کلوڈ کوڈ کوٹا ڈراپ: ایجینٹس نئے 'لیگسی کوڈ ماؤنٹینز' بنارہے ہیں؟

کلود کوڈ کا ہفتہ وار ایکسٹینشن توجہ کا مرکز بن گیا، مضمون ایجنٹ پروگرام کے ٹوکن استعمال کے طریقہ کار کا تجزیہ کرتا ہے۔ لمبے عرصے تک چلنے والے ایجنٹس کی وجہ سے ورکنگ سیٹ لگاتار بڑھتا رہتا ہے، جس میں ہر قدم پر تاریخی حالتیں جمع ہوتی رہتی ہیں، اور کیش میں مطابقت کے باوجود کنٹیکس میں جگہ قبضہ کرنے کی خصوصیت کی وجہ سے حسابی لاگت لگاتار بڑھتی ہے۔ زیادہ صاف کرنے سے "سمینٹک پیج فول" پیدا ہوتا ہے، جس کی وجہ سے ایجنٹ کو معلومات دوبارہ حاصل کرنی پڑتی ہیں۔ مضمون میں اشارہ کیا گیا ہے کہ اس کوڈ کی حالت اور ڈیزائن حالت کی محفوظ درجہ بندی میں عدم تطابق، AI کے ذریعہ تخلیق کردہ "پرانے کوڈ" کا باعث بن سکتا ہے: بعد کے ایجنٹس پچھلے کوڈ کے ڈیزائن کے سبب واقعات نہیں سمجھ سکتے، جس کے نتیجے میں queue، bypass، retry ایک دوسرے کو مکمل کرنے والے پیچیدہ کوڈ بن جاتے ہیں۔

مضمون کے مصنف، ماخذ: Leifengwang

کوڈ بالکل ایجنٹ نے لکھا تھا، صرف بعد کے ایجنٹس نہیں جانتے کہ پہلے ایجنٹ نے اسے اس لیے کیوں لکھا تھا۔

کلود کوڈ کے لیے 19 اگست کو ختم ہونے والی +50% ہفتہ وار کوٹا اضافہ، اینتھرپک نے 31 اگست تک مزید بڑھا دیا۔ اسی اصل ختم ہونے کے وقت کے قریب، ہیکر نیوز پر کلود کوڈ کے استعمال کی لاگت پر بحث شروع ہو گئی: بہت سے صارفین نے دریافت کیا کہ ایک غیر پیچیدہ کام، ایجنٹ کچھ راؤنڈ چلانے سے ہی کوٹا جلد ختم ہو جاتا ہے۔

مسئلہ یہ ہے کہ کلوڈ کوڈ صرف آخری تخلیق کی گئی کچھ لائنوں کا استعمال نہیں کرتا۔ فائلیں پڑھنا، کال چین تلاش کرنا، ٹیسٹ چلانا، اور لاگز کو پروسیس کرنا، ہر مرحلہ آگے کے کنٹیکس میں جاری رہتا ہے۔ جتنا لمبا کام ہوگا، اتنی ہی زیادہ تاریخ Agent کے ساتھ ہوگی، اور سسٹم کو صفائی اور دباؤ کی زیادہ انحصار ہوگا۔

کوڈ مکمل طور پر ریپوزٹری میں رہ سکتا ہے، لیکن ابتدائی ڈیزائن کے وجوہات دباؤ کے ساتھ دھیمے دھیمے کم ہوتے جا سکتے ہیں۔ اس طرح ٹوکن کی استعمال اور کوڈ کا گندہ کھڑکھڑا ایک ہی جگہ پر مل جاتے ہیں۔

عام چیٹ کوڈنگ کی حسابی حدیں واضح ہیں۔ ایک کوڈ کا حصہ درج کریں، ماڈل اسے پڑھنے کے بعد وضاحت یا ترمیم کا پیشہوا حل فراہم کرتا ہے، اور یہ دور تقریباً ختم ہو جاتا ہے۔

اور کلود کوڈ کی بنیادی اکائی کو ایجنٹ لوپ میں تبدیل کر دیا گیا ہے۔ ماڈل پہلے موجودہ حالت کا مشاہدہ کرتا ہے، فیصلہ کرتا ہے کہ اگلے مرحلے میں کون سا فائل پڑھنا ہے یا کون سا حکم نفاذ کرنا ہے؛ ٹولز سے نتائج واپس آنے کے بعد، ماڈل اگلے دور کا فیصلہ کرتا ہے۔

سورس کوڈ پڑھنا، حوالہ جات تلاش کرنا، ٹیسٹ چلانا، گٹ ڈیف دیکھنا، فائلز تبدیل کرنا، ایک مسلسل حرکت کی طرح لگتا ہے، لیکن ماڈل کی طرف سے یہ الگ الگ استدلال کے درخواستوں کا سلسلہ ہے۔ کلوڈ کوڈ کی آفیشل دستاویزات بھی اس "ماڈل کا فیصلہ — ٹول بلانا — نتائج کے مطابق مزید فیصلہ کرنا" کے حلقوں کو ایجنٹ کے کام کے طریقہ کار کا مرکزی حصہ قرار دیتی ہیں۔

