ক্লড কোডের সপ্তাহিক ক্ষমতা বাড়ানোর কারণে মনোযোগ আকর্ষণ করেছে, এবং নিবন্ধটি Agent প্রোগ্রামের টোকেন ব্যবহার পদ্ধতি বিশ্লেষণ করে। Agent-এর দীর্ঘসময়ের চলমান অবস্থা কার্যকরী সেটকে ধারাবাহিকভাবে বিস্তৃত করে, প্রতিটি পদক্ষেপে ইতিহাসের অবস্থা জমা হয়, এবং ক্যাশে মিলে গেলেও context-এর স্থান দখল করে, যার ফলে গণনার খরচ ধারাবাহিকভাবে বৃদ্ধি পায়। অতিরিক্ত পরিষ্কার করলে “সেম্যান্টিক পেজ ফল” ঘটে, যাতে Agent-কে পুনরায় তথ্য প্রাপ্তির প্রয়োজন হয়। নিবন্ধটি উল্লেখ করে যে, এই কোডের অবস্থা এবং ডিজাইনের অবস্থা সংরক্ষণের সঠিকতা-এর মধ্যে অসামঞ্জস্যতা AI-দ্বারা উৎপন্ন “পুরনো কোড”-এর দিকে পরিচালিত করতে পারে: পরবর্তী Agent-গুলি প্রাথমিক কোডের ডিজাইনের কারণ-প্রভাবকে বুঝতে অক্ষম, ফলস্বরূপ queue, bypass, retry-এর মধ্যে互相补偿-এর জটিল কোড গঠিত হয়।লেখক এবং উৎস: লেইফেঙ্গওয়েন
কোডটি প্রকৃতপক্ষে এজেন্ট দ্বারা লেখা হয়েছিল, কিন্তু পরবর্তী এজেন্টগুলি পূর্ববর্তী এজেন্ট কেন এটি লিখেছিল তা জানে না।
অগস্ট ১৯ তারিখে শেষ হওয়ার কথা ছিল এবং +50% সাপ্তাহিক কোটা বৃদ্ধি, এনথ্রোপিক দ্বারা অগস্ট ৩১ পর্যন্ত বাড়ানো হয়েছে। মূল সময়সীমার কাছাকাছি, হ্যাকার নিউজে ক্লাউড কোডের ব্যবহার খরচ নিয়ে আলোচনা শুরু হয়: অনেকেই দেখেছেন, একটি সহজ কাজও এজেন্টের কয়েকটি চক্রের পরেই কোটা দ্রুত শেষ হয়ে যায়।
সমস্যা হলো, Claude Code শুধু শেষে উত্পাদিত কয়েকটি লাইন কোড খরচ করে না। ফাইল পড়া, কল চেইন খোঁজা, টেস্ট চালানো, লগ প্রসেস করা—প্রতিটি ধাপই পরবর্তী কনটেক্সটে চলে যায়। কাজটি যত দীর্ঘ হবে, Agent-এর বহন করা ইতিহাস তত ভারী হবে, এবং সিস্টেমটিও পরিষ্কার ও সংকুচিতকরণের উপর তত বেশি নির্ভরশীল হবে।
কোডটি রিপোজিটরিতে সম্পূর্ণভাবে রাখা যেতে পারে, কিন্তু প্রাথমিক ডিজাইনের যুক্তি সংকুচিত হয়ে ধীরে ধীরে ক্ষয়প্রাপ্ত হতে পারে। ফলে টোকেন ব্যয় এবং কোড স্যাম একই জায়গায় মিলে যায়।
01 একটি ছোট বাগ ঠিক করতে কেন দরকার দশটি বার রিজনিং?
সাধারণ চ্যাট কোডিংয়ের গণনা সীমানা স্পষ্ট। একটি কোড সেকশন ইনপুট করুন, মডেলটি এটি পড়ে ব্যাখ্যা বা সংশোধনের প্রস্তাব দেয়, এবং এই চক্রটি প্রায় শেষ হয়ে যায়।
এবং ক্লড কোডের মৌলিক এককটি এজেন্ট লুপে পরিবর্তিত হয়েছে। মডেলটি বর্তমান অবস্থা পর্যবেক্ষণ করে, পরবর্তীতে কোন ফাইলটি পড়বে বা কোন কমান্ডটি বাস্তবায়ন করবে তা নির্ধারণ করে; টুলগুলি ফলাফল ফেরত দেওয়ার পরে, মডেলটি পরবর্তী পর্যায়ের সিদ্ধান্ত নেয়।
সোর্স কোড পড়া, রেফারেন্স খোঁজা, টেস্ট চালানো, Git diff দেখা, ফাইল পরিবর্তন করা — এগুলো একটি ধারাবাহিক ক্রিয়াকলাপের মতো দেখায়, কিন্তু মডেল পাশে এগুলো স্বতন্ত্র যুক্তি অনুরোধের একটি সিরিজ। Claude Code-এর অফিসিয়াল ডকুমেন্টেশন এই “মডেল বিচার—টুল কল—ফলাফলের ভিত্তিতে আবার বিচার” চক্রকে Agent-এর কাজের পদ্ধতির কেন্দ্রীয় বিষয় হিসেবে উপস্থাপন করে।
যেমন একটি লগইন স্ট্যাটাসের অস্থির ব্যর্থতার সমস্যা। এজেন্ট প্রথমে ইনপুট খুঁজে পায়, দেখে যে স্ট্যাটাসটি service থেকে আসছে, তাই service-এর কোড পড়তে শুরু করে; ক্যাশে দেখে কে এটি লিখছে তা খুঁজে বার করে; তারপর টেস্ট চালায়, টেস্টটি আরেকটি অস্বাভাবিকতা প্রকাশ করে, তাই fixture-এর দিকে তাকায়; ঠিক করার পর আবার যাচাই করে, পুরনো টেস্টটি আবার কম্প্যাটিবিলিটির সমস্যা প্রকাশ করে।
এটি হয়তো এই পর্যন্ত শুধুমাত্র সেই 몇 লাইন কোড লিখতে শুরু করেছে। তাই,diff আকার এবং গণনার মধ্যে প্রায় কোনও স্থিতিশীল অনুপাত নেই। 5 লাইনের প্যাচের পিছনে হয়তো শুধুমাত্র 3টি যুক্তি রয়েছে, অথবা 30টি টুল ইন্টারঅ্যাকশনের মাধ্যমে এটি পাস করেছে।
একটি এজেন্ট টাস্ককে বিভক্ত করলে, আমরা দুটি ভেরিয়েবল পাই: একটি হল step count, যা এজেন্ট টাস্কটি সম্পন্ন করতে কতগুলি ধাপ নিয়েছে; অন্যটি হল working set, যা বর্তমান ধাপে পৌঁছানোর সময় মডেলটিকে কতগুলি প্রোজেক্ট স্ট্যাটাস জানা দরকার।
শুধু স্টেপ কাউন্ট বাড়ানোই খরচ বাড়ায়। যদি ওয়ার্কিং সেটও সিঙ্ক হয়ে বড় হয়ে যায়, তাহলে অবস্থা সম্পূর্ণ ভিন্ন। ৩য় স্টেপে হয়তো শুধু কয়েকহাজার টোকেন প্রসেস করতে হবে, কিন্তু ৩০তম স্টেপে প্রজেক্টের নিয়ম, সংশ্লিষ্ট সোর্স কোড, টেস্ট রিজাল্ট, মডিফিকেশন হিস্ট্রি এবং টুলসের রিটার্ন নিয়ে আবার ইনফারেন্স করতে হতে পারে।
এটিই কোডিং এজেন্টের খরচ কাঠামোর পরিবর্তনের শুরু: গণনার পরিমাণ এখন “কত পদক্ষেপ নেওয়া হয় × প্রতিটি পদক্ষেপে কতটা ওজন বহন করা হয়”-এর উপর নির্ভর করে, যা কতগুলি লাইন কোড লেখা হয়েছে তার উপর নির্ভর করে না।
02 টোকেন ঠিক কোথায় পোড়ানো হয়?
এজেন্টের একটি মডেল অনুরোধকে তিনটি অংশে ভাগ করা যায়। স্থিতিশীল অংশগুলির মধ্যে রয়েছে system prompt, CLAUDE.md, টুল সংজ্ঞা এবং প্রকল্প নিয়ম; পরিবর্তনশীল অংশগুলির মধ্যে রয়েছে কোড ফাইল, অনুসন্ধানের ফলাফল, টেস্ট লগ, Git diff এবং আগের টাস্ক ট্রাজেক্টরি; এবং শেষে এই পর্যায়ে মডেল দ্বারা উত্পাদিত reasoning, টেক্সট এবং কোড।
এখানে একটি ভুল বোঝাবুঝি হওয়ার সম্ভাবনা রয়েছে: যদি আগের কনটেন্টটি ইতিমধ্যে পড়ে ফেলা হয়ে থাকে, তবে পুনরায় বেশি খরচ হওয়া উচিত নয়। সমস্যাটি হলো, LLM-এর দুটি অনুরোধের মধ্যে একটি প্রাচীন প্রোগ্রামের মতো যে যেকোনো সময় অ্যাক্সেসযোগ্য অভ্যন্তরীণ মেমোরি থাকে, তা নেই। আগের রাউন্ডে জানা তথ্য, যদি পরবর্তী রাউন্ডের সিদ্ধান্তের জন্য এটি নির্ভরশীল হয়, তবে সংশ্লিষ্ট অবস্থা এখনও উপলব্ধ context-এর মধ্যে থাকতে হবে।
প্রম্পট ক্যাশ এই সমস্যাটি কমিয়ে দেয়। Claude Code-এর অফিসিয়াল ডকুমেন্টে স্পষ্টভাবে উল্লেখ করা হয়েছে যে, প্রম্পট ক্যাশিং না থাকলে প্রতিটি রিকোয়েস্টে পুরো ইতিহাস পুনরায় প্রসেস করতে হয়; ক্যাশ হিট হলে, ইতিমধ্যে প্রসেস করা স্থিতিশীল প্রিফিক্সগুলি পুনরায় ব্যবহার করা যায়, যার ফলে পুনরাবৃত্তির গণনা এবং খরচ কমে।
কিন্তু ক্যাশে সমাধান করে “একই ইতিহাস কি আরও সস্তায় পুনঃব্যবহার করা যায়”, এটি সমাধান করে না যে “এই ইতিহাসটি আরও চলতে থাকা উচিত কি না”। 100K Token-এর পুরনো অবস্থা ক্যাশেতে মিলে গেলে এটি সস্তা হয়ে যায়, কিন্তু এটি এখনও context-এ জায়গা নেয় এবং বর্তমান যুক্তির ভিত্তি হয়ে থাকে।
সুতরাং একটি দীর্ঘ কাজকে প্রায় এভাবে লেখা যায়: পদক্ষেপ t-এর ইনপুট আকার প্রায় স্থিতিশীল প্রিফিক্স S এবং বর্তমান কার্যকরী ওয়ার্কসেট W_t এবং এই চক্রে তৈরি হওয়া নতুন তথ্য Δ_t-এর সমষ্টি।
সত্যিই সমস্যা হল W_t। প্রতিটি পদক্ষেপে, যদি এজেন্ট আরও কিছু সোর্স কোড পড়ে, আরও কিছু লগ পায়, আরও একটি সিদ্ধান্ত রাখে, এবং পুরনো তথ্যগুলি সময়মতো সরিয়ে ফেলা না হয়, তবে W_t কাজের প্রগতির সাথে সাথে বৃদ্ধি পাবে।
একটি চরমভাবে সরলীকৃত, কোনও ক্যাশ বা পরিষ্কার নেই এমন মডেলে, যদি প্রতিটি পর্যায়ে যোগ হওয়া কার্যকরী অবস্থা প্রায় একই থাকে, তবে মোট প্রক্রিয়াকরণ প্রায় 1 + 2 + 3 + … + n এর সঞ্চয়ী গঠন দেখাবে। অর্থাৎ, step count শুধুমাত্র দ্বিগুণ বৃদ্ধি পেলেও, সম্পূর্ণ টাস্কটি প্রক্রিয়াকৃত ইতিহাসবহুল অবস্থা আরও দ্রুত বৃদ্ধি পেতে পারে।
বাস্তব সিস্টেমে ক্যাশে, কনটেক্সট এডিটিং এবং কমপ্যাকশন রয়েছে, তাই এই বৃদ্ধির বক্ররেখা অনুসরণ করা হয় না, কিন্তু সমস্যার আকৃতি অপরিবর্তিত রয়েছে: এজেন্ট যত বেশি সময় চলে, প্রতিটি নতুন কার্য তত বেশি ভারী ইতিহাসের উপর ভিত্তি করে গঠিত হয়।
তাই দীর্ঘ কাজের মধ্যে খুব ছোট ব্যবহারকারীর প্রম্পট দ্রুত অস্তিত্বহীন হয়ে যায়। প্রকৃতপক্ষে, খরচকে প্রভাবিত করছে মডেলটি কাজের ধারাবাহিকতা বজায় রাখতে নিয়মিত বহন করা ওয়ার্কসেট।
03 খুব বেশি মুছে ফেললে অর্থগত অভাব দেখা দেবে
কেন ওয়ার্কিং সেট এত দ্রুত বৃদ্ধি পাচ্ছে, টুলের আউটপুট একটি বড় উৎস। সোর্স কোডে কমপক্ষে কাঠামো আছে, কিন্তু লগগুলোর প্রায়শই কাঠামো থাকে না।
একবার grep একাধিক শত রেফারেন্স ফেরত দিতে পারে, একটি বিল্ড সম্ভবত অসংখ্য ওয়ার্নিং দিতে পারে, একটি টেস্ট ফেইল হলে সম্পূর্ণ স্ট্যাক ট্রেস সহ আসতে পারে, Docker, কম্পাইলার, এবং প্যাকেজ ম্যানেজারও অনেক টেক্সট তৈরি করে যা কাজের দীর্ঘমেয়াদী মূল্য রাখে না।
ধরুন, 10ম ধাপের পরীক্ষা 8K টোকেন লগ উৎপন্ন করেছে। এটি প্রথমবারের মতো context-এ প্রবেশ করলে শুধুমাত্র 8K টোকেন ছিল। কিন্তু Agent-এর আরও সোর্স কোড চেক, সংশোধন এবং পুনরায় পরীক্ষা করতে হবে; যতক্ষণ এই লগটি বৈধ ইতিহাসে থাকবে, এটি পরবর্তী অনেকগুলি অনুরোধের ভিত্তিগত ওজন বাড়িয়ে দেবে।
এটি স্টোরেজ সিস্টেমের লিখন অ্যাম্প্লিফিকেশনের মতো: একটি যুক্তিসঙ্গত লিখন পরবর্তী অধিক নিম্নস্তরের প্রক্রিয়াকরণকে সৃষ্টি করে। এজেন্টের ক্ষেত্রে, একটি টুল আউটপুট এক্সিকিউশন হিস্টোরিতে লেখা হয়, এবং পরবর্তী যুক্তির সাথে এটি সরানো হয়।
অতএব, 8K টোকেন একই হলেও, এটিকে টাস্ক শেষের আগের রাউন্ডে রাখা এবং টাস্ক শুরুর সময় রাখা দুটির মোট প্রভাব সম্পূর্ণ ভিন্ন। Claude Code এখন এই দূষণকে সক্রিয়ভাবে কমাচ্ছে। অফিসিয়াল সুপারিশ করা হয়েছে যে উচ্চ-আউটপুট টাস্কগুলি সাব-এজেন্ট দ্বারা বিচ্ছিন্ন করা হোক, এবং এটি স্পষ্টভাবে উল্লেখ করা হয়েছে যে সার্চ রেজাল্ট, লগ এবং বহুল ফাইলের কন্টেন্ট মেইন সেশনের context খরচ করে; টুলের সংজ্ঞা নিজেই জায়গা নেয়, তাই টুলসেটটি খুব বড় হলেও স্টেটের বোঝা বাড়ে।
কিন্তু এখানে একটি বিপরীত সমস্যা দেখা দিচ্ছে: লগগুলি খুব ব্যয়বহুল হওয়ার কারণে সবগুলিকেই বাদ দেওয়া যাবে না। ৩০০০ লাইনের একটি লগের মধ্যে মাত্র ২০ লাইনই মূল কারণের সাথে সম্পর্কিত হতে পারে। সিস্টেম আগে থেকেই জানতে পারে না যে কোন ২০ লাইনগুলি। যদি খুব আগেই পরিষ্কার করে ফেলা হয়, তাহলে Agent-এর পরবর্তীতে যদি একটি বিস্তারিত তথ্যের প্রয়োজন হয়, তবে এটিকে পুনরায় টেস্ট চালাতে বা ফাইলটি পুনরায় খুলতে হবে।
এটিকে সেম্যান্টিক পেজ ফল্ট বলা যেতে পারে। পারম্পরিক ভার্চুয়াল মেমোরির মধ্যে, প্রোগ্রাম একটি মেমোরির বাইরে থাকা পেজে অ্যাক্সেস করলে সিস্টেম ডিস্ক থেকে পুনরায় লোড করে; কোডিং এজেন্ট কিছু প্রাচীন প্রমাণ বাদ দিলেও একই ধরনের ঘটনা ঘটে, শুধুমাত্র এটি রিপোজিটরি খোঁজা, ফাইলগুলি পুনরায় পড়া, কমান্ডগুলি আবার চালানো, বা ইতিমধ্যেই বিশ্লেষণ করা একটি সমস্যা পুনরায় উপস্থাপনের মাধ্যমে প্রকাশ পায়।
এতে দীর্ঘ কাজটি একটি দ্বিধাগ্রস্ত অবস্থায় পড়ে: অতিমাত্রায় ইতিহাস রাখলে পরবর্তী প্রতিটি পদক্ষেপ আরও ভারী হয়ে যায়; অত্যধিক ক্লিনআপ করলে, এজেন্ট বারবার আগের দেখা তথ্যগুলি পুনরায় পায়।
এটি ব্যাখ্যা করে যে কেন context ম্যানেজমেন্টকে “কম Token ঢোকানো” এর মতো সরল করা যায় না। প্রকৃতপক্ষে সমাধান করা দরকার হচ্ছে working set selection: এখন কোন তথ্যগুলি কাজের ক্ষেত্রে রাখা প্রয়োজন, আর কোনগুলি শুধুমাত্র ইতিমধ্যে তাদের লক্ষ্য পূরণ করেছে এমন মধ্যবর্তী ফলাফল।
এখানেই কমপ্যাকশন, মেমোরি এবং সাব-এজেন্টের প্রকৃত অস্তিত্বের কারণ প্রকাশ পায়।
04 কোন তথ্য ভুলে যাওয়া যাবে?
ক্লড কোড কনটেক্সট সীমার কাছাকাছি আসলে স্বয়ংক্রিয়ভাবে সেশনটি সংকুচিত করে, এবং কিছু পুরানো টুল ফলাফলও পরিষ্কার করে। অফিসিয়ালি সতর্ক করা হয়েছে যে, দীর্ঘ সেশনের অসম্পর্কিত কথোপকথন, ফাইল কনটেন্ট এবং কমান্ড ফলাফল উইন্ডোটি পূর্ণ করে ফেলতে পারে এবং মডেলের পারফরম্যান্সকে বাধা দিতে পারে।
সিস্টেমের দৃষ্টিকোণ থেকে, compaction একটি বৈষম্যপূর্ণ গার্বেজ কালেকশনের মতো। সমস্যা হলো, সাধারণ গার্বেজ কালেকশন বিচার করে “এই অবজেক্টটির আর কোনো রেফারেন্স আছে কি না”, কিন্তু Agent-এর জন্য বিচার করতে হবে “এই তথ্যটির ভবিষ্যতে কোনো অর্থ থাকবে কি না”。
পরবর্তীটি অনেক বেশি কঠিন। উদাহরণস্বরূপ, প্রাথমিক পর্যায়ে একটি ডিজাইন উপসংহার ছিল: কোনো মডিউল নিজেই ব্যবহারকারীর অবস্থা ক্যাশে করতে পারবে না, কারণ সিস্টেম চায় যে অবস্থার একটিই মালিক থাকবে, এবং সমস্ত পরিবর্তন service-এর মধ্যে দিয়েই হতে হবে।
কয়েক ধাপ পরে, যদি এই তথ্যটিকে চাপিয়ে এমনভাবে প্রকাশ করা হয়: “আগে service এর মাধ্যমে স্ট্যাটাস সমস্যা সমাধান করা হয়েছিল।” এটি সত্য হতে পারে, কিন্তু তথ্যটি পরিবর্তিত হয়ে গেছে। মূল বিষয়বস্তুতে constraint ছিল, যখন পরবর্তী সারসংক্ষেপে শুধুমাত্র event সংরক্ষিত হয়েছে।
পরবর্তী বার এজেন্ট পারফরম্যান্স সমস্যা দেখলে, সার্ভিস কল ধীর দেখলে, সম্ভবত আবার মডিউলে ক্যাশ যোগ করবে। এটি এখন পর্যন্ত যা জানে তার বিরুদ্ধে কোনো লঙ্ঘন করছে না; ক্যাশ নিষিদ্ধের কারণ-প্রভাব এখন কার্যকর নয়।
ক্লাউড কোডের কনটেক্সট ডকুমেন্টে স্পষ্টভাবে উল্লেখ করা হয়েছে যে, কিছু path-scoped নিয়ম এবং নেস্টেড CLAUDE.md ফাইলগুলি সেশনের সাথে কমপ্যাকশন সামারিত হয়ে যায়, এবং পুনরায় লোড করতে হলে ম্যাচিং ফাইলগুলি আবার পড়তে হয়।
মেমোরি দীর্ঘমেয়াদী জ্ঞান সংরক্ষণের সমস্যা সমাধান করার চেষ্টা করে। প্রকল্পের রুট ডিরেক্টরিতে থাকা CLAUDE.md এবং auto memory বিল্ড কমান্ড, প্রকল্প স্পেসিফিকেশন, ডিবাগিং অভিজ্ঞতা ইত্যাদি সংক্ষিপ্ত কথোপকথন থেকে বের করে সেশন শুরুতে পুনরায় লোড করে। তবে Anthropic এটির অবস্থানও পরিষ্কারভাবে উল্লেখ করেছে: এই memoryগুলি এখনও context, বাধ্যতামূলক কনফিগারেশন নয়।
এই পার্থক্যটি অত্যন্ত গুরুত্বপূর্ণ। "এখানে ডেটাবেসে সরাসরি অ্যাক্সেস করা যাবে না" শুধুমাত্র মেমোরিতে লিখলে, এটি এখনও একটি মডেলকে বুঝতে এবং অনুসরণ করতে হবে এমন প্রাকৃতিক ভাষা। যদি একই নিয়মটি dependency lint, টাইপ কনস্ট্রেইন্ট বা CI চেক হিসেবে লেখা হয়, তবেই এটি একটি অক্ষমভাবে পার করা যায় এমন সফটওয়্যার invariant-এ পরিণত হয়।
সাব-এজেন্ট অন্য একটি বিষয় সমাধান করে: কাজের সেট পৃথককরণ। একটি স্বতন্ত্র এজেন্টকে রিপোজিটরি স্ক্যান করতে বা দীর্ঘ লগ বিশ্লেষণ করতে বলে, তারপর সংকুচিত ফলাফলটি মূল এজেন্টকে ফিরিয়ে দেওয়া হয়, যাতে মূল থ্রেডে মূল শব্দ প্রবেশ না করে। Claude Code-এর অফিসিয়াল সাব-এজেন্টের ব্যবহারের মধ্যে একটি হল context isolation।
এর খরচও আকর্ষণীয়: মূল এজেন্ট পেয়েছে পরিষ্কার অবস্থা, কিন্তু কিছু মূল প্রমাণ হারিয়েছে; একাধিক এজেন্ট একসাথে চললে তারা নিজেদের কনটেক্সট তৈরি করে। তাই compaction, memory, sub-agent কে একসাথে দেখলে, এটি আসলে এজেন্ট যুগের একটি মেমোরি হায়ারার্কির মতো:
বর্তমান কনটেক্সট হল মহাঙ্গা কার্যকরী মেমোরি, কমপ্যাকশন সংকুচিতকরণের জন্য দায়ী, মেমোরি সেশন-পারিপার্শ্বিক অবস্থা সংরক্ষণ করে, এবং সাব-এজেন্ট একক ঠিকানা স্পেস ব্যবহার করে শব্দকে বিচ্ছিন্ন করে। সমস্যাটি “কনটেক্সট যথেষ্ট বড় কি” থেকে আরেকটি স্তরে পরিণত হয়েছে:
কোন অবস্থাগুলির জন্য উচ্চ বিশ্বস্ততা সহ সংরক্ষণ প্রয়োজন এবং কোন অবস্থাগুলির জন্য শুধুমাত্র সারাংশ রাখা প্রয়োজন—এই প্রশ্নটি পরবর্তী কোডের মানকে প্রত্যক্ষভাবে প্রভাবিত করবে।
05 কতক্ষণ চলবে তা পূর্বে পূর্বানুমান করা যায় না
পূর্বের এই এক্সিকিউশন স্ট্রাকচারটি বুঝার পরে, ক্লড কোডের সাপ্তাহিক কোটা দেখলে বুঝতে পারবেন যে প্ল্যাটফর্মটি আর বার্তার সংখ্যা অনুযায়ী এজেন্টকে মাপতে পারবে না, কারণ একটি বার্তা এখন স্থিতিশীল অর্থ হারিয়েছে।
একটি ভেরিয়েবলের নাম পরিবর্তন করা একটি মেসেজ, আবার সম্পূর্ণ অথেন্টিকেশন মডিউল পুনর্গঠন করা আরেকটি মেসেজ। প্রথমটি কয়েকটি ধাপে শেষ হতে পারে, আর দ্বিতীয়টি ডজন পাঁচেক রান চালাতে পারে, ডজন পাঁচেক ফাইল পড়তে পারে, আর একাধিক Agent শুরু করতে পারে। একই রিকোয়েস্টের পিছনে যে সম্পদের চাহিদা থাকে, তা সম্পূর্ণভাবে একই মাত্রার নয়।
ক্লড কোড এই বিষয়টিকে স্ক্রোলিং সীমা এবং সাপ্তাহিক কোটা দিয়ে প্যাকেজ করে; কোডেক্স এখন প্রবেশ টোকেন, ক্যাশড প্রবেশ টোকেন এবং আউটপুট টোকেন অনুযায়ী ক্রেডিট গণনা করে; কার্সরের প্যাকেজগুলি Agent-এর জন্য বিভিন্ন ব্যবহার পুল প্রদান করে, এবং তৃতীয় পক্ষের মডেলের ব্যবহার মডেল API-এর মূল্যের উপর নির্ভর করে।
তিনটি পণ্যের ইন্টারফেসের ভাষা ভিন্ন, কিন্তু নীচের সমস্যাগুলি খুব কাছাকাছি: একটি স্মার্ট প্রোগ্রামকে কীভাবে বরাদ্দ করা যায় যেখানে এক্সিকিউশন পাথটি পূর্বে নির্ধারিত হয়নি। একটি Coding Agent কতক্ষণ চলবে, তা কাজ শুরুর সময় খুব কঠিন।
মডেলটি দ্রুত মূল কারণ খুঁজে পেতে পারে, অথবা কয়েকটি ভুল অনুমান করতে পারে; একটি টেস্টেই সফল হতে পারে, অথবা দীর্ঘসময়ের ডিবাগ লুপে পড়তে পারে; একটি এজেন্টই যথেষ্ট হতে পারে, অথবা কয়েকটি সাব-এজেন্টে বিভক্ত হতে পারে।
প্রাচীন API রিকোয়েস্ট অনুযায়ী চার্জ করে কারণ একটি রিকোয়েস্টের সম্পদের ওতপ্রোত পরিবর্তন কিছুটা নিয়ন্ত্রিত থাকে। এজেন্ট এই স্থিতিশীলতাকে ভেঙে দেয়। তাই এখানে টোকেনটি কিছুটা CPU সময়ের মতো হয়ে উঠছে।
এই তুলনাটিকে সমান হিসাবে বিবেচনা করা যাবে না। বিভিন্ন মডেল একই সংখ্যক টোকেন প্রক্রিয়াকরণের জন্য ভিন্ন ক্যালকুলেশন খরচ বহন করে, এবং input, cached input এবং output-এর খরচও ভিন্ন। তবে ডেভেলপারদের দিক থেকে, তাদের কার্যকারিতা একেবারে অনুরূপ হয়ে আসছে: এগুলি সবই একটি টাস্ককে চালিয়ে যাওয়ার জন্য কতটা ক্যালকুলেশন সম্পদ ব্যবহার হচ্ছে, তা বর্ণনা করছে।
এনথ্রোপিক এই বছর ক্লড কোডের ব্যবহারের সীমা বাড়ানোর সময়, তারা সরাসরি কোটা বৃদ্ধি এবং অতিরিক্ত কম্পিউট ক্ষমতা যোগ করেছে। এটি একটি আকর্ষণীয় মেট্রিকের পরিবর্তন আনবে। আগে কোডিং এজেন্ট দেখার সময়, সহজেই তুলনা করা হত “একই প্রশ্নের জন্য কে একবারে ভালোভাবে লিখেছে।” এখন থেকে, সম্ভবত আরও গুরুত্বপূর্ণ হবে: একই ইঞ্জিনিয়ারিং অবস্থার পরিবর্তন সম্পন্ন করতে, কে কম কার্যকরী গণনা ব্যবহার করেছে।
যদি একটি এজেন্ট ব্যাপক পরিমাণ টোকেন ব্যয় করে শুধুমাত্র ফাইল খোলা, পুনরায় টেস্ট চালানো এবং হারিয়ে যাওয়া কনটেক্সট পুনরুদ্ধার করে, তাহলে সেই টোকেনগুলি প্রকৌশল অগ্রগতির সমান মানের ফলাফল অর্জন করেনি।
এবং এই অকার্যকর অবস্থা পুনরুদ্ধার ঠিক পরবর্তী স্তরে প্রযুক্তিগত ঋণের সাথে মিলে যায়।
06 এআই প্রাচীন কোড কিভাবে গঠিত হয়
এখানে একটি Coding Agent দ্বারা রক্ষিত সফটওয়্যারকে দুটি একসাথে বিকশিত অবস্থায় সাজানো যায়। একটি হল কোড অবস্থা R_t। ফাইল, টাইপ, ইন্টারফেস, টেস্ট, Git commit সবই এই স্তরের। Agent-এর ২০তম পদক্ষেপে যোগ করা একটি retry লাইন, যদি এটি মুছে না ফেলা হয়, তবে ১০০তম পদক্ষেপে ফাইলটি খুললেও এটি পুরোপুরি বিদ্যমান থাকবে। কোডটি অতীতের পরিবর্তনগুলির জন্য অত্যন্ত উচ্চ সংশোধন সংরক্ষণ করে।
অন্যটি হল ডিজাইন স্টেট M_t। এখানে retry কেন প্রয়োজন, কেন সেই ক্যাশে শুধুমাত্র service-এ রাখা যায়, কেন এই স্টেটের দুটি owner হতে পারে না, কেন একটি অপ্রয়োজনীয় মনে হওয়া জজমেন্ট এখনও মুছে ফেলা যায় না—এই তথ্যগুলি ডিজাইনের কারণ-প্রভাব সম্পর্কিত।
M_t এটি জিটের মতো প্রাকৃতিকভাবে ক্ষতিহীন সংরক্ষণ করে না। এটি সংলাপ, যুক্তিসঙ্গত, টুল রিটার্ন, মেমরি, নিয়ম ফাইল এবং কমপ্যাকশন সামারিতে ছড়িয়ে পড়ে। কাজ এগিয়ে যাওয়ার সাথে সাথে, কিছু অংশ পরিষ্কার করা হয়, কিছু অংশ সারাংশ হয়, আবার কিছু অংশকে পুনরায় খুঁজে বের করতে হয়।
এর ফলে একটি অত্যন্ত গুরুত্বপূর্ণ অসমতা তৈরি হয়: ফলাফলগুলি উচ্চ-বিশ্বস্ততার সাথে সঞ্চিত হয়, কিন্তু এই ফলাফলগুলির কারণ-প্রভাব সম্পর্কগুলি নিয়মিত নমুনা হ্রাস পায়। এটি শুধু “এজেন্ট বিষয়গুলি ভুলে যায়” বলার চেয়ে অনেক বেশি গুরুতর।
একটি সমান্তরাল সমস্যার ক্ষেত্রে, এজেন্ট বিশ্লেষণের পর একটি কিউতে যোগ হয়েছিল। তখন এর পূর্ণাঙ্গ সিদ্ধান্ত ছিল: কেবলমাত্র লেখা পথ A-এ প্রতিযোগিতা রয়েছে, তাই কিউটি শুধুমাত্র A-কে আটকাতে পারে; লেখা পথ B-এর নিম্ন ল্যাটেন্সির প্রয়োজন, এটি এই কিউতে প্রবেশ করতে পারে না।
কোডটি queue-কে সম্পূর্ণভাবে সংরক্ষণ করেছে। দীর্ঘ সময় ধরে চালানোর পরে, ডিজাইন স্টেট শুধুমাত্র “এখানে race condition সমাধানের জন্য queue ব্যবহার করা হয়েছে” হয়ে থাকতে পারে।
পরে B-এও একটি অস্থায়ী ত্রুটি দেখা দেয়। এজেন্ট আবার কোডটি পড়তে গিয়ে স্বাভাবিকভাবেই B-কে বর্তমান queue-এর সাথে যুক্ত করে দেয়।
পরে দেরি বেড়ে যায়, তাই বাইপাস যোগ করা হয়। বাইপাস আবার কখনও কখনও অবস্থার অসামঞ্জস্যতা তৈরি করে, তাই বাইরে retry যোগ করা হয়। এখানে পৌঁছানোর পর, কোনও পরিবর্তনই অবশ্যই অযৌক্তিক নয়। প্রতিটি প্যাচ তখনকার স্থানীয় অবস্থার ভিত্তিতে এমনকি যথেষ্ট যুক্তিসঙ্গতও বলে মনে হতে পারে। কিন্তু কোডটি এখন “একটি স্পষ্ট সমান্তরাল মডেল” থেকে queue, bypass এবং retry-এর পরস্পরের পূরকে পরিণত হয়েছে।
এই ধরনের এআই কোড স্ল্যাগ এভাবেই তৈরি হয়েছে। এটি অবশ্যই মডেলটি হঠাৎ করে একটি বিশৃঙ্খলা লিখে ফেলার মতো প্রকাশ পায় না, বরং স্থানীয়ভাবে সঠিক বিষয়গুলির ধারাবাহিক সঞ্চয়ের মাধ্যমে, সামগ্রিক মডেলটি ধীরে ধীরে অদৃশ্য হয়ে যায়।
প্রায়শই এই ধরনের সমস্যা পারস্পরিক হস্তান্তরের মাধ্যমে প্রাচীন সফটওয়্যারে ধীরে ধীরে গড়ে ওঠে। মূল লেখক চলে যান, নতুন ডেভেলপাররা পুরনো কোড দেখেন, কিন্তু জানেন না এটি কেন অস্তিত্ব রাখে, তাই তারা বাইরে আরেকটি সামঞ্জস্যপূর্ণ লজিক যোগ করেন।
কোডিং এজেন্ট "পার্সোনেল ট্রানজিশন" কে "কনটেক্সট ট্রানজিশন" এ পরিণত করেছে। ২০তম এবং ১০০তম পদক্ষেপ এখনও একই Claude Code সেশন হিসাবে দেখাচ্ছে, কিন্তু তারা বাস্তবে ভিন্ন ডিজাইন স্টেট পেয়েছে। তথ্যের দিক থেকে, এটি মনে হয় দুজন ইঞ্জিনিয়ার একটি ধীরে ধীরে কমে যাচ্ছে এমন হস্তান্তর ডকুমেন্টের মাধ্যমে একই রিপোজিটরি বজায় রাখছে।
পরীক্ষা শুধুমাত্র কিছু অংশ সমাধান করতে পারে। পরীক্ষা আচরণ সুরক্ষিত রাখতে দক্ষ: ইন্টারফেসটি কী ফেরত দেবে, কোন ইনপুট ক্রাশ করবে না, পূর্বের বাগগুলি আবার দেখা দেবে না। অনেক আর্কিটেকচারাল সীমাবদ্ধতা স্বাভাবিকভাবেই ইনপুট-আউটপুট হিসাবে প্রকাশিত হয় না।
অবস্থা শুধুমাত্র একজন মালিক রাখতে পারে, ডোমেইন লেয়ার ইউআই-এর দিকে বিপরীত নির্ভরশীলতা রাখতে পারে না, কোনো প্যাকেজ সরাসরি ডাটাবেসের সাথে সংযুক্ত হতে পারবে না, লিখন অপারেশনগুলি অবশ্যই একটি একক ট্রানজেকশন বর্ডারের মধ্যে দিয়ে যাওয়া উচিত—এই সীমাবদ্ধতাগুলি যদি শুধুমাত্র দলিলে বা এজেন্টের মেমোরিতে থাকে, তবে স্থানীয় ঠিক করার সময় এগুলি সহজেই উপেক্ষা করা হয়।
একটি খুব জটিল ইঞ্জিনিয়ারিং অবস্থা দেখা দেবে: টেস্ট এখনও সবুজ, কিন্তু কোডটি আরও কঠিন হয়ে উঠছে। এটি আরও বিপজ্জনক যে, এখানে ফিডব্যাক লুপ রয়েছে।
আর্কিটেকচার বিশৃঙ্খল হয়ে আসছে, এজেন্টের পরবর্তী বুঝতে আরও বেশি ফাইল পড়তে হবে; ডিপেনডেন্সি যত জটিল হবে, ওয়ার্কিং সেট তত বড় হবে; ওয়ার্কিং সেট যত ভারী হবে, সিস্টেম তত বেশি পরিষ্কার ও কম্প্রেস করার প্রয়োজন হবে; ডিজাইনের কারণ-প্রভাব যত পাতলা রাখা হবে, পরবর্তী মডিফিকেশনগুলি তত বেশি বর্তমান কোড এবং লোকাল টেস্টের উপর নির্ভরশীল হবে।
এতে কোডের জটিলতা বাড়তে থাকে, যা টোকেন খরচ বাড়ায়, আবার টোকেনের চাপ আবার সংক্ষিপ্ত অবস্থা ধরে রাখার এবং স্থানীয় মেরামতের প্রতি উৎসাহিত করে। এটিই Agent coding-এ “যত বার ইটারেশন করছেন, তত বেশি সমস্যা” হওয়ার পিছনের বেশি সতর্কতার প্রয়োজনীয় কারণ।
এটি একটি একক মডেল ক্ষমতার সমস্যা নয়, বরং একটি সিস্টেম সমস্যা যেখানে কোড অবস্থা এবং ডিজাইন অবস্থার সংরক্ষণের স্থিতিশীলতা অসামঞ্জস্যপূর্ণ ।
07 এজেন্টকে «স্ট্যাটাস ফিডেলিটি» প্রয়োজন
কোডিং এজেন্ট এখন দীর্ঘ সময় ধরে কাজ করতে পারে, কিন্তু "কয়েক ঘন্টা চলা" নিজেই অবশ্যই একটি ভালো ক্ষমতার মাপকাঠি নয়।
যদি একটি এজেন্ট 3 ঘন্টা কাজ করার পর নিজের 2 ঘন্টা আগে সংশোধন করা ফাইলটি আবার পড়ে, কিছু বিমূর্ত বিষয়ের অস্তিত্ব নিয়ে আবার যুক্তি দেয়, এবং আগেই চালানো পরীক্ষাগুলো আবার চালায়, তাহলে সেই 3 ঘন্টার অংশবিশেষ পরিস্থিতি পুনরুদ্ধারের উপর ব্যয়িত হয়।
পরবর্তী প্রশ্ন হবে: 50 পদক্ষেপ, 100 পদক্ষেপের পর একটি এজেন্ট কতটা কারণ-প্রভাব তথ্য সংরক্ষণ করতে পারে যা পরবর্তী সিদ্ধান্তের জন্য গুরুত্বপূর্ণ।
এটিকে স্ট্যাটাস ফিডেলিটি বলা যেতে পারে।
কারণ এটি শুধুমাত্র কতগুলি টোকেনকে context-এ প্যাক করা যায় তা পরিমাপ করে না, বরং টুল কল, সংকুচন, ক্রস-সেশন এবং মেমোরি রিট্রিভালের পরেও কতটা কীভাবে ডিজাইন তথ্য ব্যবহারযোগ্য ফরম্যাটে বিদ্যমান থাকে তা পরিমাপ করে। এর অর্থ এই যে, এজেন্টের দীর্ঘমেয়াদী মেমোরি শুধুমাত্র দীর্ঘতর context-এর উপর নির্ভর করতে পারে না।
কিছু জ্ঞান মেমরিতে রাখা উপযুক্ত, যেমন প্রজেক্ট বিল্ডিং পদ্ধতি এবং ডেভেলপমেন্ট অভ্যাস; কিছু সিদ্ধান্ত সংগঠিত ADR বা কোড ইনডেক্সে যাওয়া উচিত; এবং যে সব বিষয় যদি লঙ্ঘন করা হয় তবে সিস্টেমের আর্কিটেকচারাল বোর্ডার ভাঙতে পারে, সেগুলো সরাসরি টাইপ, টেস্ট, lint, ডিপেন্ডেন্সি নিয়ম এবং CI-তে লেখা উচিত।
যদি একটি নিয়ম সফটওয়্যার দ্বারা বাস্তবায়িত সীমাবদ্ধতায় পরিণত হয়, তবে এজেন্টকে এটি "মনে রাখতে" হবে না। পরবর্তী পর্যায়ে এজেন্ট একটি কথোপকথন ভুলে যেতে পারে, কিন্তু কম্পাইলার এবং টেস্টকে সহজেই অতিক্রম করতে পারবে না।
যদি ফিডেলিটি কম হয়, তাহলে এজেন্ট যত বেশি সময় চলবে, সিস্টেমে তত বেশি বোমা বোনা হচ্ছে।
এটি হয়তো কোডিং এজেন্টের জন্য একটি গুরুত্বপূর্ণ সীমানা যা তাকে “কোড লিখতে পারে” থেকে “দীর্ঘমেয়াদি সফটওয়্যার মেইনটেন করতে পারে”-এ নিয়ে যাবে: ডিজাইনের জ্ঞানকে সম্ভাব্য ভাষাগত মেমোরি থেকে ধাপে ধাপে রিট্রিভিউ, ভেরিফাই এবং এক্সিকিউট করা যায় এমন সফটওয়্যার স্টেট-এ স্থানান্তরিত করা।
অন্যথায়, স্বয়ংক্রিয়ভাবে চলার সময় বাড়তে থাকলে একটি অত্যন্ত অবিশ্বাস্য দৃশ্য দেখা দেবে। এজেন্ট কোড লেখার গতি দ্রুত হয়ে যাচ্ছে, প্রকল্পটিও দ্রুত পরিবর্তিত হচ্ছে, কিন্তু কিছুক্ষণ পর কিছুক্ষণ পর এটিকে আগের সময়ের বাকি থাকা বিশ্বটি আবার বুঝতে হচ্ছে।
প্রাচীন পরিবারগত কোডের সাধারণ বাক্যটি হল: "এই অংশটি না স্পর্শ করুন, কেন এটি বিস্ফোরিত হয় তা জানা যায় না।"
এআই প্রজন্মগত কোড আরও অদ্ভুত হতে পারে: কোডটি প্রকৃতপক্ষে এজেন্ট দ্বারা লেখা হয়েছিল, কিন্তু পরবর্তী এজেন্টগুলি আগের এজেন্টগুলির কারণে এটি কেন লেখা হয়েছিল তা জানে না।