হারনেস ইঞ্জিনিয়ারিং হয়ে উঠছে আসল চাকরি — জব ডেসক্রিপশনে যা থাকে

গত দুই বছর ধরে, এআই এজেন্ট নিয়ে ক্যারিয়ার পরামর্শ মূলত এদের ভালোভাবে প্রম্পট করতে শেখার মধ্যেই সীমাবদ্ধ ছিল। কিন্তু সেটা আর বিরল দক্ষতা নয়। এখন বিরল দক্ষতা হলো এজেন্ট যে কাঠামোর ভেতরে বসে থাকে সেটি তৈরি করা — যাকে ক্রমশ হার্নেস বলা হচ্ছে — এবং এটি এতটাই নির্দিষ্ট ও কঠিন যে এটি একটি দলের "এআই মানুষটির" পার্শ্ব-দায়িত্ব না থেকে নিজেই একটি স্বতন্ত্র পদের বিবরণ হয়ে উঠছে।

এই বিষয়ে সবচেয়ে স্পষ্ট প্রকাশ্য বিবরণ পাওয়া যায় Lenny's Newsletter-এ, যেখানে দেখানো হয়েছে কীভাবে প্রোডাক্ট-ম্যানেজমেন্ট টুল ChatPRD Sentry-র বাগ স্বয়ংক্রিয়ভাবে ডিবাগ করার জন্য একটি হার্নেস তৈরি করেছিল। এখানে বিশেষায়িত হওয়ার কথা ভাবলে পুরো লেখাটি পড়া উচিত, কারণ এতে এমন একটি বিষয় তুলে ধরা হয়েছে যা সহজেই এড়িয়ে যাওয়া যায়: মডেলটি কখনোই বাধা ছিল না। দলটি ভিত্তি হিসেবে Claude Agent SDK ব্যবহার করেছিল, এরপর তাদের বেশিরভাগ প্রকৌশল প্রচেষ্টা ব্যয় করেছিল একটি কাস্টম টার্মিনাল UI এবং এজেন্টকে Sentry, Linear, GitHub ও Vercel-এর সঙ্গে সংযুক্ত করার একগুচ্ছ অ্যাডাপ্টার তৈরিতে। সংক্ষেপে, এটাই এই কাজ। চারটি সিস্টেম, চারটি ভিন্ন অথ স্কিম, চারটি ভিন্ন ডেটা আকৃতি, এবং এমন একটি UI যা একজন মানুষকে প্রতিটি ধাপ পাহারা না দিয়েই পর্যবেক্ষণ ও হস্তক্ষেপ করতে দেয়।

"হার্নেস" আসলে যেসব অংশে ভাগ হয়

আপনি যদি বুঝতে চেষ্টা করেন যে এই দক্ষতাগুলো গড়ে তোলার যোগ্য কিনা, তাহলে এটাকে এমন কিছু অংশে ভাগ করে দেখা সহায়ক যেগুলো আলাদাভাবে নিয়োগ দেওয়া হয়, বা অন্তত সাক্ষাৎকারে আলাদাভাবে মূল্যায়ন করা হয়:

• পারমিশন ডিজাইন। একটি এজেন্টকে অনুমতিহীনভাবে কী করতে দেওয়া হবে (একটি টিকিট পড়া, একটি PR খসড়া তৈরি করা) আর কোন কাজে মানুষের হস্তক্ষেপ দরকার (মার্জ করা, ডিপ্লয় করা, মুছে ফেলা, অর্থ খরচ করা) তা ঠিক করা — এবং সেটাকে প্রম্পটের নির্দেশনা হিসেবে নয়, বরং কোডে প্রকৃত নীতি হিসেবে সংকেতায়িত করা, যা চাপের মুখে মডেল উপেক্ষা করতে পারে। এটি প্রম্পট লেখার চেয়ে অ্যাক্সেস-কন্ট্রোল ইঞ্জিনিয়ারিংয়ের কাছাকাছি।
• টুল অ্যাডাপ্টার। প্রতিটি বাহ্যিক সিস্টেমের (Sentry, Linear, GitHub, Vercel, অথবা আপনার কোম্পানির স্ট্যাক যা-ই হোক) জন্য পাতলা, ভালোভাবে পরীক্ষিত র‍্যাপার যা এজেন্টের অভিপ্রায়কে একটি নিরাপদ, যাচাইকৃত API কলে রূপান্তর করে এবং সেই সাড়াকে এমন কিছুতে ফিরিয়ে আনে যা মডেল বুঝে যুক্তি করতে পারে। এটি সাধারণ সফটওয়্যার ইঞ্জিনিয়ারিং — এরর হ্যান্ডলিং, রিট্রাই, স্কিমা যাচাইকরণ — যা একটি নতুন ব্যবহারকারীর ওপর প্রয়োগ করা হয়েছে।
• টার্মিনাল বা কনসোল UI। একজন মানুষের জন্য এজেন্ট কী করছে তা দেখার, কাজ অনুমোদন বা প্রত্যাখ্যান করার, এবং এটি আটকে গেলে হস্তক্ষেপ করার একটি উপায়। ChatPRD একটি কাস্টম UI তৈরি করেছিল; অনেক দল হয়তো এর বদলে রেডিমেড এজেন্ট কনসোল ব্যবহার করবে, কিন্তু তবুও কাউকে না কাউকে ঠিক করতে হয় কী দেখানো হবে, কী লুকানো হবে, এবং কোন কাজ ঘটার আগে ক্লিক করার প্রয়োজন হবে।
• বড় পরিসরে টুল নির্বাচন। Machine Learning Mastery-র একটি লেখায় এমন একটি বিষয় তুলে ধরা হয়েছে যা ডেমোর চেয়ে বেশি কিছু তৈরি করলে জানা দরকার: টুল ক্যাটালগ প্রায় এক ডজন অপশন ছাড়ালে টুল কল করার ক্ষেত্রে এজেন্টের নির্ভুলতা কমতে থাকে — মডেল ভুল টুল কল করা শুরু করে, প্যারামিটার নিয়ে হ্যালুসিনেট করে, অথবা খারাপ কলের ক্ষেত্রে থমকে যায়। এতে যেসব প্রতিকারের কথা বলা হয়েছে (একটি নির্দিষ্ট প্রসঙ্গে কোন টুলগুলো আদৌ দৃশ্যমান তা নিয়ন্ত্রণ করা, রিট্রিভ্যাল-ভিত্তিক টুল লুকআপ, বিশেষায়িত সাব-এজেন্টে রাউটিং, স্পষ্ট পরিকল্পনা ধাপ, ফলব্যাক লজিক, এবং রিগ্রেশন ধরার জন্য বেঞ্চমার্ক হার্নেস) সেগুলো নিজেই এমন একটি চেকলিস্ট যা একজন হার্নেস ইঞ্জিনিয়ারের শুধু জানলেই চলবে না, বাস্তবায়ন করতে জানতে হবে।
• কনটেক্সট ও মেমরি ইঞ্জিনিয়ারিং। একই উৎস একটি গুরুত্বপূর্ণ পার্থক্য তুলে ধরে: কনটেক্সট ইঞ্জিনিয়ারিং (একটি একক ইনফারেন্স কলে কী যায়, এবং কোথায়) এবং মেমরি ইঞ্জিনিয়ারিং (সেশন জুড়ে কী টিকে থাকে, তা কীভাবে সংরক্ষিত হয়, কীভাবে পুনরুদ্ধার করা হয়) — এই দুটি ভিন্ন শৃঙ্খলা, যাদের ব্যর্থতার ধরনও ভিন্ন। এর দাবি হলো, দীর্ঘস্থায়ী, বহু-সেশন এজেন্টে বেশিরভাগ বিপর্যয়ের মূলে থাকে এই দুটিকে গুলিয়ে ফেলা — সেশন মেমরিকে শুধু আরও কনটেক্সট হিসেবে গণ্য করা, বা উল্টোটা — বিশেষত যেখানে সিস্টেম ঠিক করে কী পুনরুদ্ধার করতে হবে।