مثلاً، لاگ ان کی حالت کا ایک عارضی خاتمہ۔ ایجینٹ پہلے انٹری پوائنٹ تلاش کرتا ہے، پتہ چلتا ہے کہ حالت سروس سے آ رہی ہے، اس لیے وہ سروس کو مزید پڑھتا ہے؛ کیش کو دیکھ کر وہ تلاش کرتا ہے کہ کون اسے لکھ رہا ہے؛ پھر ٹیسٹ چلاتا ہے، ٹیسٹ میں ایک اور غیر معمولی بات ظاہر ہوتی ہے، اس لیے وہ فکسچر دیکھتا ہے؛ اس کے بعد اسے درست کرتا ہے اور دوبارہ تصدیق کرتا ہے، پرانا ٹیسٹ دوبارہ مطابقت کی مسئلہ ظاہر کرتا ہے۔

شاید تب تک ہی اس نے وہ کچھ لائنز کوڈ لکھنا شروع کیا۔ اس لیے،diff سائز اور کمپوٹیشنل لود کے درمیان تقریباً کوئی مستقل تناسب نہیں ہے۔ 5 لائنز کے پیچ کے پیچھے صرف 3 بار استدلال ہو سکتا ہے، یا پھر 30 بار ٹول انٹرایکشن ہو چکا ہو سکتا ہے۔

اگر ایک ایجینٹ کا کام تقسیم کیا جائے، تو دو متغیر حاصل ہو سکتے ہیں: ایک اسٹیپ کاؤنٹ ہے، جو ایجینٹ کو کام مکمل کرنے کے لیے کتنے اسٹیپ لگے، اور دوسرا ورکنگ سیٹ ہے، جو موجودہ اسٹیپ تک پہنچنے کے بعد ماڈل کو کتنے پروجیکٹس کی حالت معلوم ہونی چاہیے۔

صرف اسٹیپ کاؤنٹ بڑھانا ہی خرچ میں اضافہ کر دے گا۔ اگر ورکنگ سیٹ ابھی بھی مسلسل بڑھ رہا ہے، تو صورتحال بالکل مختلف ہو جائے گی۔ تیسرے اسٹیپ میں شاید صرف ہزاروں ٹوکنز کو پروسیس کرنا پڑے، لیکن تیسرا اسٹیپ پہلے ہی پروجیکٹ کے قواعد، متعلقہ سورس کوڈ، ٹیسٹ نتائج، تبدیلی کی تاریخ اور ٹولز کو ساتھ لے کر دوبارہ استدلال کر رہا ہوگا۔

یہ کوڈنگ ایجنٹ کی لاگت ساخت میں تبدیلی کا آغاز بھی ہے: کمپوٹیشن کی مقدار اب "کتنے قدم چلنا ہے × ہر قدم پر کتنا بوجھ لانا ہے" پر منحصر ہوگی، نہ کہ کتنی لائنز کوڈ لکھنا ہے پر۔

ایجنٹ کے ایک ماڈل کے درخواست کو تین حصوں میں تقسیم کیا جا سکتا ہے۔ نسبتاً مستحکم حصہ سسٹم پرامپٹ، CLAUDE.md، ٹول کی تعریف اور منصوبہ کے قواعد پر مشتمل ہے؛ متغیر حصہ کوڈ فائلز، سرچ نتائج، ٹیسٹ لاگز، Git diff اور پچھلے ٹاسک ٹریکس پر مشتمل ہے؛ اور آخر میں اس دور میں ماڈل کے ذریعہ تخلیق کردہ ریزننگ، متن اور کوڈ شامل ہیں۔

یہاں ایک عام غلط فہمی ہے: اگر پہلے کا مواد پڑھ لیا گیا ہے، تو دوبارہ زیادہ لاگت نہیں ہونی چاہیے۔ مسئلہ یہ ہے کہ LLM کے دو درخواستوں کے درمیان کوئی روایتی پروگرام کی طرح وہ اندرونی میموری نہیں ہوتی جس تک کبھی بھی رسائی حاصل کی جا سکے۔ اگر اگلے مرحلے میں پچھلے مرحلے کی معلومات کی ضرورت ہو، تو وہ متعلقہ حالتیں دستیاب کانٹیکسٹ میں برقرار رکھی جانی چاہئیں۔

پرامپٹ کیش اس مسئلے کو کم کر سکتی ہے۔ کلوڈ کوڈ کی آفیشل دستاویز میں واضح طور پر بتایا گیا ہے کہ اگر پرامپٹ کیشینگ نہ ہو، تو ہر درخواست میں پوری تاریخ دوبارہ پروسیس کی جانی چاہیے؛ جب کیش میچ ہو جائے، تو پہلے پروسیس کیے گئے مستقل پیشون کو دوبارہ استعمال کیا جا سکتا ہے، جس سے دوبارہ کمپوٹیشن اور لاگت کم ہوتی ہے۔

لیکن کیش صرف یہ حل کرتا ہے کہ "کیا ایک جیسی تاریخ کو دوبارہ استعمال کیا جا سکتا ہے اور اسے سستا بنایا جا سکتا ہے"، اس نے یہ نہیں حل کیا کہ "کیا یہ تاریخ کو مزید جاری رکھنا ضروری ہے؟"۔ 100K ٹوکن کی پرانی حالت کے کیش میں مل جانے کے بعد اسے سستا بنایا گیا، لیکن وہ اب بھی کانٹیکسٹ پر قبضہ کرتی ہے اور اب بھی موجودہ استدلال کی بنیاد ہے۔

