Harness engineering-এর ইন্টারভিউ প্রশ্ন: AI ইঞ্জিনিয়ারের জন্য ২২টি প্রশ্ন ও উত্তর

কীভাবে প্রস্তুতি নেবেন

Harness engineering-এর ইন্টারভিউ প্রশ্ন সাধারণত সাধারণ থেকে নির্দিষ্টের দিকে যায়: harness কী, কী কী নিয়ে গঠিত, কীভাবে সমস্যা নির্ণয় করেন, কীভাবে প্রভাব মাপেন। ইন্টারভিউয়ার খোঁজেন প্রকৌশলী চিন্তাভাবনা: মডেলের সমস্যা ও পরিবেশের সমস্যার পার্থক্য বোঝা, এবং যাচাইযোগ্য সমাধান প্রস্তাব করা। নিচে বিষয় অনুযায়ী সাজানো ২২টি প্রশ্ন ও উত্তর।

মূল ধারণা

১. Agent harness কী?

Harness হলো AI এজেন্ট যে পুরো পরিবেশে কাজ করে তার সবকিছু, মডেল ছাড়া: নির্দেশনা, টুল, এক্সিকিউশন পরিবেশ, অবস্থা সংরক্ষণ এবং প্রতিক্রিয়ার চক্র। মডেল সিদ্ধান্ত নেয়, আর harness ঠিক করে মডেল কী জানে, কী করতে পারে এবং নিজের ফলাফল কীভাবে জানে। একই মডেল ভিন্ন harness-এ খুব ভিন্ন মানের ফল দেয়।

২. Harness engineering prompt ও context engineering থেকে কীভাবে আলাদা?

Prompt engineering এক অনুরোধের শব্দচয়ন নিয়ে কাজ করে, context engineering প্রতিটি ধাপে মডেলের জানালায় কী যাবে তা নিয়ে। Harness engineering দুটিকেই অন্তর্ভুক্ত করে এবং যোগ করে যা শুধু লেখা দিয়ে সমাধান হয় না: টুলে প্রবেশাধিকার, পুনরুৎপাদনযোগ্য পরিবেশ, সেশনের মধ্যে অবস্থা, এবং ফলাফলের যান্ত্রিক যাচাই।

৩. Harness-এর পাঁচটি উপাদান বলুন।

নির্দেশনা (AGENTS.md, CLAUDE.md, skills, নথি), টুল (shell, test, linter, browser, MCP), পরিবেশ (dependency, runtime, Docker, worktree), অবস্থা (PROGRESS.md, ফিচার তালিকা, সিদ্ধান্ত), এবং প্রতিক্রিয়া (make check, E2E, hook, মূল্যায়নকারী)। যেকোনো একটি উপাদান না থাকা মানে «একটু খারাপ ফল» নয়, বরং একটি পদ্ধতিগত ব্যর্থতার শ্রেণি।

৪. শক্তিশালী মডেলে বদলালে প্রায়ই কেন সমাধান হয় না?

কারণ অনেক ব্যর্থতা মডেলের বুদ্ধিমত্তা থেকে আসে না। শক্তিশালী মডেল এমন কমান্ডে প্রবেশাধিকার পাবে না যা নেই, অবস্থার ফাইল ছাড়া গতকালের সেশন মনে রাখবে না, এবং কেউ না চালালে ভাঙা migration-এর কথা জানবে না। নির্দিষ্ট দলের কনভেনশনও মডেল আন্দাজ করতে পারে না।

রোগ নির্ণয়

৫. এজেন্ট CLAUDE.md-এ লেখা নিয়ম লঙ্ঘন করছে। আপনি কী করবেন?

