বেশিরভাগ ডেভেলপারই AI কোডিং এজেন্টদের ভুলভাবে মূল্যায়ন করেন। তারা তিনটি টুল ইনস্টল করেন, একটি টার্মিনাল ওপেন করেন এবং একই সাধারণ প্রম্পট চালান: build me a landing page। তারপর তারা যে আউটপুটটি দেখতে সবচেয়ে সুন্দর মনে হয় সেটি বেছে নেন। এই পরীক্ষাটি আপনাকে একটি আসল কোডবেসের ভেতরে এই সিস্টেমগুলো কীভাবে কাজ করে সে সম্পর্কে প্রায় কিছুই বলে না।

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

আপনি যখন নতুনত্বের ডেমো থেকে বেরিয়ে এসে ইঞ্জিনিয়ারিং কাজে প্রবেশ করবেন, তখন নিচের বিষয়গুলোই মূলত শীর্ষস্থানীয় টুলগুলোকে আলাদা করে।

হারনেস (Harness) হলো আসল প্রোডাক্ট

একটি এজেন্ট হারনেস নির্ধারণ করে যে একটি রিপোজিটরির ভেতরে বুদ্ধিমত্তা কীভাবে কাজ করবে। এটি নিয়ন্ত্রণ করে যে এজেন্ট কতটুকু কনটেক্সট মনে রাখতে পারে, এটি কোন ফাইলগুলো স্পর্শ করতে পারে, একটি ব্যর্থ টার্মিনাল কমান্ড থেকে এটি কীভাবে রিকভার করে, এবং আপনার .env ফাইলটি মুছে ফেলার আগে এটি থামতে জানে কি না। দুটি এজেন্ট একই রকম বেঞ্চমার্ক স্কোর সম্পন্ন মডেলের ওপর চলতে পারে, কিন্তু যদি একটি এজেন্ট তিনটি ফাইল এডিট করার পর মডিউলগুলোর মধ্যকার সম্পর্ক হারিয়ে ফেলে আর অন্যটি আপনার আর্কিটেকচারের একটি সুসংগত ম্যাপ বজায় রাখে, তবে দ্বিতীয়টি রিফ্যাক্টর (refactor) সম্পন্ন করবে এবং প্রথমটি রিগ্রেশন (regression) তৈরি করবে।

এভাবে চিন্তা করুন: মডেলটি হলো ইঞ্জিন, কিন্তু হারনেস হলো সাসপেনশন, ব্রেক এবং স্টিয়ারিং। আপনি যদি রাস্তায় থাকতে না পারেন, তবে শক্তির কোনো মানে নেই।

Claude Code: গভীর রিপোজিটরি রিজনিং

Claude Code তখন উজ্জ্বল হয়ে ওঠে যখন আপনার কেবল কোড যোগ করার পরিবর্তে একটি জটিল কোডবেস বোঝা প্রয়োজন হয়। এর শক্তি হলো মডিউলগুলোর মধ্যকার সম্পর্কের একটি মেন্টাল মডেল বজায় রাখা। আপনি যদি এমন একটি বাগ (bug) ট্র্যাক করেন যা একটি অথেন্টিকেশন মিডলওয়্যার (authentication middleware) থেকে শুরু হয়, একটি ডাটাবেস র‍্যাপারের (database wrapper) মাধ্যমে ছড়িয়ে পড়ে এবং একটি ভ্যালিডেশন ইউটিলিটিতে (validation utility) প্রকাশ পায়, তবে Claude Code সেই সূত্রটি ধরে রাখতে সক্ষম। এটি বিশেষ করে বড় ধরনের রিফ্যাক্টরের পরিকল্পনার জন্য উপযোগী যেখানে আপনাকে একটি ইন্টারনাল API রিনেম করতে হয়, প্রতিটি কনজিউমার আপডেট করতে হয় এবং কোনো ভুলে যাওয়া ইউটিলিটি ফোল্ডারের শ্যাডো ইম্পোর্ট (shadowed import) ভুলে না গিয়ে টেস্টগুলো অ্যাডজাস্ট করতে হয়।