اس لیے ایک لمبا کام درج ذیل طرح لکھا جا سکتا ہے: اسٹیبل پیشگی S، موجودہ مؤثر ورک سیٹ W_t، اور اس دور میں تازہ پیدا ہونے والی نئی معلومات Δ_t کا مجموعہ۔

حقیقی پریشانی ہے W_t۔ اگر ہر قدم پر، ایجینٹ مزید سورس کوڈ پڑھے، مزید لاگ حاصل کرے، اور ایک اضافی فیصلہ چھوڑے، جبکہ پرانی معلومات کو وقت پر ختم نہ کیا جائے، تو W_t ٹاسک کے آگے بڑھنے کے ساتھ لگاتار بڑھتی رہے گی۔

ایک انتہائی سادہ، مکمل طور پر کیش اور صفائی کے بغیر کے ماڈل میں، اگر ہر راؤنڈ میں نئے اثباتی حالات تقریباً ایک جیسے ہوں، تو کل پروسیسنگ کا مجموعہ تقریباً 1 + 2 + 3 + … + n کی ت tíchیلی ساخت ظاہر کرے گا۔ یعنی، اسٹیپ کاؤنٹ صرف دوگنا ہو گا، لیکن پورے کام کے دوران پروسیس کیے گئے سابقہ حالات زیادہ تیزی سے بڑھ سکتے ہیں۔

عملی نظام میں کیش، کنٹیکس ایڈیٹنگ اور کمپیکشن ہوتے ہیں، جو اس ترقی کے منحنی کا حرفی طور پر پابند نہیں ہوتے، لیکن مسئلے کی شکل وہی رہتی ہے: ایجینٹ جتنا لمبا وقت چلتا ہے، اتنے ہی زیادہ احتمال ہوتا ہے کہ ہر نیا ایکشن مزید بھاری تاریخ پر مبنی ہو۔

اس لیے لمبے کام میں وہ بہت چھوٹا صارف پرامپٹ جلد ہی اپنی موجودگی کھو دے گا۔ اصل میں لاگت کو ہدایت کرنے والا، ماڈل کا وہ ورک سیٹ ہے جو وہ کام کی مسلسل مانگ کے لیے لے جاتا رہتا ہے۔

کیوں working set اتنی جلدی بڑھ رہا ہے، ٹول کا آؤٹ پٹ ایک بڑا ذریعہ ہے۔ سورس کوڈ میں کم از کم سٹرکچر ہوتا ہے، لیکن لوگز اکثر نہیں ہوتے۔

ایک grep کئی سو حوالے واپس کر سکتا ہے، ایک بیلڈ ممکنہ طور پر بہت سارے وارننگز پیدا کر سکتا ہے، ایک ٹیسٹ فیل ہونے پر مکمل اسٹیک ٹریس کے ساتھ آ سکتا ہے، ڈاکر، کمپائلر، اور پیکج مینیجر بھی ایسے بہت سارے متن پیدا کرتے ہیں جو کام کے لیے لمبے عرصے تک فائدہ مند نہیں ہوتے۔

اگر 10ویں مرحلے کے ٹیسٹ سے 8K ٹوکن لاگز ملے ہوں۔ جب یہ پہلی بار کنٹیکسٹ میں داخل ہوتا ہے، تو صرف 8K ٹوکن ہوتا ہے۔ لیکن ایجنٹ کو ذرائع کوڈ کی جانچ، تبدیلی اور دوبارہ ٹیسٹ کرنے کی ضرورت ہوتی ہے، اور جب تک یہ لاگز معتبر تاریخ میں موجود رہتا ہے، یہ بعد کے بہت سارے درخواستوں کی بنیادی وزن بڑھاتا رہتا ہے۔

یہ اسٹوریج سسٹم میں write amplification جیسا ہے: ایک منطقی لکھنا، نیچے کے سطح پر مزید پردازش کا باعث بنتا ہے۔ ایجنٹ میں، ایک ٹول آؤٹ پٹ کو ایکزیکشن ہسٹری میں لکھا جاتا ہے، جس کے بعد یہ بعد کے استدلال کے ساتھ منتقل ہوتا ہے۔

اس لیے 8K ٹوکن کو کام ختم ہونے سے پہلے ایک چکر میں رکھنا اور کام شروع ہونے کے فوراً بعد رکھنا، دونوں کا کل اثر بالکل مختلف ہوتا ہے۔ کلاؤڈ کوڈ اب اس آلودگی کو کم کرنے کی کوشش کر رہا ہے۔ باضابطہ تجویز ہے کہ زیادہ آؤٹ پٹ والے کاموں کو سب ایجنٹ کے ذریعے الگ کیا جائے، اور واضح طور پر بتایا گیا ہے کہ تلاش کے نتائج، لاگز اور بڑی مقدار میں فائلز کا مواد مین سیشن کے کنٹیکس کو استعمال کرتے ہیں؛ ٹول کی تعریف خود بھی جگہ لیتی ہے، اس لیے ٹول سیٹ بہت بڑا ہونا بھی حالت پر بوجھ ڈالتا ہے۔

لیکن یہاں ایک اُلٹی سمت کا مسئلہ بھی ہے: کیونکہ لاگز مہنگے ہیں، انہیں مکمل طور پر کاٹنا نہیں چاہیے۔ 3000 لائنوں کی لاگ میں، صرف 20 لائیں جڑ کی وجہ سے متعلق ہو سکتی ہیں۔ سسٹم پہلے سے نہیں جانتا کہ کون سی 20 لائیں ہیں۔ اگر آپ جلدی صاف کر دیں، تو ایجنٹ بعد میں ایک تفصیل کی ضرورت محسوس کرے گا اور صرف ٹیسٹ دوبارہ چلانے یا فائل دوبارہ کھولنے کے ذریعے ہی اس تک پہنچ سکتا ہے۔

