২,৯০০ জন ইঞ্জিনিয়ারের ওপর করা একটি ২০২৬ সালের জরিপ অনুযায়ী, ডেভেলপাররা এখন সপ্তাহে ১১.৪ ঘণ্টা AI-জেনারেটেড কোড রিভিউ করতে ব্যয় করছেন, যা তাদের নিজেদের লেখা ৯.৮ ঘণ্টার চেয়েও বেশি। প্রতিবন্ধকতা এখন "AI কি কোড তৈরি করতে পারে?" থেকে সরে এসে "AI যে কোড তৈরি করছে তা কি আমরা বিশ্বাস করতে পারি?"—এই পর্যায়ে পৌঁছেছে এবং টিমগুলো এখন মাল্টি-এজেন্ট AI ওয়ার্কফ্লোর দিকে ঝুঁকছে, যা আরও স্পষ্ট সিদ্ধান্তের ধারা (decision trails) এবং উচ্চতর আত্মবিশ্বাসের প্রতিশ্রুতি দেয়।
সেই জরিপ যা আলোচনার সূত্রপাত ঘটিয়েছে
এই বছরের শুরুর দিকে পরিচালিত একটি প্রশ্নাবলীতে ডেভেলপারদের জিজ্ঞাসা করা হয়েছিল যে তারা নতুন কোড লেখা এবং AI-তৈরি করা কোড যাচাই করার মধ্যে কীভাবে সময় ভাগ করে নেন। উত্তরদাতারা জানিয়েছেন যে, কোড রিভিউ করতে এখন প্রাথমিক তৈরির চেয়ে বেশি সময় লাগছে। তারা একটি প্রজেক্টে দুই থেকে চারটি ভিন্ন ভিন্ন AI অ্যাসিস্ট্যান্ট ব্যবহার করার কথাও জানিয়েছেন এবং ৭০% বলেছেন যে এই অভ্যাসটি এখন রুটিন হয়ে দাঁড়িয়েছে।
এই সংখ্যাগুলো একটি ক্রমবর্ধমান হতাশার প্রতিফলন ঘটায়: একটি একক, সর্বজনীন মডেল কয়েক সেকেন্ডের মধ্যে একটি ফাংশন লিখে দিতে পারে, কিন্তু এটি কোনো রেকর্ড বা প্রমাণ ছাড়াই ডেটা স্ট্রাকচার, এরর হ্যান্ডলিং এবং পারফরম্যান্স অপ্টিমাইজেশনের বিষয়ে গোপন সিদ্ধান্ত নিয়ে ফেলে। ডেভেলপারদের শেষ পর্যন্ত সেই সিদ্ধান্তগুলো রিভার্স-ইঞ্জিনিয়ারিং করতে হয়, যা একটি পুরো কাজের দিন শেষ করে দিতে পারে।
কেন একটি একক মডেল আর যথেষ্ট নয়
বছরের পর বছর ধরে সাধারণ ওয়ার্কফ্লোটি এমন ছিল: একজন ডেভেলপার একটি প্রম্পট টাইপ করতেন, মডেলটি একটি ফাইল তৈরি করত এবং ডেভেলপার সেটি কোডবেসে কপি করে নিতেন। এই পদ্ধতিটি দ্রুত ডেমো দেখানোর জন্য কার্যকর হলেও, প্রোডাকশন সফটওয়্যারের জন্য ওয়ান-শট আউটপুটের চেয়ে বেশি কিছু প্রয়োজন। উদাহরণস্বরূপ, যখন মডেলটি একটি অ্যারের পরিবর্তে লিঙ্কড লিস্ট ব্যবহার করার বা কোনো এরর (exception) নিঃশব্দে এড়িয়ে যাওয়ার সিদ্ধান্ত নেয়, তখন সেই সিদ্ধান্তগুলো কোডের ভেতরেই মিশে যায় এবং রিভিউয়ারের নজরের বাইরে চলে যায়।
যেহেতু মডেলের অভ্যন্তরীণ যুক্তিগুলো (internal reasoning) লগ করা হয় না, তাই কাজ শেষ হওয়ার পর টিমগুলো প্রশ্ন করে, "AI কেন এই প্যাটার্নটি বেছে নিল?" এর উত্তর পেতে প্রায়শই জেনারেট করা কমেন্টগুলো খুঁটিয়ে দেখতে হয়, ভিন্ন ভিন্ন temperature setting দিয়ে প্রম্পটটি পুনরায় চালাতে হয়, এমনকি পুরো জেনারেশন ধাপটি পুনরায় করতে হয়। এই অনিশ্চয়তা এখন জরিপে অতিরিক্ত রিভিউ আওয়ার হিসেবে দেখা দিচ্ছে।
কাজ ভাগ করে দেওয়া: মাল্টি-এজেন্ট সিস্টেম কীভাবে সাহায্য করে
মাল্টি-এজেন্ট সেটআপ একটি ছোট ডেভেলপমেন্ট টিমের অনুকরণ করে। একটি মডেল সব কিছু সামলানোর পরিবর্তে, আলাদা আলাদা এজেন্ট ভিন্ন ভিন্ন দায়িত্ব পালন করে:
- Architect agent: একটি হাই-লেভেল ডিজাইন ডকুমেন্ট তৈরি করে, ডেটা মডেল, API কন্ট্রাক্ট এবং এরর-হ্যান্ডলিং কৌশলের রূপরেখা প্রদান করে।
- Implementation agent: স্পেসিফিকেশনগুলোকে চেকলিস্ট হিসেবে ব্যবহার করে ঠিক আর্কিটেকচার অনুযায়ী কোড লেখে।
- Verification agent: শুধুমাত্র কোয়ালিটি অ্যাসুরেন্সের ওপর গুরুত্ব দিয়ে ইউনিট টেস্ট তৈরি করে, স্ট্যাটিক অ্যানালাইসিস চালায় অথবা CI/CD পাইপলাইন প্রস্তুত করে।
প্রতিটি এজেন্টের আউটপুট একটি স্বতন্ত্র আর্টিফ্যাক্ট (artifact), তাই কোনো সিদ্ধান্তের পেছনের যুক্তি সেই আর্টিফ্যাক্টটির মধ্যেই থাকে। কোডের কোনো লাইন লেখার আগেই আর্কিটেকচার রিভিউ করা একটি ত্রুটিপূর্ণ ডিজাইনের কারণে সৃষ্ট বাগ (bug) ঠিক করার চেয়ে অনেক কম ব্যয়বহুল। এই ট্রেসেবিলিটি (traceability) কমপ্লায়েন্স টিমকেও সন্তুষ্ট করে, যাদের দেখার প্রয়োজন হয় যে কোনো নির্দিষ্ট ইমপ্লিমেন্টেশন ডিটেইল কে (বা কী) নির্ধারণ করেছে।
মাল্টি-এজেন্ট ওয়ার্কফ্লোকে বাস্তবায়নযোগ্য করে তোলা টুলসসমূহ
ডেভেলপাররা ইতিমধ্যে বিভিন্ন ইউটিলিটির সমন্বয়ে এই পাইপলাইনগুলো তৈরি করছেন:
- IDE integrations এজেন্টদের সাইড প্যানেল হিসেবে প্রদর্শন করতে দেয়, যা একটি ক্লিকের মাধ্যমেই আর্কিটেকচার ডকুমেন্টটি কোড-জেনারেশন অ্যাসিস্ট্যান্টের কাছে পৌঁছে দেয়।
- CLI utilities স্ক্রিপ্টেড সিকোয়েন্স বা ধারাবাহিকতা নিশ্চিত করে: প্রথমে আর্কিটেক্ট রান করা, তার আউটপুট কোডারকে পাঠানো এবং তারপর ফলাফলটি টেস্টারকে প্রদান করা।
- Frameworks কাস্টম এজেন্ট তৈরির জন্য লাইব্রেরি প্রদান করে যা প্রজেক্টের প্রয়োজন অনুযায়ী পরিবর্তন বা প্রতিস্থাপন করা যায়।
- Specification-first platforms কোনো জেনারেশন শুরু করার আগে একটি আনুষ্ঠানিক রিকোয়ারমেন্ট ফাইল দাবি করে, যা নিশ্চিত করে যে ডিজাইন ধাপটি বাদ দেওয়া যাবে না।
জরিপের ৭০% পরিসংখ্যান নির্দেশ করে যে বেশিরভাগ টিম ইতিমধ্যে এই পাইপলাইনগুলোর অ্যাড-হক (ad-hoc) সংস্করণ তৈরি করে ফেলেছে। নতুন প্ল্যাটফর্মগুলো কেবল সেই কাজগুলোকেই আনুষ্ঠানিক রূপ দিচ্ছে যা ইঞ্জিনিয়াররা ম্যানুয়ালি করে আসছিলেন।
কারা লাভবান হবে—এবং কারা পিছিয়ে পড়বে
ফিন্যান্স বা হেলথকেয়ারের মতো কঠোর অডিট প্রয়োজনীয়তা মেনে চলতে বাধ্য প্রতিষ্ঠানগুলো অবিলম্বে এর সুবিধা পাবে। একটি নথিভুক্ত ডিজাইন-টু-কোড চেইন প্রোডাকশনে কোনো গোপন দুর্বলতা (vulnerability) ঢুকে পড়ার ঝুঁকি কমিয়ে দেয়। ছোট স্টার্টআপগুলোর ক্ষেত্রে একাধিক এজেন্ট রক্ষণাবেক্ষণের অতিরিক্ত খরচ অপ্রয়োজনীয় মনে হতে পারে, যদি তারা যথেষ্ট দ্রুত কাজ করতে পারে যাতে একটি একক মডেলের গতি মাঝেমধ্যে রিওয়ার্ক করার খরচের চেয়ে বেশি হয়।
A counter-argument notes that multi-agent systems add complexity. Coordinating three or more models can introduce integration bugs, increase latency, and require more sophisticated monitoring. Teams lacking the expertise to build or manage custom agents might spend more time on orchestration than on actual development. For those groups, a well-tuned single model—especially one that offers built-in explainability—could remain the pragmatic choice.
What to watch in the coming months
- Standardised logging formats for AI-generated artifacts could make it easier to compare outputs across different agents.
- Marketplace offerings that bundle architecture, coding and testing agents into a single subscription may lower the barrier for teams without in-house AI expertise.
- Regulatory guidance on AI-assisted code could push more organisations toward auditable, multi-step pipelines.
- Performance benchmarks that measure total development time—not just generation speed—will help teams decide whether the extra coordination overhead pays off.
The survey’s headline numbers tell a clear story: developers spend more of their week double-checking AI output than writing fresh code. Multi-agent workflows emerge as a direct response, offering traceability that turns “black-box” generation into a documented, reviewable process. Whether the added orchestration complexity justifies itself for every team remains to be seen, but the trend toward splitting AI responsibilities is already reshaping how software is built.