প্রথমে দেখুন এজেন্ট নিয়মটি খুঁজে পাচ্ছে কি না: দশের বেশি বুলেটের দীর্ঘ ফাইল গুরুত্বপূর্ণ জিনিস ঝাপসা করে। প্রবেশ-ফাইলকে সূচিতে ছোট করুন, বিস্তারিত শর্তসাপেক্ষে নথিতে সরান। নিয়মটি গুরুত্বপূর্ণ হলে সেটিকে চালানো যায় এমন যাচাইয়ে বদলান — linter, test, grep-গার্ড বা hook — যাতে লঙ্ঘন যান্ত্রিকভাবে দেখা যায়, মডেলের মনোযোগের ওপর না থাকে।

৬. লক্ষণ দেখে কীভাবে বুঝবেন কোন উপাদান ভাঙা?

পরিচিত কনভেনশন ভাঙছে — নির্দেশনা। এজেন্ট «চায়, কিন্তু পারে না» — টুল। প্রতিটি সেশন পরিবেশ ঠিক করে শুরু হয় — পরিবেশ। নতুন সেশন জানে না কাজ কোথায় থামল — অবস্থা। «সম্পন্ন» বাস্তবের সঙ্গে মেলে না — প্রতিক্রিয়া।

৭. Harness কোন উপাদান দিয়ে শুরু করা উচিত, এবং কেন?

প্রতিক্রিয়া দিয়ে। যতক্ষণ এমন কমান্ড নেই যা যান্ত্রিকভাবে বলে «কাজ করছে কি না», ততক্ষণ অন্য কোনো পরিবর্তনের প্রভাব মাপা যায় না। এরপর সাধারণত আসে নির্দেশনা, অবস্থা, পরিবেশ ও টুল, তবে ক্রমটি অভিজ্ঞতাভিত্তিক এবং কোনটি সবচেয়ে বেশি ভাঙা তার ওপর নির্ভর করে।

৮. একটি harness উপাদানের অবদান কীভাবে মাপবেন?

Ablation দিয়ে: মডেল ও কাজের সেট ঠিক রেখে একটি উপাদান একবারে বন্ধ করে মান কতটা কমে তা দেখা হয়। তবে ব্যর্থতার লগ দিয়ে শুরু করা ভালো, কারণ স্তরভিত্তিক চিহ্নিতকরণে বাধা দ্রুত ধরা পড়ে। শূন্য পতন মানে উপাদানটি অকেজো নয়: হয়তো এই কাজগুলো তা ব্যবহার করেনি, অথবা সেটি অতিরিক্ত।

নির্দেশনা ও প্রসঙ্গ

৯. ভালো AGENTS.md কীভাবে গড়বেন?

রাউটার হিসেবে, পাঠ্যবই হিসেবে নয়: প্রকল্প কী, কীভাবে চালাতে হয়, কীভাবে যাচাই হয়, Definition of Done এবং বাধ্যতামূলক সীমার একটি ছোট তালিকা। বিস্তারিত আলাদা নথিতে থাকে, «পেমেন্ট ছুঁলে পড়ো» ধরনের লিংকসহ। ফাইল invariant ঠিক করে («ডেটা সীমানায় যাচাই হয়»), লাইনে লাইনে বাস্তবায়ন বা লাইব্রেরি নির্দেশ দেয় না।

১০. Subagent কেন দরকার?

প্রসঙ্গ আইসোলেশনের জন্য। সহায়ক কাজ — কোডবেসে খোঁজা, review, যাচাই — আলাদা প্রসঙ্গে চলে এবং শুধু আউটপুট ফেরত দেয়। মূল ধারা দূষিত হয় না, আর মূল্যায়নকারী subagent সম্পাদকের যুক্তি উত্তরাধিকারে পায় না, যা সৎ মূল্যায়নের জন্য জরুরি।

১১. Harness debt কী?

Harness ও বাস্তবের জমে ওঠা ফারাক: পুরনো নিয়ম, আর কাজ করে না এমন কমান্ড, এমন মডিউলের নথি যা আর নেই। এটি প্রযুক্তিগত ঋণের মতো আচরণ করে — অলক্ষ্যে জমে, এজেন্টের ব্যর্থতায় শোধ হয়। Harness নিয়মিত পর্যালোচনা করতে হয়, শুধু একবার কনফিগার করে ছেড়ে দিলে চলে না।