اسے سیمینٹک پیج فولٹ کہا جا سکتا ہے۔ روایتی ورچوئل میموری میں، جب پروگرام ایک ایسے پیج کو ایکسیس کرتا ہے جو میموری میں نہیں ہے، تو سسٹم ڈسک سے اسے دوبارہ لوڈ کرتا ہے؛ کوڈنگ ایجنٹ جب کسی پرانے ثبوت کو چھوڑ دیتا ہے، تو اسی قسم کا واقعہ پیش آتا ہے، صرف اس بار یہ ریپوزٹری کو دوبارہ تلاش کرنے، فائلز کو دوبارہ پڑھنے، حکمات دوبارہ چلانے، یا پہلے ہی تجزیہ کیا گیا مسئلہ دوبارہ استنباط کرنے کی شکل میں ظاہر ہوتا ہے۔

اس طرح لمبے کام کا ایک دوہری مسئلہ بن جاتا ہے: زیادہ تاریخ رکھنے سے بعد کا ہر مرحلہ اور بھی بھاری ہوتا جاتا ہے؛ اگر زیادہ جلد بازی سے صاف کر دیا جائے تو ایجنٹ بار بار پہلے دیکھ چکی معلومات دوبارہ حاصل کرتا رہتا ہے۔

یہ بھی وضاحت کرتا ہے کہ کیوں کنٹیکسٹ مینجمنٹ کو "کم ٹوکن ڈالنا" کے طور پر سادہ نہیں کیا جا سکتا۔ حقیقت میں جس کا حل کیا جانا چاہیے وہ ہے ورکنگ سیٹ کا انتخاب: ابھی کون سی معلومات کام کے علاقے میں رہنی چاہیں اور کون سی صرف مکمل ہو چکی درمیانی پیداواریں ہیں۔

یہاں تک کہ compaction، memory اور sub-agent کو حقیقی وجہ مل گئی۔

کلود کوڈ جب context کی حد کے قریب پہنچ جائے تو یہ خودبخود سیشن کو دبائے گا اور کچھ پرانے ٹول نتائج کو صاف کر دے گا۔ اس کے علاوہ، افسران نے یہ بھی اطلاع دی ہے کہ لمبے سیشن میں غیر متعلقہ بات چیت، فائل کا مواد اور حکمات کے نتائج ونڈو کو بھر سکتے ہیں اور ماڈل کی کارکردگی پر اثر ڈال سکتے ہیں۔

سسٹم کے نقطہ نظر سے، کمپیکشن ایک معنائی گربیج ریکلیمیشن کی طرح ہے۔ مشکل یہ ہے کہ عام گربیج ریکلیمیشن یہ جانچتی ہے کہ "اس آبجیکٹ کے لیے اب بھی کوئی ریفرنس موجود ہے یا نہیں"، جبکہ ایجنٹ کو یہ فیصلہ کرنا ہوگا کہ "یہ معلومات مستقبل میں کبھی اہم ہوں گی یا نہیں۔"

دوسرا بہت مشکل ہے۔ مثال کے طور پر، ابتدائی طور پر ایک ڈیزائن نتیجہ یہ تھا کہ کوئی ماڈیول اپنے صارف کی حالت کو اپنے اندر کیش نہیں کر سکتا، کیونکہ سسٹم کی درخواست ہے کہ حالت کا صرف ایک مالک ہو، اور تمام تبدیلیاں سروس کے ذریعے ہی ہونی چاہئیں۔

کچھ قدموں کے بعد، اگر اس معلومات کو دبایا جائے کہ: "سابقہ service کے ذریعہ تبدیلی سے حالت کا مسئلہ حل ہو گیا۔" تو واقعیت غلط نہیں ہے، لیکن معلومات تبدیل ہو چکی ہیں۔ اصل مواد میں constraint شامل تھا، جبکہ بعد کے خلاصے میں صرف event محفوظ ہے۔

اگلی بار ایجینٹ کو پرفارمنس کی پریشانی کا سامنا ہو، اور وہ دیکھے کہ سروس کالس سست ہیں، تو اس کا احتمال ہے کہ وہ ماسول میں کیش بڑھا دے گا۔ اس نے اپنے موجودہ جانے ہوئے معلومات کا خلاف ورزی نہیں کیا؛ جب کیش کو منع کرنے والا علّت اب درست نہیں رہا۔

کلود کوڈ کا کنٹیکس دستاویز صاف طور پر واضح کرتا ہے کہ کچھ پاتھ-سکوپڈ قواعد اور نیسٹڈ CLAUDE.md فائلیں سیشن کے ساتھ کمپیکشن خلاصہ میں شامل ہو جاتی ہیں، اور دوبارہ لوڈ ہونے کے لیے مطابقت رکھنے والی فائل کو دوبارہ پڑھنا ضروری ہے۔