এর থেকে সর্বোচ্চ সুবিধা পাওয়ার একটি ব্যবহারিক উপায় হলো আপনার প্রজেক্ট রুট-এ একটি CLAUDE.md ফাইল ব্যবহার করা। এই ডকুমেন্টটি একটি প্রাতিষ্ঠানিক মেমরি (institutional memory) হিসেবে কাজ করে যা আপনি কোড আকারে লিখে রাখতে পারেন। আপনি নির্দিষ্ট করে দিতে পারেন যে সমস্ত লগিং console.log-এর পরিবর্তে ইন্টারনাল র‍্যাপার ব্যবহার করতে হবে, ডাটাবেস মাইগ্রেশন শুধুমাত্র /infra/migrations-এ থাকবে, অথবা প্রতিটি নতুন React কম্পোনেন্টের জন্য একটি অনুরূপ Storybook ফাইল প্রয়োজন। এই গার্ডরেল (guardrail) ছাড়া যেকোনো এজেন্ট তার ট্রেনিং ডিফল্টের দিকে ঝুঁকে পড়বে। এটি থাকলে, Claude Code সেই কনভেনশনগুলো মেনে চলতে পারে যা আপনার টিম প্রতিষ্ঠা করতে কয়েক মাস সময় নিয়েছে।

যখন আপনার কাজ অনুসন্ধানমূলক (exploratory) এবং আর্কিটেকচারাল হয়, তখন এই টুলটি বেছে নিন। আপনি যদি জটিল লজিক ডিবাগ করেন বা একটি মনোরিপো (monorepo)-র প্যাকেজগুলো একে অপরের ওপর কীভাবে নির্ভর করে তা পুনর্গঠন করেন, তবে কনটেক্সট হ্যান্ডলিংয়ের গভীরতা সাধারণত কাজে দেয়।

OpenAI Codex: স্ট্রাকচার্ড অটোমেশন

Codex এমন টিমের জন্য তৈরি করা হয়েছে যাদের স্কেলেতে পুনরাবৃত্তিযোগ্য ফলাফল (repeatable outcomes) প্রয়োজন। যেখানে Claude Code অনুসন্ধানের দিকে ঝুঁকে থাকে, Codex অটোমেশনের দিকে ঝুঁকে থাকে। এটি তখনই সবচেয়ে ভালো কাজ করে যখন আপনার কাছে সুনির্দিষ্টভাবে সংজ্ঞায়িত টাস্ক থাকে যা বিদ্যমান টিম সিস্টেমের সাথে খাপ খাইয়ে নিতে হবে: একটি নতুন মাইক্রোসার্ভিসের জন্য বয়লারপ্লেট (boilerplate) তৈরি করা, আপনার নির্দিষ্ট মিডলওয়্যার স্ট্যাক দিয়ে CRUD এন্ডপয়েন্ট স্কাফোল্ডিং (scaffolding) করা, বা একগুচ্ছ সার্ভিসের কনফিগারেশন ফাইল আপডেট করা।

সমস্যা হলো আপনাকে সুনির্দিষ্ট হতে হবে। আপনার একসেপ্টেন্স ক্রাইটেরিয়া (acceptance criteria) যদি অস্পষ্ট হয়, তবে Codex সানন্দে এমন কোড তৈরি করবে যা প্রযুক্তিগতভাবে চলে কিন্তু আপনার কনভেনশন লঙ্ঘন করে। কাঠামো, নামকরণের নিয়ম, এরর হ্যান্ডলিং প্যাটার্ন এবং টেস্টের প্রত্যাশাগুলো আগে থেকেই সংজ্ঞায়িত করুন। সেই পরিবেশে, Codex একজন পেয়ার প্রোগ্রামারের চেয়ে একটি অ্যাসেম্বলি লাইনের মতো বেশি কাজ করে যা প্রাকৃতিক ভাষার নির্দেশাবলী বুঝতে পারে। এটি এটিকে ইন্টারনাল টুলিং, CI-সংলগ্ন ওয়ার্কফ্লো এবং এমন যেকোনো পরিস্থিতির জন্য শক্তিশালী করে তোলে যেখানে সৃজনশীল সমস্যা সমাধানের চেয়ে ধারাবাহিকতা (consistency) বেশি গুরুত্বপূর্ণ।

