یہ ٹیسٹ کیوں اہم ہے
AI پر مبنی کوڈ اسسٹنٹس اکثر ٹیموں کو یہ اجازت دیتے ہیں کہ وہ ریپوزٹری (repo) میں ایک "rules" فائل رکھ دیں اور یہ توقع کریں کہ ماڈل ہر درخواست پر اس کی ہدایات پر عمل کرے گا۔ عملی طور پر، ہو سکتا ہے کہ ماڈل اس فائل کو دیکھے ہی نہ، یا وہ اسے دیکھ لے لیکن اس کے مواد کو نظر انداز کر دے۔ Claude Code کے ساتھ کیے گئے ایک حالیہ تجربے نے یہ دونوں مسائل دکھائے۔ ٹول نے خاموشی سے 72 KB کی AGENTS.md فائل کو نظر انداز کر دیا؛ جب اسی فائل کا نام بدل کر CLAUDE.md کر دیا گیا تو اسسٹنٹ نے اسے لوڈ کر لیا اور ہر درخواست کے لیے ٹوکن کی تعداد (token count) بڑھ گئی۔ ٹوکن کا وہ اضافی بجٹ لیٹنسی (latency)، لاگت کو بڑھا دیتا ہے اور درخواست کو ماڈل کی حد سے تجاوز کروا سکتا ہے۔
وہ ڈویلپرز جو یہ فرض کر لیتے ہیں کہ "فائل کا موجود ہونا" ہی "ماڈل کے اصولوں پر عمل کرنا" ہے، وہ پوشیدہ عدم کارکردگی اور غیر متوقع نتائج کا خطرہ مول لیتے ہیں۔ یہ تین مرحلہ وار ٹیسٹ ہر مرحلے پر ٹھوس ثبوت فراہم کرنے پر مجبور کرتا ہے: کنفیگریشن (configuration)، لوڈنگ (loading)، اور افادیت (usefulness)۔
پوچھے جانے والے تین سوالات
- Configured (کنفیگرڈ) – کیا فائل وہاں رکھی گئی ہے جہاں اسسٹنٹ اسے تلاش کرتا ہے؟ مختلف ٹولز میں راستے (paths) یا فائل کے نام کے طریقے (conventions) ہارڈ کوڈڈ (hard-coded) ہوتے ہیں؛ اگر ان میں فرق ہو تو اس کا مطلب ہے کہ فائل کبھی بھی پرامپٹ پائپ لائن (prompt pipeline) کا حصہ نہیں بن پائے گی۔
- Loaded (لوڈڈ) – کیا اسسٹنٹ اس بات کا کوئی ثبوت دیتا ہے کہ اسے فائل موصول ہوئی ہے؟ ہیش (hash) ڈسک پر فائل کی شناخت کی تصدیق کر سکتا ہے، لیکن صرف ڈیلیوری ٹریس (مثلاً لاگ لائن یا ٹوکن کی تعداد) ہی یہ ثابت کرتی ہے کہ ماڈل نے واقعی اسے دیکھا ہے۔
- Useful (مفید) – کیا فائل کی موجودگی سے کام کے نتیجے میں بہتری آتی ہے؟ ایسی لوڈ شدہ فائل جو ٹوکنز تو بڑھاتی ہے لیکن نتیجہ تبدیل نہیں کرتی، وہ خالص نقصان ہے۔
ٹیسٹ کا طریقہ کار
یہ طریقہ کار جان بوجھ کر انتہائی سادہ رکھا گیا ہے تاکہ اسے کسی بھی پلیٹ فارم پر دہرایا جا سکے۔
ایک واضح اصول بنائیں – ایک سادہ اور قابل مشاہدہ ہدایت لکھیں۔ مثال کے طور پر: "ایڈیٹنگ سے پہلے بالکل دو فائلیں لسٹ کریں۔" اس اصول کے اثر کو اسسٹنٹ کے جواب میں چیک کیا جا سکتا ہے۔
ٹول کا ورژن اور ماڈل چیک کریں – ایک نیا سیشن کھولیں، ورژن اسٹرنگ اور ماڈل آئیڈنٹیفائر (identifier) کو نوٹ کریں۔ مختلف ورژنز فائل کے نام کے ان طریقوں کو بدل سکتے ہیں جنہیں وہ پہچانتے ہیں۔
دو بار چلا کر دیکھیں (Execute two runs) Run A: ایسی فائل کا نام استعمال کریں جسے ٹول نہیں پہچانتا (مثلاً AGENTS.md)۔ Run B: ٹول کا اپنا (native) فائل نیم استعمال کریں (مثلاً CLAUDE.md)۔
درج کریں:
- فائل کا اصل ہیش (یہ ثابت کرنے کے لیے کہ ڈسک پر موجود مواد تبدیل نہیں ہوا)۔
- استعمال کیا گیا درست راستہ (path)۔
- اسسٹنٹ کی طرف سے فائل لوڈ کرنے کے بارے میں کوئی بھی ثبوت (ٹوکن کی تعداد میں اضافہ، واضح "loaded X.md" پیغام، وغیرہ)۔
- ہر درخواست کے لیے ٹوکن کی تعداد۔
- کام کا نتیجہ (کیا اسسٹنٹ نے بالکل دو فائلیں لسٹ کیں؟)۔
اگر Run B میں اصول کی پاسداری نظر آتی ہے اور ٹوکن کی تعداد متوقع حد تک بڑھتی ہے، تو اس کا مطلب ہے کہ فائل لوڈ بھی ہو رہی ہے اور مفید بھی ہے۔ اگر ٹوکن بڑھنے کے باوجود اصول کو نظر انداز کیا جاتا ہے، تو اس کا مطلب ہے کہ فائل تو پڑھی جا رہی ہے لیکن ماڈل کا پرامپٹ پارسنگ (parsing) اس ہدایت کو مسترد کر رہا ہے۔ ایسی صورت میں، فائل میں مزید متن شامل کرنے سے کوئی فائدہ نہیں ہوگا؛ اس کے بجائے اصول کو کسی ہارڈ کوڈڈ پالیسی گیٹ (policy gate) یا ٹیسٹ ہارنس (test harness) میں منتقل کر دیں۔
ڈیٹا کیا ظاہر کرتا ہے
Claude Code کے کیس نے کنفیگریشن اور لوڈنگ کے درمیان ایک واضح فرق کو ظاہر کیا۔ 72 KB کی فائل موجود تھی، اس کا ہیش درست تھا، اور وہ ریپوزٹری کے ساتھ سنک (sync) بھی تھی، پھر بھی اسسٹنٹ نے کبھی اس کا حوالہ نہیں دیا۔ فائل کا نام بدل کر native CLAUDE.md کرنے سے لوڈنگ تو شروع ہو گئی، لیکن اس سے ٹوکنز کا ایک بڑا بوجھ (overhead) بھی پیدا ہوا۔ ہر اضافی ٹوکن کمپیوٹ سائیکلز (compute cycles) استعمال کرتا ہے اور درخواست کو ریٹ لمٹس (rate limits) سے تجاوز کروا سکتا ہے۔
یہ تین مرحلہ وار ٹیسٹ ایسے پوشیدہ اخراجات کو پیداواری رکاوٹوں (production blockers) میں تبدیل ہونے سے پہلے ہی سامنے لے آتا ہے۔ ٹوکن ڈیلٹا (token delta) کو نوٹ کر کے، ٹیمیں یہ فیصلہ کر سکتی ہیں کہ آیا اصول کا فائدہ اس کی قیمت سے زیادہ ہے یا نہیں۔
خلاصہ
کبھی یہ فرض نہ کریں کہ صرف ریپوزٹری میں موجود ہونے کی وجہ سے کوئی رول فائل کام کر رہی ہے۔ اس مفروضے کو پیمائش کے قابل ثبوت میں بدلنے کے لیے تین مرحلہ وار ٹیسٹ—کنفیگر کریں، لوڈ کریں، اور افادیت ثابت کریں—کا استعمال کریں۔ جب ثبوت سے یہ ظاہر ہو کہ فائل محض ٹوکنز ضائع کرنے کا ذریعہ (token sink) ہے، تو اس منطق کو پرامپٹ سے نکال کر ایک ڈیٹرمینسٹک گیٹ (deterministic gate) میں منتقل کر دیں۔ اس کا نتیجہ ایک زیادہ بہتر، تیز رفتار، اور زیادہ قابلِ پیش گوئی AI کوڈنگ ورک فلو کی صورت میں نکلے گا۔