Memory لمسلہ طویل مدتی علم کے محفوظ رکھنے کا حل پیش کرتا ہے۔ پروجیکٹ رُوت ڈائریکٹری میں CLAUDE.md اور auto memory تعمیر کمانڈز، پروجیکٹ اسپیفیکیشنز، ڈیبگنگ تجربات جیسی چیزوں کو مختصر مکالمات سے نکال کر سیشن کے آغاز پر دوبارہ لوڈ کرتے ہیں۔ لیکن Anthropic اپنی مثبت حیثیت بھی واضح طور پر لکھتی ہے: یہ memory ابھی بھی context ہیں، اور اجباری ترتیب کا حصہ نہیں ہیں۔

یہ فرق بہت اہم ہے۔ اگر "یہاں ڈیٹا بیس تک ب безپوسیب رسائی نہیں" صرف میموری میں لکھا جائے، تو یہ اب بھی ایک ایسی قدرتی زبان ہے جسے ماڈل کو سمجھنا اور اس پر عمل کرنا ہوگا۔ اگر اسی قاعدہ کو ڈیپینڈنسی لِنٹ، ٹائپ کنسترینٹ یا CI چیک کے طور پر لکھا جائے، تو یہ ایک ایسا سافٹ ویئر انویرینٹ بن جاتا ہے جسے آسانی سے نہیں چھوڑا جا سکتا۔

سب-ایجینٹ ایک اور شعبے کو حل کرتا ہے: ورک سیٹ کو الگ کرنا۔ ایک الگ ایجینٹ کو ریپوزٹری کو اسکین کرنے یا لمبے لاگز کو تجزیہ کرنے کے لیے بھیجا جا سکتا ہے، اور پھر دبائے گئے نتائج کو مین ایجینٹ کو واپس کیا جا سکتا ہے، جس سے اصل نویز مین ٹھریڈ میں داخل نہیں ہوتا۔ کلوڈ کوڈ کی طرف سے سب-ایجینٹ کا استعمال کرنے کا ایک مقصد context isolation ہے۔

اس کی قیمت بھی دلچسپ ہے: اہم ایجنٹ کو صاف تر حالت ملی، لیکن کچھ اصل ثبوت کھو دیے؛ متعدد ایجنٹس ایک ساتھ چلنے سے اپنے اپنے کنٹیکس بناتے ہیں۔ اس لیے کمپیکشن، میموری اور سب-ایجنٹس کو ایک ساتھ دیکھنا، دراصل ایجنٹ کے دور کی ایک میموری ہائرارکی جیسا ہے:

موجودہ کنٹیکس مہنگا ورکنگ میموری ہے، کمپیکشن کمپریشن کے لیے ذمہ دار ہے، میموری سیشن کے درمیان حالت محفوظ رکھتی ہے، اور سب-ایجنٹ نویز کو الگ ایڈریس اسپیس سے الگ کرتا ہے۔ مسئلہ اب "کنٹیکس کافی بڑا ہے؟" سے ایک اور سطح پر چلا گیا ہے：

کون سی حالتیں مکمل محفوظ کی جانی چاہئیں اور کون سی حالتیں صرف خلاصہ کے ساتھ چھوڑ دی جانی چاہئیں؟ یہ سوال بعد کے کوڈ کی معیار کو ب без تاثیر ڈالے گا۔

پہلے اس اجراء کی ساخت کو سمجھنے کے بعد، کلاؤڈ کوڈ کی ہفتہ وار سیٹنگ دیکھ کر، یہ واضح ہوتا ہے کہ پلیٹ فارم کو "پیغام کی تعداد" کے لحاظ سے ایجنٹ کا اندازہ لگانا مشکل ہو جائے گا، کیونکہ ایک پیغام اب مستقل معنی نہیں رکھتا۔

ایک متغیر کا نام بدلنا ایک پیغام ہے، جبکہ پورے تصدیق ماڈیول کو دوبارہ ڈیزائن کرنا بھی ایک پیغام ہے۔ پہلا ممکنہ طور پر کچھ مراحل میں ختم ہو جائے گا، جبکہ دوسرا کئی دہائیوں تک چل سکتا ہے، کئی دہائیوں فائلیں پڑھ سکتا ہے، اور کئی ایجینٹس کو شروع کر سکتا ہے۔ ایک ہی درخواست کے پیچھے وسائل کی ضرورت مکمل طور پر مختلف سطح کی ہو سکتی ہے۔

کلود کوڈ نے اس بات کو رولنگ لِمٹس اور ہفتہ وار کوٹہ کے ساتھ جوڑ دیا ہے؛ کوڈیک اب input token، cached input token اور output token کے مطابق کریڈٹس کا حساب کرتا ہے؛ جبکہ کرسر کے پیکجز Agent کو مختلف استعمال کے پول فراہم کرتے ہیں، اور تیسری پارٹی ماڈلز کی استعمال کی رفتار ماڈل API کی قیمت پر منحصر ہوگی۔

تینوں مصنوعات کی انٹرفیس کی زبانیں مختلف ہیں، لیکن ان کے نیچے کے مسائل بہت قریب ہیں: ایک ایسا ذکی پروگرام جس کا اجرائی راستہ شروع میں نہیں معلوم ہوتا، اسے تجزیاتی وسائل کیسے تقسیم کیا جائے۔ ایک کوڈنگ ایجنٹ کتنے دیر تک چلے گا، یہ کام شروع ہونے پر مشکل سے معلوم ہوتا ہے۔

