কেন এই পরীক্ষাটি গুরুত্বপূর্ণ
AI-চালিত কোড অ্যাসিস্ট্যান্টগুলো প্রায়শই টিমগুলোকে রিপোজিটরিতে একটি "rules" ফাইল রাখার সুযোগ দেয় এবং আশা করে যে মডেলটি প্রতিটি রিকোয়েস্টে এর নির্দেশাবলী মেনে চলবে। বাস্তবে মডেলটি ফাইলটি হয়তো কখনোই দেখতে পায় না, অথবা দেখতে পেলেও এর বিষয়বস্তু উপেক্ষা করতে পারে। Claude Code-এর একটি সাম্প্রতিক পরীক্ষা উভয় সমস্যাই প্রদর্শন করেছে। টুলটি নিঃশব্দে একটি 72 KB AGENTS.md ফাইলটি স্কিপ করেছিল; যখন একই ফাইলটির নাম পরিবর্তন করে CLAUDE.md করা হলো, তখন অ্যাসিস্ট্যান্টটি এটি লোড করল এবং প্রতিটি রিকোয়েস্টের জন্য টোকেন সংখ্যা বাড়িয়ে দিল। সেই অতিরিক্ত টোকেন বাজেট ল্যাটেন্সি (latency) এবং খরচ বাড়িয়ে দেয় এবং একটি রিকোয়েস্টকে মডেলের সীমার বাইরে ঠেলে দিতে পারে।
যেসব ডেভেলপার মনে করেন যে "ফাইলটি বিদ্যমান" মানেই "মডেলটি নিয়ম মেনে চলছে", তারা লুকানো অদক্ষতা এবং অপ্রত্যাশিত আউটপুটের ঝুঁকিতে থাকেন। এই তিন-ধাপের পরীক্ষাটি প্রতিটি পর্যায়ে সুনির্দিষ্ট প্রমাণ নিশ্চিত করে: কনফিগারেশন (configuration), লোডিং (loading), এবং উপযোগিতা (usefulness)।
জিজ্ঞাসা করার মতো তিনটি প্রশ্ন
- Configured (কনফিগার করা হয়েছে কি না) – ফাইলটি কি এমন জায়গায় রাখা হয়েছে যেখানে অ্যাসিস্ট্যান্ট এটি খোঁজে? বিভিন্ন টুল নির্দিষ্ট পাথ (path) বা ফাইলের নামের নিয়ম (filename conventions) ব্যবহার করে; অমিল থাকলে ফাইলটি প্রম্পট পাইপলাইনে কখনোই প্রবেশ করতে পারে না।
- Loaded (লোড করা হয়েছে কি না) – অ্যাসিস্ট্যান্ট কি ফাইলটি পেয়েছে তার কোনো প্রমাণ দেয়? একটি হ্যাশ (hash) ডিস্কে ফাইলের পরিচয় নিশ্চিত করতে পারে, কিন্তু শুধুমাত্র একটি ডেলিভারি ট্রেস (যেমন, একটি লগ লাইন বা টোকেন সংখ্যা) প্রমাণ করে যে মডেলটি আসলে এটি দেখেছে।
- Useful (উপকারী কি না) – ফাইলের উপস্থিতি কি কাজের ফলাফল উন্নত করে? একটি লোড করা ফাইল যা টোকেন বাড়ায় কিন্তু ফলাফল অপরিবর্তিত রাখে, তা আসলে একটি নিট লস (net loss)।
পরীক্ষাটি চালানো
পদ্ধতিটি ইচ্ছাকৃতভাবে অত্যন্ত সংক্ষিপ্ত রাখা হয়েছে যাতে এটি যেকোনো প্ল্যাটফর্মে পুনরাবৃত্তি করা যায়।
একটি দৃশ্যমান নিয়ম তৈরি করুন – একটি সহজ এবং পর্যবেক্ষণযোগ্য নির্দেশ লিখুন। উদাহরণস্বরূপ: “এডিট করার আগে ঠিক দুটি ফাইল তালিকাভুক্ত করুন।” অ্যাসিস্ট্যান্টের রেসপন্সে নিয়মের প্রভাব পরীক্ষা করা যেতে পারে।
টুলের ভার্সন এবং মডেল পরীক্ষা করুন – একটি নতুন সেশন খুলুন, ভার্সন স্ট্রিং এবং মডেল আইডেন্টিফায়ারটি নোট করুন। বিভিন্ন ভার্সন তাদের পরিচিত ফাইলের নাম পরিবর্তন করতে পারে।
দুটি রান (run) সম্পন্ন করুন Run A: এমন একটি ফাইলের নাম ব্যবহার করুন যা টুলটি চেনে না (যেমন, AGENTS.md)। Run B: টুলের নেটিভ (native) ফাইলের নাম ব্যবহার করুন (যেমন, CLAUDE.md)।
রেকর্ড করুন:
- ফাইলের সোর্স হ্যাশ (প্রমাণ করার জন্য যে ডিস্কের বিষয়বস্তু পরিবর্তন হয়নি)।
- ব্যবহৃত সঠিক পাথ (path)।
- ফাইল লোড করার বিষয়ে অ্যাসিস্ট্যান্টের লগ করা কোনো প্রমাণ (টোকেন সংখ্যা বৃদ্ধি, স্পষ্ট “loaded X.md” মেসেজ ইত্যাদি)।
- প্রতিটি রিকোয়েস্টের জন্য টোকেন সংখ্যা।
- কাজের ফলাফল (অ্যাসিস্ট্যান্ট কি ঠিক দুটি ফাইল তালিকাভুক্ত করেছে?)।
যদি Run B-তে দেখা যায় যে নিয়মটি মানা হচ্ছে এবং টোকেন সংখ্যা প্রত্যাশিত পরিমাণে বাড়ছে, তবে ফাইলটি লোড করা হয়েছে এবং এটি কার্যকর। যদি টোকেন বাড়ার পরেও নিয়মটি উপেক্ষা করা হয়, তবে ফাইলটি পড়া হচ্ছে কিন্তু মডেলের প্রম্পট পার্সিং (prompt parsing) নির্দেশটি বাদ দিচ্ছে। সেক্ষেত্রে, ফাইলে আরও টেক্সট যোগ করলে কোনো লাভ হবে না; পরিবর্তে নিয়মটিকে একটি হার্ড-কোডেড পলিসি গেট (hard-coded policy gate) বা একটি টেস্ট হার্নেসে (test harness) স্থানান্তর করুন।
ডেটা কী প্রকাশ করে
Claude Code-এর ঘটনাটি কনফিগারেশন এবং লোডিংয়ের মধ্যে একটি বিশাল ব্যবধান প্রদর্শন করেছে। 72 KB ফাইলটি বিদ্যমান ছিল, সঠিক হ্যাশ ছিল এবং রিপোজিটরির সাথে সিঙ্ক করা ছিল, তবুও অ্যাসিস্ট্যান্ট এটি কখনোই উল্লেখ করেনি। ফাইলটির নাম পরিবর্তন করে নেটিভ CLAUDE.md করার ফলে লোডিং শুরু হয়েছিল, কিন্তু এটি একটি উল্লেখযোগ্য টোকেন ওভারহেডও তৈরি করেছিল। প্রতিটি অতিরিক্ত টোকেন কম্পিউট সাইকেল (compute cycles) খরচ করে এবং রিকোয়েস্টকে রেট লিমিটের (rate limits) বাইরে ঠেলে দিতে পারে।
এই তিন-ধাপের পরীক্ষাটি এই ধরনের লুকানো খরচগুলো প্রোডাকশন ব্লকার (production blockers) হওয়ার আগেই সামনে নিয়ে আসে। টোকেন ডেল্টা (token delta) ক্যাপচার করার মাধ্যমে, টিমগুলো সিদ্ধান্ত নিতে পারে যে নিয়মের সুবিধা কি এর খরচের চেয়ে বেশি।
সারসংক্ষেপ
একটি রুল ফাইল রিপোজিটরিতে আছে বলেই সেটি কাজ করছে বলে কখনোই ধরে নেবেন না। সেই ধারণাটিকে পরিমাপযোগ্য প্রমাণের রূপ দিতে তিন-ধাপের পরীক্ষা—কনফিগার করুন, লোড করুন, উপযোগিতা প্রমাণ করুন—ব্যবহার করুন। যখন প্রমাণ দেখাবে যে একটি ফাইল কেবল একটি টোকেন সিঙ্ক (token sink), তখন লজিকটি প্রম্পট থেকে সরিয়ে একটি ডিটারমিনিস্টিক গেটে (deterministic gate) নিয়ে যান। এর ফলে একটি আরও স্লিম, দ্রুত এবং আরও অনুমানযোগ্য AI কোডিং ওয়ার্কফ্লো পাওয়া সম্ভব।