এই প্রমাণ যে এটি একটি বাস্তব, তহবিলযোগ্য পদ — শুধু শখের জায়গা নয়

সন্দেহপ্রবণ মানুষেরা যুক্তিসঙ্গতভাবেই প্রশ্ন তুলতে পারেন যে "হার্নেস ইঞ্জিনিয়ার" আদৌ একটি চাকরি, নাকি অন্য কারও কাজের ভেতরের একটি অংশমাত্র। ডাইজেস্টের দুটি তথ্য ইঙ্গিত দেয় যে এটি প্রথমটির দিকেই এগোচ্ছে। প্রথমত, মাইক্রোসফটের Aspire টিম — একটি ১০ জনের দল — GitHub-এর Agentic Workflows ব্যবহার করে ক্রস-রিপো ডকুমেন্টেশন PR স্বয়ংক্রিয় করেছিল, এবং দুটি রিলিজ জুড়ে ৮২টি PR মার্জ করেছিল, সংশ্লিষ্ট প্রোডাক্ট PR প্রকাশের গড়ে ৪৪.৮ ঘণ্টা পর, কোনো নতুন নিয়োগ বা প্রক্রিয়া পুনঃপ্রশিক্ষণ ছাড়াই। এটি একটি ছোট দলের অস্বাভাবিক প্রভাব অর্জনের উদাহরণ, নির্দিষ্টভাবে এই কারণে যে কেউ কাঠামোতে (ওয়ার্কফ্লো সংজ্ঞা, রিভিউ রাউটিং, ট্রিগার লজিক) বিনিয়োগ করেছিল, প্রকৌশলীদের হাতে করে ডকস PR লেখানোর বদলে। দ্বিতীয়ত, মাইক্রোসফট রিসার্চের SkillOpt প্রকল্প এজেন্ট "স্কিল" ফাইলগুলোকে — যে নির্দেশনা ও সীমাবদ্ধতা এজেন্টের হার্নেসের মধ্যে আচরণ নির্ধারণ করে — হাতে সম্পাদনার বদলে পদ্ধতিগতভাবে অপ্টিমাইজ করার মতো কিছু হিসেবে দেখে, এবং জানায় যে এটি একটি বেঞ্চমার্ক গ্রিডের সব ৫২টি সেলে (ছয়টি বেঞ্চমার্ক, সাতটি মডেল, তিনটি এক্সিকিউশন মোড) সেরা বা যৌথভাবে সেরা ছিল, এবং অপ্টিমাইজড স্কিলগুলো বিভিন্ন মডেল ও বিভিন্ন হার্নেস জুড়ে স্থানান্তরযোগ্য ছিল। এই নির্দিষ্ট টুলটি মানদণ্ড হয়ে উঠুক বা না উঠুক, এটি ইঙ্গিত দেয় যে এই শিল্প হার্নেস কনফিগারেশনকে নিজস্ব টুলিং ও বেঞ্চমার্কসহ একটি প্রকৌশল শিল্পকর্ম হিসেবে দেখতে শুরু করেছে — ঠিক যে গতিপথে "DevOps" এলোমেলো স্ক্রিপ্টের সমষ্টি থেকে একটি শৃঙ্খলায় পরিণত হয়েছিল।

এই স্তরের জন্য স্পষ্টভাবে অবকাঠামোও এখন তৈরি হচ্ছে। Gemini API-তে Google-এর নতুন ঘোষিত "Managed Agents" সক্ষমতাগুলো — ব্যাকগ্রাউন্ড ও অ্যাসিঙ্ক এক্সিকিউশন, রিমোট MCP সার্ভার ইন্টিগ্রেশন, কাস্টম ফাংশন কলিং, ইন্টারঅ্যাকশন জুড়ে ক্রেডেনশিয়াল রিফ্রেশ — কার্যত এমন প্রি-বিল্ট প্লাম্বিং যা ChatPRD দল হাতে করে সমাধান করা ঠিক সেই সমস্যাগুলোর জন্য তৈরি। এটি একটি স্বাভাবিক প্যাটার্ন: এক দল এই বছর যা কাস্টম বানায়, একটি প্ল্যাটফর্ম বিক্রেতা পরের বছর সেটাকেই পণ্য বানিয়ে ফেলে। এতে হার্নেস-ইঞ্জিনিয়ারিং পদটি বিলুপ্ত হয় না; বরং এটি ন্যূনতম মান বাড়ায় এবং কাজটিকে প্রতিটি অ্যাডাপ্টার শূন্য থেকে লেখার বদলে ম্যানেজড প্রিমিটিভগুলো একীভূত ও কনফিগার করার দিকে সরিয়ে দেয় — অনেকটা যেভাবে ক্লাউড ইনফ্রাস্ট্রাকচার অপস ইঞ্জিনিয়ারদের বিলুপ্ত করেনি, বরং তাদের সময় কীসে ব্যয় হয় তা বদলে দিয়েছিল।