ماڈل جلد ہی جڑ کا پتہ لگا سکتا ہے، یا کئی غلط فرضیات پیش کر سکتا ہے؛ ایک ٹیسٹ میں کامیاب ہو سکتا ہے، یا لمبے عرصے تک ڈیبگ لُو میں پھنس سکتا ہے؛ شاید صرف ایک ایجنٹ کی ضرورت ہو، یا کئی سب-ایجنٹس میں تقسیم کیے جائیں۔

سنتھیکل API کو ریکسٹ پر چارج کرنے کی پسند ہے، کیونکہ ایک ریکسٹ کے وسائل کو کچھ حد تک کنٹرول میں رکھا جا سکتا ہے۔ ایجنٹ اس استحکام کو توڑ دیتا ہے۔ اس لیے یہاں ٹوکن تھوڑا سا CPU ٹائم کا جذبہ رکھنے لگتا ہے۔

یہ تشبیہ برابر نہیں ہو سکتی۔ مختلف ماڈلز ایک جتنے ٹوکنز کو ایک جتنے کمپیوٹیشنل کوسٹس پر پروسیس کرتے ہیں، اور input، cached input اور output کے لیے الگ الگ لاگت ہوتی ہے۔ لیکن ڈویلپرز کی طرف سے، ان کا کردار آہستہ آہستہ ایک جیسا ہوتا جا رہا ہے: یہ سب اس بات کو ظاہر کرتے ہیں کہ ایک ٹاسک کو جاری رکھنے کے لیے کتنے کمپیوٹیشنل وسائل استعمال ہو رہے ہیں۔

اینٹروپک نے اس سال کلید کوڈ کے استعمال کی حد بڑھاتے ہوئے، فوری طور پر اس额度 کی اضافہ اور نئی کمپیوٹ کی صلاحیت کو جوڑ دیا۔ اس سے ایک دلچسپ اشاریہ میں تبدیلی آئے گی۔ پہلے کوڈنگ ایجینٹ کا موازنہ کرتے وقت، آسان تھا کہ "ایک ہی سوال پر کون ایک بار میں بہتر کام کرتا ہے"۔ آگے کے لیے، زیادہ مفید ہو سکتا ہے کہ ایک جیسے انجینئرنگ کی حالت میں تبدیلی لانے میں، کون کم از کم مؤثر کمپیوٹنگ استعمال کرتا ہے۔

اگر ایک ایجینٹ بہت سارے ٹوکن خرچ کرے تو صرف فائلیں کھولنا، ٹیسٹ دوبارہ چلانا، اور پہلے سے گم ہو چکے کنٹیکسٹ کو دوبارہ استوار کرنا، تو ان ٹوکنز نے متعلقہ درجہ کی انجینئرنگ پیش رفت حاصل نہیں کی۔

اور یہ ناکارہ حالت کی واپسی، بالکل اسی طرح تکنیکی قرض کے ساتھ نیچے کی سطح پر ملتی ہے۔

یہاں ایک کوڈنگ ایجنٹ کے ذریعے برقرار رکھے جانے والے سافٹ ویئر کو دو ساتھ میں ترقی کرنے والی حالتوں میں تصور کیا جا سکتا ہے۔ ایک حالت کوڈ کی حالت ہے R_t۔ فائلیں، ٹائپس، انٹرفیسز، ٹیسٹ، جیٹ کامٹ سب اس لیور سے تعلق رکھتے ہیں۔ ایجنٹ کا 20ویں مرحلہ پر شامل کیا گیا ایک لائن retry، جب تک کہ اسے حذف نہیں کیا جاتا، 100ویں مرحلہ پر فائل کھولنے پر بھی مکمل طور پر موجود رہتا ہے۔ کوڈ قدیم تبدیلیوں کو بہت زیادہ درجہ دقت کے ساتھ محفوظ کرتا ہے۔

ایک اور سیٹ ڈیزائن اسٹیٹ ہے M_t۔ اس جگہ پر retry کیوں ضروری ہے، کیوں وہ کیش صرف سروس میں رکھا جا سکتا ہے، کیوں اس اسٹیٹ کے دو مالک نہیں ہو سکتے، اور کیوں ایک ایسا لگنے والا زائد جائزہ ابھی تک حذف نہیں کیا جا سکتا، یہ تمام معلومات ڈیزائن کے سبب و معلول سے متعلق ہیں۔

M_t اس میں گٹ جیسا کوئی قدرتی طور پر نقصان رہित ذخیرہ نہیں ہے۔ یہ مکالموں، استدلال، ٹولز کے جوابات، میموری، قواعد کے فائلز اور کمپیکشن سمری میں بکھیرا ہوا ہے۔ جب ٹاسک آگے بڑھتا ہے، تو کچھ حصے صاف کر دیے جاتے ہیں، کچھ خلاصہ کر دیے جاتے ہیں، اور کچھ کو دوبارہ حاصل کرنے کی ضرورت ہوتی ہے۔

اس طرح ایک بہت اہم عدم توازن پیدا ہوتا ہے: نتائج کو اعلی درجے کی درستگی کے ساتھ جمع کیا جا سکتا ہے، لیکن ان نتائج کو پیدا کرنے والے علیحدہ علیحدہ واقعات لگاتار نمونہ لیے جاتے رہتے ہیں۔ یہ صرف "ایجنٹ چیزیں بھول جاتا ہے" کہنے سے بہت زیادہ سنگین ہے۔