Gemini CLI: ওপেন, স্ক্রিপ্টেবল ওয়ার্কফ্লো

Gemini CLI সম্পূর্ণ ভিন্ন একটি রূপ নেয়। এটি একটি কথোপকথনমূলক কোডিং অ্যাসিস্ট্যান্টের চেয়ে আপনার টার্মিনাল এনভায়রনমেন্টের একটি সম্প্রসারণযোগ্য (extensible) উপাদান হিসেবে বেশি কাজ করে। এটি অত্যন্ত স্ক্রিপ্টেবল, যার মানে হলো আপনি এটিকে স্ট্যান্ডার্ড Unix ওয়ার্কফ্লোতে পাইপ (pipe) করতে পারেন, grep, awk, বা jq-এর সাথে চেইন করতে পারেন এবং কাস্টম টুলচেইন তৈরি করতে পারেন যার জন্য আপনাকে চ্যাট উইন্ডোর মধ্যে কপি এবং পেস্ট করার প্রয়োজন হবে না।

এই উন্মুক্ততা সেইসব ইঞ্জিনিয়ারদের জন্য গুরুত্বপূর্ণ যারা টার্মিনালকে তাদের প্রধান ইন্টারফেস হিসেবে ব্যবহার করেন। আপনি এটি ব্যবহার করতে পারেন স্টেজড ডিফ (staged diffs) থেকে স্বয়ংক্রিয়ভাবে কমিট মেসেজ তৈরি করতে, ইনলাইন ব্যাখ্যাসহ লেগাসি শেল স্ক্রিপ্টগুলোকে Python-এ রূপান্তর করতে, অথবা কোনো ব্যর্থ Kubernetes pod-এর লগ আউটপুট সারসংক্ষেপ করতে। এর নন-ইন্টারঅ্যাক্টিভ মোড CI পাইপলাইনের জন্য বিশেষভাবে কার্যকর। আপনি হালকা কোড ট্রান্সফরমেশন করতে, সোর্স থেকে ডকুমেন্টেশন স্নিপেট তৈরি করতে, অথবা Slack চ্যানেলে পোস্ট করার আগে এরর আউটপুট ক্লিন করতে এটিকে একটি GitHub Action বা Makefile স্টেপে যুক্ত করতে পারেন।

আপনার ওয়ার্কফ্লো যদি ইতিমধ্যে শেল স্ক্রিপ্ট এবং কম্পোজেবল টুলের ওপর ভিত্তি করে তৈরি হয়ে থাকে, তবে Gemini CLI আপনার অভ্যাস পরিবর্তন না করেই সহজেই মানিয়ে যাবে।

যে কাজগুলো আসলে গুরুত্বপূর্ণ

AI এজেন্ট গ্রহণের হার নিয়ে গবেষণা এমন একটি প্যাটার্ন প্রকাশ করে যা অভিজ্ঞ ইঞ্জিনিয়ারদের অবাক করবে না: নতুন ফিচারের কাজের তুলনায় ডকুমেন্টেশন পরিবর্তন অনেক বেশিবার অনুমোদিত হয়। Docstrings আপডেট করা, কমেন্ট সংশোধন করা বা README সম্প্রসারণ করা একজন এজেন্টের শক্তির জায়গা, কারণ এখানে কনটেক্সট সীমাবদ্ধ এবং রিপোজিটরিতে স্টাইলটি ইতিমধ্যে প্রতিষ্ঠিত। অন্যদিকে, নতুন ফিচারের কাজের জন্য প্রয়োজন উদ্ভাবন, এজ কেস (edge cases) অনুমান করা এবং ব্যবহারকারীর উদ্দেশ্যের এমন একটি উপলব্ধি যা কোথাও লেখা নেই। কোনো একক টুলই উভয় ক্ষেত্রেই সেরা হতে পারে না কারণ এদের ব্যবহারের প্রয়োজনীয়তা বা হারনেস (harness) রিকয়ারমেন্টগুলো মৌলিকভাবে আলাদা।