আপনি যদি এই পদের দিকে লক্ষ্য রাখেন তাহলে এর মানে কী

এই কাজের জন্য বিশ্বাসযোগ্য হতে চাইলে পোর্টফোলিও বা রিজিউমেতে রাখার মতো কিছু নির্দিষ্ট, যাচাইযোগ্য বিষয়: আপনার নিয়ন্ত্রণে নেই এমন একটি বাস্তব API-এর বিরুদ্ধে সম্পূর্ণ একটি অ্যাডাপ্টার তৈরি করুন (অথ, এরর হ্যান্ডলিং, রেট লিমিটসহ, শুধু একটি হ্যাপি-পাথ ডেমো নয়); এমন একটি এজেন্টের জন্য পারমিশন মডেল ডিজাইন ও নথিভুক্ত করুন যা রিড/প্রপোজ/অ্যাক্ট কাজগুলোর মধ্যে পার্থক্য করে এবং দেখায় কেন প্রতিটি সীমারেখা সেখানেই আছে; এবং এমন একটি রিভিউ ইন্টারফেস তৈরি বা কনফিগার করুন যেখানে একজন মানুষ এজেন্টের কাজ কার্যকর হওয়ার আগে অনুমোদন করে, কারণ এজেন্টকে প্রোডাকশন স্পর্শ করতে দেওয়ার আগে বেশিরভাগ কোম্পানি এই অংশটির ওপর জোর দেবে। আপনি যদি একটি হার্নেস-ইঞ্জিনিয়ারিং চাকরির প্রস্তাব যাচাই করছেন বা নিজের দায়িত্ব নির্ধারণ করছেন, তাহলে নির্দিষ্টভাবে জিজ্ঞেস করুন কে পারমিশন মডেলের মালিক, কে অ্যাডাপ্টারগুলোর মালিক, এবং কে মানব-রিভিউ পৃষ্ঠতলের মালিক — বর্তমানে অনেক দলে এই তিনটি বিষয়ের কোনো স্পষ্ট মালিক নেই, এবং এটাই ঠিক সেই ফাঁক যা পূরণ করার জন্য এই পদটি গড়ে উঠছে।

স্পষ্টভাবে বলার মতো একটি সতর্কতা: ওপরের কোনো উৎসই এই নির্দিষ্ট পদের জন্য নিয়োগ-বাজারের কোনো সংখ্যা প্রতিষ্ঠিত করে না, এবং "হার্নেস ইঞ্জিনিয়ার" এখনও এমন একটি পদবি নয় যা আপনি চাকরির বিজ্ঞাপনে দেখবেন — এটি "AI ইনফ্রাস্ট্রাকচার ইঞ্জিনিয়ার", "এজেন্ট প্ল্যাটফর্ম ইঞ্জিনিয়ার", বা নিছক "সিনিয়র ব্যাকএন্ড ইঞ্জিনিয়ার, AI সিস্টেমস"-এর মতো পদবির ভেতরে দেখা যাচ্ছে। এটিকে LinkedIn-এ খোঁজার জন্য একটি পদবি হিসেবে না দেখে, গড়ে তোলা ও সঠিকভাবে বর্ণনা করার একটি দক্ষতাসেট হিসেবে দেখুন।