ایک کنکرنسی مسئلے کے دوران، ایجینٹ کے تجزیے کے بعد اس نے ایک قطار میں شامل ہو گیا۔ اس وقت اس کے پاس مکمل نتیجہ یہ تھا کہ صرف لکھنے کا راستہ A میں مقابلہ تھا، اس لیے قطار صرف A کو ہی شامل کر سکتی تھی؛ لکھنے کا راستہ B کو کم تاخیر کی ضرورت تھی، اس لیے یہ قطار میں نہیں آ سکتا تھا۔

کوڈ نے queue کو مکمل طور پر محفوظ کر لیا ہے۔ لمبے عرصے تک عمل کے بعد، ڈیزائن کی حالت صرف اس بات تک محدود ہو سکتی ہے کہ "یہاں race condition کو حل کرنے کے لیے queue استعمال ہوتا ہے"۔

بعد میں B میں بھی ایک عارضی خطا ظاہر ہوئی۔ ایجینٹ نے دوبارہ کوڈ پڑھتے ہوئے B کو بھی موجودہ قطار میں شامل کر دیا۔

اس کے بعد تاخیر بڑھی، اس لیے ایک bypass شامل کیا گیا۔ bypass نے عارضی حالت کی عدم تطابق کو پیدا کیا، اس لیے باہری طرف retry شامل کیا گیا۔ اب تک، کوئی بھی تبدیلی بے معنی نہیں تھی۔ ہر پیچ کو اس وقت کے محدود حالت میں دیکھتے ہوئے، وہ کافی منطقی لگ سکتا تھا۔ لیکن کوڈ اب “ایک واضح کانکرنس ماڈل” سے بدل کر queue، bypass اور retry کے درمیان ایک دوسرے کو مکمل کرنے والا بن چکا ہے۔

AI کوڈ کا گندہ ڈھیر اسی طرح بنتا ہے۔ یہ ضروری نہیں کہ مدل اچانک ایک گندی گٹھڑی لکھ دے، بلکہ یہ ممکنہ طور پر مقامی درستگی کے مستقل جمع ہونے اور مجموعی مدل کے آہستہ آہستہ غائب ہونے کی شکل میں ظاہر ہوتا ہے۔

ایسے مسائل عام طور پر روایتی سافٹ ویئر میں ملازمت کے تبادلوں کے ذریعے آہستہ آہستہ پیدا ہوتے ہیں۔ اصل مصنف چلے جاتے ہیں، نئے ڈویلپرز پرانے کوڈ کو دیکھتے ہیں لیکن نہیں جانتے کہ یہ کیوں وجود میں آیا، اس لیے وہ اس کے باہر ایک مطابقت کا منطق شامل کر دیتے ہیں۔

کوڈنگ ایجنٹ نے " personnel handover " کو " context handover " بنا دیا۔ اسٹیپ 20 اور اسٹیپ 100 اب بھی ایک ہی Claude Code سیشن لگ رہے ہیں، لیکن ان کو حاصل ہونے والا ڈیزائن اسٹیٹ بالکل ایک جیسا نہیں ہے۔ معلومات کے نقطہ نظر سے، یہ دو انجینئرز کی طرح ہے جو ایک ایسے ہینڈ اوور ڈاکیومنٹ کے ذریعے ایک ہی ریپوزٹری کو برقرار رکھ رہے ہیں جو لگاتار چھوٹا ہوتا جا رہا ہے۔

ٹیسٹنگ صرف کچھ حصوں کو ہی حل کر سکتی ہے۔ ٹیسٹنگ کا کام سرگرمیوں کے تحفظ میں ہوتا ہے: انٹرفیس کو کیا واپس کرنا چاہیے، کسی خاص ان پٹ سے سسٹم نہیں ٹوٹنا چاہیے، اور پچھلے بگز دوبارہ نہیں آنے چاہئیں۔ بہت سے آرکیٹیکچرل پابندیاں خود بخود ان پٹ اور آؤٹ پٹ کے طور پر ظاہر نہیں ہوتیں۔

حالت صرف ایک مالک رکھ سکتی ہے، دستوری لیورل UI پر ریورس انحصار نہیں کر سکتا، کسی بھی پیکج کو ڈیٹا بیس سے براہ راست جڑنے کی اجازت نہیں، لکھنے کے عمل کو یکساں ٹرانزیکشن بارڈر سے گزرنا ہوگا، اگر یہ پابندیاں صرف دستاویزات یا ایجنٹ کی یادداشت میں موجود ہوں تو انہیں مقامی درستگیوں کے دوران آسانی سے نظرانداز کر دیا جا سکتا ہے۔

ایک بہت پیچیدہ انجینئرنگ کی حالت ظاہر ہوگی: ٹیسٹ اب بھی سبز ہے، لیکن کوڈ اب越来越 مشکل سمجھنا ہو رہا ہے۔ اس سے زیادہ خطرناک بات یہ ہے کہ اس میں فیڈ بیک لوپ موجود ہے۔

سیستم کی ڈیزائن اب بگڑنے لگی ہے، ایجنٹ کو اگلی بار فنکشن کو سمجھنے کے لیے زیادہ فائلیں پڑھنی پڑیں گی؛ متعلقہ ڈیپینڈنسیز جتنا زیادہ پیچیدہ ہوں گی، ورکنگ سیٹ اتنا ہی بڑھے گا؛ ورکنگ سیٹ جتنا بھاری ہوگا، سیستم کو اتنا ہی زیادہ صفائی اور کمپریشن کی ضرورت ہوگی؛ ڈیزائن کے کاروں کو جتنا پتلا رکھا جائے گا، بعد میں تبدیلیاں اتنا ہی زیادہ موجودہ کوڈ اور مقامی ٹیسٹنگ پر منحصر ہوں گی۔