এর মানে হলো আপনার মূল্যায়ন অবশ্যই আপনার করা প্রকৃত কাজের সাথে সামঞ্জস্যপূর্ণ হতে হবে। আপনি যদি কেবল সীমাবদ্ধ কাজের ওপর পরীক্ষা করেন, তবে প্রতিটি টুলই জিনিয়াস বলে মনে হবে।

যেখানে এজেন্টরা আসলে ব্যর্থ হয়

বেশিরভাগ ব্যর্থতা ঘটে এক্সিকিউশন লেয়ারে, মডেল লেয়ারে নয়। কোডটি সিনট্যাক্স অনুযায়ী নিখুঁত হতে পারে, কিন্তু একটি ইন্টারনাল API-তে নেটওয়ার্ক টাইমআউট, macOS-এ কাজ করে কিন্তু GNU/Linux-এ ব্যর্থ হওয়া একটি sed কমান্ড, অথবা কোনো পারমিশন বাউন্ডারি যা এজেন্ট চিনতে পারে না—এর কারণে এজেন্টটি ব্যর্থ হতে পারে। এজেন্টরা তখন হিমশিম খায় যখন:

  • একটি API সাময়িক ব্যর্থতা (transient failure) প্রদান করে এবং লুপটি ব্যাক-অফ (back off) করার পরিবর্তে ঘুরতে থাকে।
  • একটি টুল এমনভাবে এরর স্ট্রিম প্রদান করে যা এজেন্ট ভুলভাবে ব্যাখ্যা করে।
  • একটি কমান্ডের জন্য sudo অ্যাক্সেস প্রয়োজন যা এজেন্টের নেই, ফলে এটি নিঃশব্দে আটকে (silent hang) যায়।
  • জেনারেট করা টেস্টগুলো আলাদাভাবে পাস করলেও রিয়েল ডেটাবেসের সাথে চালানোর সময় ব্যর্থ হয় কারণ হারনেসটি কানেকশন স্ট্রিং সঠিকভাবে প্রকাশ করতে পারেনি।

এগুলো হলো ইন্টিগ্রেশন সমস্যা। এগুলোর জন্য এমন একটি হারনেস প্রয়োজন যা কীভাবে এরর পড়তে হয়, বাউন্ডারি বা সীমানা মেনে চলতে হয় এবং ভুল পথে এগিয়ে না গিয়ে মানুষের হস্তক্ষেপ চাইতে হয় তা জানে।

কীভাবে এই টুলগুলোকে বাস্তবে মূল্যায়ন করবেন