অবস্থা ও সেশন

১২. সেশনের মধ্যে এজেন্টের বিস্মৃতি কীভাবে সামলাবেন?

অবস্থা repository-তে রাখুন: PROGRESS.md (কী অবস্থা, কী সম্পন্ন, বাধা, পরের ধাপ), DECISIONS.md (সিদ্ধান্ত, কারণ, বাতিল বিকল্প), অবস্থাসহ ফিচার তালিকা, এবং ঘন ঘন commit। নির্দেশনায় শুরুর ক্রম ঠিক করুন: অগ্রগতি পড়ো, পরিবেশ যাচাই স্ক্রিপ্ট চালাও, সক্রিয় ফিচার নাও।

১৩. WIP=1 নিয়ম কেন?

এজেন্ট একসঙ্গে কয়েকটি ফিচার শুরু করলে অবস্থা ছড়িয়ে যায়: কিছুই শেষ হয় না, পরিবর্তন মিশে যায়, rollback কঠিন হয়। একটি সক্রিয় ফিচার স্পষ্ট যাচাই-বিন্দু, পরিষ্কার commit এবং ব্যর্থতার পর সহজ পুনরুদ্ধার দেয়।

১৪. Cold start test কী?

পরীক্ষা: নতুন সেশন মানুষের ইঙ্গিত ছাড়া মৌলিক প্রশ্নের উত্তর দিতে পারে কি না — প্রকল্পটি কী, কোথায় থামা হয়েছে, কোন ফিচার সক্রিয়, সবকিছু ঠিক আছে কি না যাচাই করবে কীভাবে। এজেন্ট ফাইল থেকে আন্দাজ ছাড়া উত্তর দিলে অবস্থার উপাদান কাজ করছে।

যাচাই

১৫. সবুজ unit test কেন প্রমাণ করে না যে ফিচার কাজ করে?

Unit test মডিউলকে আলাদা করে এবং নির্ভরতা mock করে, তাই সংযোগ দেখে না: ইন্টারফেসের অমিল, অবস্থার ছড়ানো (schema বদলেছে, cache পুরনো), সম্পদের ফাঁস, কনফিগারেশন ও পরিবেশের সমস্যা। Unit ধরা ত্রুটি integration ধরা ত্রুটির উপসেট, আর সেটি আবার E2E-তে ধরা যায় এমন ত্রুটির উপসেট।

১৬. Verification gap কী এবং কীভাবে হিসাব করবেন?

যেসব কাজ এজেন্ট «সম্পন্ন» বলেছে কিন্তু স্বাধীন যাচাই নিশ্চিত করেনি, তার অনুপাত। ১০টি কাজ পরপর নিন এবং প্রতিটির জন্য দুটি তথ্য লিখুন। এটি মূল-রেখা দেয়: harness বদলের পর অনুরূপ কাজের সেটে আবার হিসাব করুন।

১৭. এজেন্টের জন্য Definition of Done কীভাবে লিখবেন?

AGENTS.md-এ যাচাইযোগ্য বিন্দুর তালিকা হিসেবে: যাচাই-কমান্ড কোড 0 নিয়ে শেষ, সেই পরিস্থিতির জন্য E2E আছে, migration প্রয়োগ হয়, অগ্রগতি হালনাগাদ। কী সম্পন্নতা নয় তা স্পষ্ট লেখাও কাজের: «ঠিক দেখাচ্ছে», «unit test পাস করছে», «আমার কাছে চলছে»।

১৮. এজেন্ট নিজে «সম্পন্ন» স্ট্যাটাস কেন দেবে না?