اس طرح کوڈ کی پیچیدگی میں اضافہ ہوتا ہے، جس سے ٹوکن لاگت بڑھتی ہے، اور ٹوکن کا دباؤ دوبارہ مختصر ترین حالت کو برقرار رکھنے اور مقامی ترمیم کو فروغ دیتا ہے۔ یہی وہ مکانیزم ہے جس کی طرف ایجنٹ کوڈنگ میں “جتنا زیادہ دہرائیں، اتنے ہی زیادہ مسائل” کے پیچھے سنجیدگی سے توجہ دینی چاہئے۔

یہ صرف ایک الگ ماڈل کی صلاحیت کا مسئلہ نہیں ہے، بلکہ ایک سسٹم کا مسئلہ ہے جہاں کوڈ کی حالت اور ڈیزائن کی حالت کی درستگی میں عدم تطابق ہے۔

کوڈنگ ایجینٹ اب越来越能长时间行动，但“能跑几个小时”本身未必是一个很好的能力指标。

اگر ایک ایجینٹ 3 گھنٹے کام کرنے کے بعد، اپنے 2 گھنٹے پہلے تبدیل کیے گئے فائل کو دوبارہ پڑھے، کسی انتزاعی کی وجہ سے دوبارہ استدلال کرے، اور پہلے چلائے گئے ٹیسٹ کو دوبارہ رن کرے، تو ان 3 گھنٹوں میں سے کافی حسابی طاقت حالت کی بحالی پر خرچ ہو رہی ہے۔

اگلے سوال کا یہ ہو جائے گا کہ ایک ایجنٹ 50 اسٹیپس، 100 اسٹیپس کے بعد بھی اگلے فیصلوں کے لیے کتنی علیحدہ معلومات برقرار رکھ سکتا ہے۔

اسے حالت کی سچائی کی شرح کہا جا سکتا ہے۔

کیونکہ یہ نہیں پیمائش کرتا کہ context میں کتنے ٹوکن فٹ ہو سکتے ہیں، بلکہ یہ پیمائش کرتا ہے کہ ٹول کال، کمپریشن، کراس سیشن اور میموری ریٹریول کے بعد کتنی اہم ڈیزائن معلومات استعمال کے قابل شکل میں موجود رہتی ہیں۔ اس کا مطلب یہ بھی ہے کہ ایجنٹ کی لمبی مدتی یادداشت صرف لمبے context پر منحصر نہیں ہو سکتی۔

کچھ جانکاریاں میموری میں محفوظ ہونے کے لائق ہیں، جیسے پروجیکٹ کی تعمیر کا طریقہ اور ڈویلپمنٹ کی عادات؛ کچھ فیصلے ساختی ADR یا کوڈ انڈیکس میں جانے چاہئیں؛ اور وہ جو اگر خلاف ورزی کی گئی تو سسٹم کے آرکیٹیکچر بارڈر کو تباہ کر دے گا، وہ براہ راست ٹائپ، ٹیسٹ، لِنٹ، منابع کے قواعد اور CI میں لکھے جانے چاہئیں۔

اگر کوئی قاعدہ نرم افزار کے قابل اجراء پابندی میں تبدیل ہو جائے، تو ایجینٹ کو اسے "یاد" رکھنے کی ضرورت نہیں ہے۔ اگلے دور میں ایجینٹ ایک مکالمہ کو بھول سکتا ہے، لیکن کمپائلر اور ٹیسٹ کو آسانی سے نہیں عبور کر سکتا۔

اگر فیڈیلیٹی کم ہو، تو ایجینٹ جتنا لمبا چلے گا، سسٹم میں اتنے ہی زیادہ بم چھپائے گا۔

یہ شاید کوڈنگ ایجینٹ کے لیے "کوڈ لکھنا سیکھنا" سے "نرم افزار کو لمبے عرصے تک برقرار رکھنا" تک جانے کی ایک اہم حد ہو: ڈیزائن کی معلومات کو احتمالی زبانی یادداشت سے، قابل ریٹریو، قابل تصدیق اور قابل اجراء نرم افزار کی حالت میں منتقل کرنا۔

ورنہ خودکار چلنے کا وقت زیادہ ہوگا، تو ایک بہت عجیب منظر پیش آئے گا۔ ایجنٹ کوڈ لکھنے کی رفتار ہر وقت تیز ہوتی جا رہی ہے، اور منصوبے بھی تیزی سے تبدیل ہو رہے ہیں، لیکن ہر ایک مخصوص وقت کے بعد، اسے پچھلے دور میں چھوڑے گئے دنیا کو دوبارہ سمجھنا پڑتا ہے۔

قدیمی ورثہ کوڈ میں عام طور پر ایک جملہ ہوتا ہے: "اس حصے کو مت چھیڑیں، نہیں تو پتہ نہیں کیوں پھٹ جائے گا۔"

AI کی ورثہ کوڈ مزید عجیب ہو سکتی ہے: کوڈ بالکل Agent نے لکھا ہے، صرف بعد والے Agent کو پہلے والے Agent نے اسے اس طرح کیوں لکھا تھا، یہ نہیں معلوم۔