Red Hat کے 219 حقیقی دنیا کے سیشنز کے تجزیے کے مطابق، Claude Code اپنے ٹوکن بجٹ کا تین چوتھائی حصہ صرف کوڈ بیس کو پڑھنے میں خرچ کرتا ہے۔ یہ نتیجہ اس عام مفروضے کو بدل دیتا ہے کہ AI سے چلنے والے کوڈنگ ایجنٹس کوڈ تیار کرنے میں وقت ضائع کرتے ہیں، اور یہ تجویز کرتا ہے کہ ڈویلپرز کو صرف ماڈل کی رفتار کے بجائے سیاق و سباق کے انتظام (context-management) کے مسئلے پر توجہ دینی چاہیے۔

دعوے کے پیچھے موجود ڈیٹا

Red Hat نے Anthropic کے Claude Code کے ساتھ 219 تعاملات کا جائزہ لیا اور فی مرحلہ ٹوکن کے استعمال کا حساب لگایا۔ نمونے میں، اوسط مرحلہ (median turn) 75% ٹوکنز کوڈ اور دستاویزات کو جذب کرنے کے لیے مختص کرتا تھا، جبکہ صرف 25% نئی لائنیں تیار کرنے کے لیے استعمال ہوتے تھے۔ چونکہ زیادہ تر AI فراہم کنندگان ان پٹ اور آؤٹ پٹ ٹوکنز کے لیے ایک ہی شرح سے چارج کرتے ہیں، اس لیے لین دین کا "پڑھنے" والا حصہ لاگت کا بڑا حصہ بنتا ہے۔

پڑھنے کی لاگت کیوں اہم ہے

آپٹیمائزیشن کی حکمت عملی

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

لاگت پر قابو

جب ایک AI اسسٹنٹ ہر درخواست پر اسی ریپوزٹری کی حالت کو دوبارہ پڑھتا ہے، تو ان پٹ ٹوکنز میں بہت زیادہ اضافہ ہو جاتا ہے۔ بڑے context windows والے پروجیکٹس کے بلز میں نمایاں اضافہ ہو سکتا ہے، چاہے تیار کردہ کوڈ کی مقدار معمولی ہی کیوں نہ ہو۔

انجینئرنگ پر توجہ

ٹول بنانے والے اکثر ماڈل کے معیار کو بہتر بنانے کے پیچھے بھاگتے ہیں جبکہ اس بات کو نظر انداز کر دیتے ہیں کہ پرامپٹس (prompts) کیسے بنائے جاتے ہیں۔ تجزیہ یہ تجویز کرتا ہے کہ "context engineering" – یعنی ماڈل کو فراہم کیے جانے والے کوڈ کو تراشنا (trimming)، کیش کرنا (caching)، اور خلاصہ کرنا (summarizing) – ماڈل کے بتدریج اپ گریڈز کے مقابلے میں زیادہ بہتر ROI فراہم کرتا ہے۔

پڑھنے کے بوجھ کو کم کرنے کے لیے عملی اقدامات

  • غیر متعلقہ فائلوں کو ختم کریں – پرامپٹ سے وہ فائلیں ہٹا دیں جن کی موجودہ ٹاسک کو ضرورت نہیں ہے۔ چھوٹے پرامپٹس کا مطلب ہے کم ان پٹ ٹوکنز۔
  • بار بار پڑھے جانے والے ڈیٹا کو کیش کریں – کوڈ بیس کے مستحکم حصوں کے ماڈل کے تجزیے کو محفوظ کریں اور ایک ہی متن کو بار بار بھیجنے کے بجائے اسے مختلف مراحل میں دوبارہ استعمال کریں۔
  • ٹول کے آؤٹ پٹ کو کمپریس کریں – جب بیرونی ٹولز بڑے ڈیٹا (مثلاً lint reports) واپس کرتے ہیں، تو انہیں Claude کو واپس بھیجنے سے پہلے خلاصہ کر لیں۔
  • بتدریج فرق (incremental diffs) کا استعمال کریں – پوری فائل کے مواد کے بجائے صرف پچھلے مرحلے سے ہونے والی تبدیلیوں کو بھیجیں۔

ان حکمت عملیوں کا مقصد AI کو ہر تعامل پر اسی ریپوزٹری اسنیپ شاٹ کو دوبارہ پڑھنے سے روکنا ہے، جس سے لیٹنسی (latency) اور لاگت دونوں میں کمی آتی ہے۔

جوابی دلیل: رفتار اب بھی اہمیت رکھتی ہے

کچھ ڈویلپرز کا کہنا ہے کہ تیز رفتار ماڈل اب بھی اہمیت رکھتا ہے کیونکہ یہ ان 25% ٹوکنز کی لیٹنسی کو کم کرتا ہے جو تیار کیے جاتے ہیں۔ لیٹنسی کے حساس ماحول میں—جیسے IDE پلگ انز جنہیں فوری طور پر جواب دینا ہوتا ہے—ہر ملی سیکنڈ اہم ہوتا ہے۔ پڑھنے پر مبنی یہ پروفائل تیز رفتار ماڈل کے فائدے کو ختم نہیں کرتا؛ یہ صرف اس کے متعلقہ اثر کو کم کر دیتا ہے۔

آگے کیا دیکھنا ہے

Red Hat کا مطالعہ سیشنز کے ایک محدود سیٹ پر مبنی ہے، اس لیے وسیع تر نمونہ دیگر زبانوں یا پروجیکٹ کے سائز کے لیے ٹوکن کی مختلف تقسیم ظاہر کر سکتا ہے۔ اگر مستقبل کا ڈیٹا 75% پڑھنے کے ہندسے کی تصدیق کرتا ہے، تو ہم ایسے ٹولز کی طرف منتقلی دیکھ سکتے ہیں جو خودکار طور پر سیاق و سباق کو تراشتے اور کیش کرتے ہیں، یا یہاں تک کہ ایسے ماڈل آرکیٹیکچر بھی جو تیز رفتار سیاق و سباق کے جذب (ingestion) کے لیے تیار کیے گئے ہوں۔

حاصلِ کلام: AI کی مدد سے کوڈنگ کے لیے، سب سے سستا کارکردگی کا اضافہ ماڈل کو کم ڈیٹا فراہم کرنے سے حاصل ہوتا ہے، نہ کہ اسے تیزی سے لکھنے کے لیے مجبور کرنے سے۔ Red Hat کے اعداد و شمار ایک واضح کیس پیش کرتے ہیں: اپنے پرامپٹس کو تراشیں، کیش کریں اور خلاصہ کریں، اور آپ وقت اور پیسہ دونوں میں واضح بچت دیکھیں گے۔