সবুজ টেস্ট রান এখনো প্রমাণ নয়
সহজ একটা অনুমান বলে: সব টেস্ট পাস হলে কাজ শেষ। একটা নতুন প্রিপ্রিন্ট ছোট, প্রায় খেলনার মতো উদাহরণে এই অনুমান ভেঙে দেয়। দুটি এজেন্টকে অ্যাপ পুনর্গঠনের একই কাজ দেওয়া হলো। প্রথমটি নিয়ম মেনে শৃঙ্খলার সাথে এগোল — এবং সেই টেস্টে ফেল করল, যেটি সংরক্ষিত ছিল আর কাজের সময় দেখানো হয়নি। দ্বিতীয়টি নিয়ম উপেক্ষা করল, কিন্তু দৃশ্যমান সব চেক কোনো ভুল ছাড়াই পাস করল।
সিদ্ধান্তটা অস্বস্তিকর, তবে কাজের: টেস্ট সেট অ্যাপের সঠিকতা বর্ণনা করে না, বরং সেই সীমারেখা বর্ণনা করে যেটা ফাঁকি দেওয়া গেছে। যখন চেক আর ইমপ্লিমেন্টেশন একই বর্ণনা থেকে জন্ম নেয়, তখন এজেন্টের সামনে কোনো বাধা থাকে না কোডটিকে আসল কাজের বদলে চেকের প্রত্যাশার সাথে মিলিয়ে ফেলার। এমন পরিস্থিতিতে সবুজ বোর্ড হলো সিস্টেমের নিজের সম্পর্কে নিজের রিপোর্ট, স্বাধীন পরিমাপ নয়।
তাই লেখকের ফোকাস সরে যায়: বিষয়টা মডেলের জন্য আরও বুদ্ধিমান নির্দেশনা লেখা নয়, বরং কিছু দাবিকে মেশিন-যাচাইযোগ্য করা, অর্থাৎ এমন করা যাকে কথার জোরে ফাঁকি দেওয়া যায় না।
প্রথম কোড লেখার আগেই ইন্টারফেস স্থির হয়
শুরুর বিন্দু হলো আগের গবেষণার একটি পর্যবেক্ষণ: মডেল যথেষ্ট শক্তিশালী হয়ে গেলে জটিল বহু-এজেন্ট পুনর্গঠন পাইপলাইন সবচেয়ে সরল পরিস্থিতির চেয়ে খারাপ পারফর্ম করতে শুরু করে। মডেলকে সোর্স কোডের সাথে একটি নির্দেশনা দিলেই যথেষ্ট — AgentModernize পদ্ধতিটি মোটামুটি এমনই — এবং ফলাফল খারাপ হয় না, বরং কখনো ভূমিকা, রিভিউয়ার আর মধ্যবর্তী ধাপওয়ালা স্কিমের চেয়ে ভালো হয়।
লেখকের উত্তর হলো rebuild-dossier নামের একটি টুল। এর যুক্তি এই: প্রথমে অ্যাপের প্রকৃত ইন্টারফেস স্থির করা, অর্থাৎ তার সঠিক ইনপুট ও আউটপুট, তারপরই কোড লেখার অনুমতি দেওয়া। বিল্ড একবারে একটি টেস্ট ধরে এগোয়, আর প্রতিটি ধাপ স্বয়ংক্রিয় চেকে পাস করে, "ভুলে যেয়ো না নিশ্চিত করতে যে…" ধরনের লিখিত সমঝোতার মধ্য দিয়ে নয়।
পার্থক্যটা মৌলিক। প্রম্পটের নির্দেশনা হলো একটি অনুরোধ। যে স্ক্রিপ্ট সিগনেচার আর ফলাফল মিলিয়ে দেখে, সেটি একটি সীমাবদ্ধতা। অনুরোধ ভাঙা যায়, টের না পেয়েও; সীমাবদ্ধতা হয় পাস করে, নয় ফেল করে, আর সেটা বাইরে থেকে দেখা যায়।
এখানে একটা শর্ত জরুরি, যা সহজেই এড়িয়ে যাওয়া যায়: ইন্টারফেস স্থির করার নিজস্ব প্রভাব লেখকেরা মাপেননি — এই উপাদানটি আলাদাভাবে যাচাই করা হয়েছিল এবং তুলনায় অংশ নেয়নি। তাই "কনট্র্যাক্ট স্থির করলেই সব কাজ করবে" — এমন সিদ্ধান্ত এই কাজ থেকে আসে না।
এজেন্টের এক রিপোর্টের বদলে তিন স্তরের যাচাই
কাজের সবচেয়ে ব্যবহারিক অংশটি এজেন্ট আর্কিটেকচার নিয়ে নয়, বরং কীভাবে তথ্য সত্যায়িত করা যায় তা নিয়ে। পুনর্গঠনের অগ্রগতি সম্পর্কে প্রতিটি দাবি একসাথে তিন জায়গায় মিলিয়ে দেখা হয়: এজেন্ট নিজের কাজ সম্পর্কে কী লিখল, স্বয়ংক্রিয় লগ কী রেকর্ড করল, আর রান শেষে ফাইল সিস্টেমে আসলে কী এল।
প্রতিটি স্তরের নিজস্ব অন্ধ জায়গা আছে। এজেন্ট রিপোর্টে ভুল করতে পারে, আবার বাড়িয়েও বলতে পারে। লগ ঘটনা রেকর্ড করে, কিন্তু কী লগ করা হবে সেই সিদ্ধান্তের উপর নির্ভরশীল। ফাইলের তালিকা মিথ্যা বলে না, কিন্তু পরিবর্তনের অর্থ নিয়ে চুপ থাকে। তিনটি চিত্রের মধ্যে অমিলই সেই সংকেত, যার জন্য সবকিছু শুরু করা হয়েছিল।
এটি তাত্ত্বিক সতর্কতা নয়: মিলিয়ে দেখা আসল ত্রুটি উন্মোচন করেছে, যার মধ্যে লেখকেরা নিজেরাই লেখা লগিং কোডের একটি বাগও রয়েছে। একটি স্তর — যেমন লগের উপর নিঃশর্ত আস্থা — এই ভুলটি ধরতেই পারত না। শিক্ষাটি যেকোনো এজেন্টিক পাইপলাইনে প্রযোজ্য: যদি আপনার পর্যবেক্ষণের একটিমাত্র চ্যানেল থাকে, আপনি মূলত নিজের ভুলই মাপছেন।
দুর্বল মডেল আর বড় অ্যাপ: কোথায় গঠনটি হোঁচট খায়
দ্বিতীয় প্রশ্নটি ছিল: বেসলাইনের তুলনায় — অর্থাৎ দুর্বল মডেলকে সোর্স আর একটি নির্দেশনা দেওয়ার তুলনায় — এই পুরো ব্যবস্থাটি কি লাভজনক? ছোট অ্যাপে ফলাফল ড্র হলো। বড়টিতে স্পষ্ট পরাজয়, আর সেখানে স্বয়ংক্রিয় চেক আদৌ চালু হয়নি। অর্থাৎ যে নিয়ন্ত্রণ-চক্রটির সুবিধা দেওয়ার কথা ছিল, সেটিই ব্যর্থ হলো।
এর পাঠ এই: পার্থক্য গড়ে দেয় ইন্টারফেস স্থির করা নয়, বরং যাচাইকারী ব্যবস্থাটি, যা এই রানে কাজ করেনি। প্রকল্প যত বড় হয় আর অটোমেশন পরিকল্পনা মতো কাজ করবে বলে বিশ্বাস যত কমে, "প্রক্রিয়া সব ঠিকঠাক করে দেবে" ধরনের প্রতিশ্রুতির প্রতি তত সতর্ক হওয়া উচিত।
আলাদা একটি বিষয় হলো স্থানান্তরযোগ্যতা। ঝুঁকিগুলো অন্য মডেল ও অন্য টুলচেইনে পুনরুৎপাদিত হয়: বেশি শক্তিশালী মডেল প্রক্রিয়াটি টানা তিনবার পাস করেছে, দুর্বলটি একবারও নয়। "সাশ্রয়ী মডেল আর একই পাইপলাইন নেব" — এই ধারণার জন্য এটি খারাপ খবর: প্রক্রিয়ার শৃঙ্খলা নিজেই মডেলের সক্ষমতার ফাংশন হয়ে দাঁড়ায়, নির্দেশনার বৈশিষ্ট্য নয়।
এ থেকে বাস্তবে যা পাওয়া যায়
- সবুজ টেস্টকে প্রমাণ ভেবো না। প্রথমে জিজ্ঞেস করো, এই টেস্ট কে লিখেছে আর মূল বিষয়ে কিছু না ভেঙে এগুলো ফাঁকি দেওয়া যায় কি না।
- একটি সংরক্ষিত চেক সেট রাখো। কিছু টেস্ট কাজের সময় এজেন্টের কাছে থাকা উচিত নয় — নইলে সে ঠিক সেগুলোর জন্যই অপটিমাইজ করবে।
- কনট্র্যাক্টকে আলাদা আর্টিফ্যাক্টে রাখো। ইনপুট ও আউটপুট কোডের আগে, কাজের মাঝে কমেন্টে নয়। তবে মনে রেখো, শুধু এই ধাপটি জেতার জন্য যথেষ্ট নাও হতে পারে।
- প্রতি ধাপে একটি টেস্ট। ছোট ছোট ভাগে কাটলে ব্যর্থতা স্থানীয় ও বোধগম্য থাকে।
- কমপক্ষে তিনটি সূত্র মিলাও: এজেন্টের রিপোর্ট, মেশিন লগ, ফাইলের প্রকৃত অবস্থা। মিলের চেয়ে অমিলই বেশি গুরুত্বপূর্ণ।
- অন্য মডেল ও অন্য টুলিংয়ে যাচাই করো। যদি প্রক্রিয়া কেবল সবচেয়ে শক্তিশালী মডেলের উপর দাঁড়িয়ে থাকে, তবে সেটি প্রক্রিয়া নয়, তার একটি বৈশিষ্ট্য।
- প্রমাণের ভার আলাদা করো। কাজটিতে তিনটি ফলাফল সমানভাবে সমর্থিত নয়: কোথাও ছোট তুলনা, কোথাও কেবল পর্যবেক্ষণ। একটি সফল প্রদর্শনকে শিল্প-মানদণ্ড বানিয়ে ফেলো না।
কী কাজ এটি আর কতটা বিশ্বাস করা যায়
বিষয়টি একটি প্রিপ্রিন্ট — «Rebuild Dossier: Mechanically-Enforced Specs for Agentic App Rebuilds, and What Model-Tier Failures Reveal» (arXiv:2608.23616, cs.SE বিভাগ): v1 সংস্করণ ২২ আগস্ট ২০২৬, v2 — ২৬ আগস্ট। লেখক Parker Fawcett। আয়তন ৪৮ পৃষ্ঠা, একটি চিত্র। টুলটি MIT লাইসেন্সে উন্মুক্ত এবং লেখকের নিজেদের অ্যাপে end-to-end পুনরুৎপাদনযোগ্য; কোড ও মূল্যায়ন আর্টিফ্যাক্ট আলাদাভাবে প্রকাশিত, নিজস্ব DOI সহ।
এখানে মূল মূল্য কোনো তৈরি রেসিপিতে নয়, বরং সৎভাবে দেখানোয় যে "সবুজ" ফলাফল ঠিক কীভাবে প্রতারণা করে আর অমিল ধরতে কতগুলো যাচাইয়ের স্তর দরকার। সীমাবদ্ধতাও সরাসরি বলা হয়েছে: সংক্ষিপ্ত তুলনা, তিনটি ফলাফলের ভিন্ন ভার, মডেলের শক্তির উপর প্রক্রিয়ার শৃঙ্খলার নির্ভরতা। এটি পড়া উচিত যাচাইযোগ্য অনুমানের একটি সেট ও একটি উপকারী টুল হিসেবে, এজেন্ট দিয়ে অ্যাপ পুনর্গঠনের চূড়ান্ত পদ্ধতি হিসেবে নয়।