মডেল নিজের কাজের মূল্যায়ন বাড়িয়ে দেখতে ঝোঁকে, আর আত্মমূল্যায়ন সেই একই প্রসঙ্গে হয় যেখানে সিদ্ধান্ত নেওয়া হয়েছে। Passing স্ট্যাটাস যাচাই-স্ক্রিপ্ট দেবে, কমান্ড চালানোর ফলাফলের ভিত্তিতে, এবং commit hash প্রমাণ হিসেবে লিখবে।

১৯. স্বাধীন মূল্যায়নকারী কীভাবে গড়বেন?

আলাদা এজেন্ট বা সেশন, যা শুধু প্রয়োজনীয়তা, diff ও যাচাইয়ের ফলাফল দেখে, সম্পাদকের যুক্তি দেখে না। সে রুব্রিক ধরে মূল্যায়ন করে (সঠিকতা, স্থাপত্য, test, ত্রুটির হাতল), আর প্রতিটি মূল্যায়ন একটি ফাইল, লাইন বা লগের সঙ্গে যুক্ত। আদর্শভাবে ভিন্ন মডেল ব্যবহার করুন, যাতে দুজনের অন্ধ জায়গা একই না হয়।

২০. স্থাপত্যের নিয়মকে কীভাবে চালানো যায় এমন যাচাইয়ে বদলাবেন?

তিন স্তরে: guard grep (দ্রুত, প্যাটার্নভিত্তিক), আমদানি-গ্রাফ বোঝা linter-নিয়ম (import-linter, dependency-cruiser), এবং CI-এ স্থাপত্য-test। সবগুলো make check-এ যুক্ত হয়, অশূন্য কোডে ব্যর্থ হয় এবং WHY ও FIX ছাপায়, যাতে এজেন্ট নিজে লঙ্ঘন ঠিক করতে পারে। নতুন যাচাইয়ের ট্রিগার: একই রিভিউ-মন্তব্য দ্বিতীয়বার এলে।

স্বয়ংক্রিয় কাজ

২১. এজেন্টকে ঘণ্টার পর ঘণ্টা কাজ করতে দিতে কী লাগে?

অস্পষ্টতাহীন লক্ষ্য, একমুখী অগ্রগতির মেট্রিক (যেমন passing ফিচারের সংখ্যা), প্রতি ফিচারের সময় ও চেষ্টার বাজেট, রিগ্রেশনে স্বয়ংক্রিয় rollback, এবং মানুষের প্রয়োজনীয় কাজের তালিকা: migration, অবকাঠামো, টাকা। সঙ্গে আইসোলেশন: আলাদা sandbox বা git worktree, যাতে ভুল কাজের পরিবেশে না লাগে।

২২. একটি এজেন্ট-চক্র কখন যথেষ্ট নয়, এবং ভূমিকার গ্রাফ কীভাবে গড়বেন?

যখন সম্পাদক নিজেকে যাচাই করতে শুরু করে এবং আটকে যায়। তখন কাজ ভূমিকায় ভাগ হয়: বাস্তবায়ন, review, test, merge। Review পায় পরিষ্কার প্রসঙ্গ ও রুব্রিক, আর review == pass হলে merge-এর কাজ কোড করে। Review ব্যর্থ হলে ফিচার বাস্তবায়নে ফেরে, এবং কয়েকবার ব্যর্থ হলে পরিষ্কার প্রসঙ্গে নতুন করে শুরু হয় — মানে সমস্যা কাজটি বোঝায়, কোডে নয়।

সারসংক্ষেপ

Harness engineering-এর ইন্টারভিউয়ে সবচেয়ে ভালো উত্তর হলো যা যাচাইযোগ্য তা নিয়ে কথা বলা: কোন ফাইল, কোন কমান্ড, কোন মেট্রিক। মাথায় রাখুন পাঁচটি উপাদান, verification gap, এবং «সম্পন্নতা স্ক্রিপ্ট ঠিক করে» নিয়মটি। এই সব বিষয় কোর্সের একটি প্রকল্পে একটি পূর্ণ harness-এ মিলিত হয়।