এজেন্টদের build a landing page-এর মতো প্রম্পট দিয়ে পরীক্ষা করা বন্ধ করুন। এটি ভিজ্যুয়াল আউটপুট পরিমাপ করে, ইঞ্জিনিয়ারিং ক্ষমতা নয়। পরিবর্তে, প্রতিটি টুলকে বাস্তব কাজের একই অগ্নিপরীক্ষার সম্মুখীন করুন:

  • এমন একটি বাগ ঠিক করুন যা একাধিক ফাইল জুড়ে বিস্তৃত, যেখানে মূল কারণ এবং লক্ষণ স্ট্যাকের বিভিন্ন লেয়ারে অবস্থিত।
  • বাহ্যিক আচরণ পরিবর্তন না করে একটি ডিপ্রিকേറ്റেড (deprecated) ডিপেন্ডেন্সি সরানোর জন্য একটি মডিউল রিফ্যাক্টর করুন, তারপর যাচাই করুন যে টেস্ট স্যুটটি এখনও পাস করছে কি না।
  • কোনো থার্ড-পার্টি API তার রেসপন্স শেপ পরিবর্তন করার পর প্রতিটি মক ফিক্সচার (mock fixture), টাইপ ডেফিনিশন এবং ইন্টিগ্রেশন টেস্ট আপডেট করুন।
  • ভার্সন কনফ্লিক্টের কারণে ভেঙে যাওয়া একটি বিল্ড শনাক্ত করুন এবং এমন একটি সমাধান প্রস্তাব করুন যা আসলে কম্পাইল হয়।

কেবল অনুমানের (vibes) ওপর নির্ভর না করে শক্ত মেট্রিক্স (hard metrics) ট্র্যাক করুন। কমপ্লিশন রেট গণনা করুন: এজেন্ট কি কাজ শেষ করেছে নাকি মাঝপথে হাল ছেড়ে দিয়েছে? কোডটি মার্জ করার যোগ্য হওয়ার আগে কতবার মানুষের সংশোধনের প্রয়োজন হয়েছিল তা লগ করুন। টেস্টগুলো কি প্রথম প্রচেষ্টাতেই পাস করেছে নাকি বারবার প্যাচওয়ার্কের প্রয়োজন হয়েছে তা পরীক্ষা করুন। আউটপুট রিভিউ করতে একজন সিনিয়র ইঞ্জিনারের কত সময় লেগেছে তা পরিমাপ করুন। যে টুলটি নিখুঁতভাবে দুইশ লাইন কোড লিখে দেয় সেটিও মূল্যহীন যদি আপনাকে এক ঘণ্টা সময় ব্যয় করতে হয় শুধু এটি নিশ্চিত করতে যে এটি এমন কোনো ফাইল স্পর্শ করেনি যা তার ছোঁয়া উচিত ছিল না।

আসল শিক্ষা

বিজয়ী টুলটি সেটি নয় যা সবচেয়ে বেশি ক্যারেক্টার তৈরি করে বা সবচেয়ে চাকচিক্যময় ডেমো দেখায়। এটি হলো সেই টুল যা সবচেয়ে কম রিভিউ জটিলতা (review friction) সহ সবচেয়ে বেশি মার্জযোগ্য কোড তৈরি করে। এই ক্ষেত্রে প্রতিযোগিতা এখন র (raw) মডেল ইন্টেলিজেন্স থেকে সরে এসে নির্ভরযোগ্য ইঞ্জিনিয়ারিং হারনেসের দিকে মোড় নিচ্ছে। সেই এজেন্টটি বেছে নিন যার সিস্টেম ডিজাইন আপনার প্রকৃত কাজের ধরনের সাথে মিলে যায়: আর্কিটেকচারাল সার্জারির জন্য গভীর যুক্তি (deep reasoning), টিম অটোমেশনের জন্য কাঠামোগত নির্ভুলতা (structured precision), অথবা কাস্টম ওয়ার্কফ্লোর জন্য টার্মিনাল এক্সটেনসিবিলিটি (terminal extensibility)। তারপর এটিকে খেলনা সমস্যার (toy problems) পরিবর্তে প্রকৃত ব্যর্থতার ওপর পরীক্ষা করুন।

এই বিশ্লেষণটি এই বিস্তারিত বিবরণ-এ বর্ণিত সরাসরি তুলনা এবং এজেন্টের আচরণের গবেষণার ওপর ভিত্তি করে করা হয়েছে।

ইঞ্জিনিয়ারিং টুলস এবং AI ওয়ার্কফ্লো সম্পর্কে আরও আলোচনার জন্য, GyaanSetu learning community-এ যোগ দিন।