گزشتہ پانچ مہینوں کے دوران، ہماری ٹیم ایک تجربہ چلا رہی ہے: ایک سافٹ ویئر پروڈکٹ کا اندرونی بیٹا بنانا اور بھیجنا، جس میں دستی طور پر لکھے گئے کوڈ کی صفر لائنیں ہیں.
پروڈکٹ کے اندرونی روزانہ صارفین اور بیرونی الفا ٹیسٹرز ہیں. یہ بھیجا جاتا ہے، تعینات ہوتا ہے، خراب ہوتا ہے اور پھر ٹھیک کیا جاتا ہے. جو چیز مختلف ہے وہ یہ ہے کہ کوڈ کی ہر لائن—ایپلیکیشن لاجک، ٹیسٹس، CI کنفیگریشن، دستاویزات، آبزرویبیلٹی اور اندرونی ٹولنگ—Codex نے لکھی ہے. ہم اندازہ لگاتے ہیں کہ ہم نے اسے تقریباً 1/10 ویں وقت میں بنایا، جتنا وقت ہاتھ سے کوڈ لکھنے میں لگتا.
انسان رہنمائی کرتے ہیں. ایجنٹس عمل کرتے ہیں.
ہم نے جان بوجھ کر یہ پابندی منتخب کی تاکہ ہم وہی چیز بنائیں جو انجینئرنگ کی رفتار کو کئی گنا بڑھانے کے لیے ضروری ہو. ہمارے پاس بھیجنے کے لیے ہفتوں کا وقت تھا جو کوڈ کی دس لاکھ لائنوں پر مشتمل تھا. ایسا کرنے کے لیے، ہمیں یہ سمجھنے کی ضرورت ہے کہ جب سافٹ ویئر انجینئرنگ ٹیم کا بنیادی کام اب کوڈ لکھنا نہیں ہے، بلکہ ماحول کو ڈیزائن کرنا، ارادے کی وضاحت کرنا اور فیڈ بیک لوپس بنانا ہے جو Codex ایجنٹوں کو قابل اعتماد کام کرنے کی اجازت دیتے ہیں.
یہ پوسٹ اس بارے میں ہے کہ ہم نے ایجنٹس کی ایک ٹیم کے ساتھ بالکل نئی پروڈکٹ بنا کر کیا سیکھا—کیا ٹوٹا، کیا بڑھا اور اپنے واحد واقعی نایاب وسیلے کو کیسے زیادہ سے زیادہ استعمال کیا جائے: انسانی وقت اور توجہ.
ایک خالی ریپوزٹری میں پہلی کمٹ اگست 2025 کے آخر میں کی گئی.
ابتدائی اسکیفولڈ—ریپوزٹری کی ساخت، CI کنفیگریشن، فارمیٹنگ کے قواعد، پیکیج مینیجر سیٹ اپ اور ایپلیکیشن فریم ورک—Codex CLI نے GPT‑5 کا استعمال کرتے ہوئے تیار کیا، جس کی رہنمائی موجودہ ٹیمپلیٹس کے ایک چھوٹے مجموعے نے کی. یہاں تک کہ ابتدائی AGENTS.md فائل، جو ایجنٹس کو ریپوزٹری میں کام کرنے کی ہدایت دیتی ہے، وہ بھی Codex نے لکھی تھی.
سسٹم کو بنیاد فراہم کرنے کے لیے کوئی پہلے سے موجود انسانی تحریر کردہ کوڈ نہیں تھا. شروع سے ہی، ریپوزٹری کو ایجنٹ نے تشکیل دیا تھا.
پانچ ماہ بعد، ریپوزٹری ایپلی کیشن لاجک، انفراسٹرکچر، ٹولنگ، دستاویزات اور اندرونی ڈویلپر کی افادیت میں کوڈ کی ایک ملین لائنوں کے آرڈر پر مشتمل ہے. اس مدت کے دوران، تقریباً 1,500 pull requests کھولی اور ضم کی گئی ہیں، جبکہ صرف تین انجینئرز کی ایک چھوٹی ٹیم Codex کو چلا رہی ہے. یہ فی انجینئر فی دن اوسطاً 3.5 PRs کے تھروپٹ کے طور پر ظاہر ہوتا ہے اور حیرت انگیز طور پر، جیسے جیسے ٹیم اب سات انجینئرز تک بڑھ گئی ہے، تھروپٹ میں اضافہ ہوا ہے. اہم بات یہ ہے کہ یہ آؤٹ پٹ محض آؤٹ پٹ کے لیے نہیں تھا: اس پروڈکٹ کو اندرونی طور پر سینکڑوں صارفین نے استعمال کیا ہے، جن میں روزانہ کے اندرونی پاور صارفین بھی شامل ہیں.
ترقی کے پورے عمل کے دوران، انسانوں نے کبھی بھی براہ راست کوئی کوڈ نہیں لکھا. یہ ٹیم کے لیے ایک بنیادی فلسفہ بن گیا: کوئی دستی طور پر لکھا ہوا کوڈ نہیں.
ہاتھوں سے انسانی کوڈنگ کی کمی نے انجینئرنگ کے کام کی ایک مختلف قسم متعارف کرائی، جو نظامات، ڈھانچے اور فائدہ اٹھانے پر مرکوز تھی.
ابتدائی پیش رفت ہماری توقع سے سست تھی، اس لیے نہیں کہ Codex نااہل تھا، بلکہ اس لیے کہ ماحول کی وضاحت ناکافی تھی. ایجنٹ کے پاس وہ ٹولز، تجریدات اور اندرونی ڈھانچہ نہیں تھا جو اعلٰی سطحی اہداف کی طرف پیش رفت کے لیے ضروری تھا. ہماری انجینئرنگ ٹیم کا بنیادی کام یہ بن گیا کہ ایجنٹس کو مفید کام کرنے کے قابل بنایا جائے.
عملی طور پر، اس کا مطلب یہ تھا کہ ڈیپتھ-فرسٹ انداز میں کام کیا جائے: بڑے اہداف کو چھوٹے تعمیراتی بلاکس (ڈیزائن، کوڈ، ریویو، ٹیسٹ، وغیرہ) میں توڑنا، ایجنٹ کو ان بلاکس کی تشکیل کے لیے پرامپٹ کرنا اور انہیں زیادہ پیچیدہ کاموں کو ممکن بنانے کے لیے استعمال کرنا. جب کچھ ناکام ہوتا تھا، تو اس کا حل تقریباً کبھی بھی "زیادہ محنت کریں." نہیں ہوتا تھا. کیونکہ ترقی کرنے کا واحد طریقہ یہ تھا کہ Codex کو کام کرنے دیا جائے، انسانی انجینئرز ہمیشہ اس کام میں شامل ہوتے اور پوچھتے: "کون سی صلاحیت غائب ہے اور ہم اسے ایجنٹ کے لیے بیک وقت قابلِ فہم اور قابلِ نفاذ کیسے بناتے ہیں؟"
انسان تقریباً مکمل طور پر پرومپٹس کے ذریعے سسٹم کے ساتھ تعامل کرتے ہیں: ایک انجینئر ایک کام کی وضاحت کرتا ہے، ایجنٹ کو چلاتا ہے اور اسے pull request کھولنے کی اجازت دیتا ہے. ایک PR کو مکمل کرنے کے لیے، ہم Codex کو ہدایت دیتے ہیں کہ وہ اپنی تبدیلیوں کا مقامی طور پر جائزہ لے، مقامی اور کلاؤڈ میں اضافی مخصوص ایجنٹ جائزوں کی درخواست کرے، انسان یا ایجنٹ کی جانب سے دیے گئے کسی بھی فیڈبیک کا جواب دے اور ایک لوپ میں تکرار کرے جب تک کہ تمام ایجنٹ جائزہ کار مطمئن نہ ہو جائیں (یہ دراصل ایک رالف وگم لوپ(نئی ونڈو میں کھلتا ہے) ہے). Codex ہمارے معیاری ڈیولپمنٹ ٹولز کو براہ راست (gh، لوکل اسکرپٹس اور ریپوزٹری میں شامل مہارتیں) استعمال کرتا ہے تاکہ انسانوں کے CLI میں کاپی اور پیسٹ کیے بغیر سیاق و سباق جمع کیا جا سکے.
انسان pull requests کا جائزہ لے سکتے ہیں، لیکن ان کے لیے ایسا کرنا ضروری نہیں ہے. وقت کے ساتھ، ہم نے تقریباً تمام جائزہ کی کوشش کو ایجنٹ سے ایجنٹ کے درمیان سنبھالے جانے کی طرف منتقل کر دیا ہے.
جب کوڈ تھروپٹ میں اضافہ ہوا، تو ہماری رکاوٹ انسانی QA کی صلاحیت بن گئی. چونکہ مقررہ رکاوٹ انسانی وقت اور توجہ رہی ہے، ہم نے ایجنٹ میں مزید صلاحیتیں شامل کرنے کے لیے کام کیا ہے، تاکہ ایپلیکیشن UI، لاگز اور ایپ میٹرکس جیسی چیزیں Codex کے لیے براہ راست قابل فہم بن سکیں.
مثال کے طور پر، ہم نے ایپ کو بوٹ ایبل فی گٹ ورک ٹری بنایا ہے، تاکہ Codex فی تبدیلی ایک مثال کو لانچ اور چلا سکے. ہم نے ایجنٹ کے رن ٹائم میں Chrome DevTools پروٹوکول کو بھی وائر کیا اور DOM اسنیپ شاٹس، اسکرین شاٹس اور نیویگیشن کے ساتھ کام کرنے کے لیے مہارتیں پیدا کیں. اس نے Codex کو بگز کو دوبارہ پیدا کرنے، اصلاحات کی توثیق کرنے اور UI کے رویے کے بارے میں براہ راست استدلال کرنے کے قابل بنایا.
ہم نے مشاہدہ پذیری کے ٹولزوں کے لیے بھی یہی کیا. لاگز، میٹرکس اور ٹریسز Codex کو ایک مقامی آبزرویبیلٹی اسٹیک کے ذریعے فراہم کیے جاتے ہیں جو کسی بھی مخصوص ورک ٹری کے لیے عارضی ہوتا ہے. Codex اس ایپ کے مکمل طور پر الگ تھلگ ورژن پر کام کرتا ہے—بشمول اس کے لاگز اور میٹرکس، جو ٹاسک مکمل ہونے کے بعد ختم کر دیے جاتے ہیں. ایجنٹس LogQL کے ساتھ لاگز اور PromQL کے ساتھ میٹرکس کو کوئری کر سکتے ہیں. اس سیاق و سباق کی دستیابی کے ساتھ، "اس بات کو یقینی بنائیں کہ سروس اسٹارٹ اپ 800ms سے کم میں مکمل ہو جائے" یا "صارف کے ان چار اہم سفروں میں کوئی وقفہ دو سیکنڈ سے زیادہ نہ ہو" جیسے اشارے قابل عمل ہو جاتے ہیں.
ہم باقاعدگی سے دیکھتے ہیں کہ ایک ہی Codex رن ایک ہی کام پر چھ گھنٹے سے زیادہ وقت تک کام کرتا ہے (اکثر جب انسان سو رہے ہوتے ہیں).
سیاق و سباق کا انتظام ایجنٹس کو بڑے اور پیچیدہ کاموں میں مؤثر بنانے کے لیے سب سے بڑے چیلنجز میں سے ایک ہے. ہم نے جو ابتدائی ترین اسباق سیکھے، ان میں سے ایک سادہ تھا: Codex کو ایک نقشہ دیں، نہ کہ 1,000 صفحات پر مشتمل ہدایات نامہ.
ہم نے "ایک بڑی AGENTS.md(نئی ونڈو میں کھلتا ہے)" کو آزمایا طریقہ. یہ متوقع طریقوں سے ناکام ہوا:
- سیاق ایک نایاب وسیلہ ہے. ایک بڑی ہدایتی فائل کام، کوڈ اور متعلقہ دستاویزات کو پیچھے چھوڑ دیتی ہے—جس کی وجہ سے ایجنٹ یا تو اہم پابندیوں کو نظرانداز کر دیتا ہے یا غلط پابندیوں کے لیے اصلاح شروع کر دیتا ہے.
- بہت زیادہ رہنمائی غیر رہنمائی بن جاتی ہے. جب ہر چیز "اہم" ہو، تو کچھ بھی اہم نہیں رہتا. ایجنٹس جان بوجھ کر نیویگیٹ کرنے کے بجائے مقامی طور پر پیٹرن-میچنگ کرنے لگتے ہیں.
- یہ فوراً گل سڑ جاتا ہے. ایک یک سنگی دستی کتاب باسی اصولوں کے قبرستان میں تبدیل ہو جاتی ہے. ایجنٹس یہ نہیں بتا سکتے کہ کیا اب بھی درست ہے، انسان اسے برقرار رکھنا چھوڑ دیتے ہیں اور فائل خاموشی سے ایک پرکشش خطرہ بن جاتی ہے.
- یہ تصدیق کرنا مشکل ہے. ایک واحد بلاک میکینیکل چیکس (کوریج، تازگی، ملکیت، کراس-لنکس) کے لیے موزوں نہیں ہوتا، اس لیے انحراف ناگزیر ہے.
لہٰذا AGENTS.md کو انسائیکلوپیڈیا کے بجائے فہرستِ مضامین سمجھا جاتا ہے.
ریپوزٹری کا علمی ذخیرہ ایک منظم docs/ ڈائریکٹری میں موجود ہے جسے نظامی ریکارڈ کے طور پر استعمال کیا جاتا ہے. ایک مختصر AGENTS.md (تقریباً 100 لائنیں) سیاق و سباق میں شامل کی جاتی ہے اور بنیادی طور پر ایک نقشے کے طور پر کام کرتی ہے، جس میں کہیں اور موجود حقیقت کے گہرے ذرائع کی طرف اشارے ہوتے ہیں.
ڈیزائن دستاویزات کو کیٹلاگ اور انڈیکس کیا جاتا ہے، جس میں توثیق کی حیثیت اور بنیادی عقائد کا ایک مجموعہ شامل ہوتا ہے جو ایجنٹ-فرسٹ آپریٹنگ اصولوں کی وضاحت کرتا ہے. آرکیٹیکچر ڈاکیومینٹیشن(نئی ونڈو میں کھلتا ہے) ڈومینز اور پیکیج لیئرنگ کا اعلٰی سطحی نقشہ فراہم کرتی ہے. ایک معیاری دستاویز ہر پروڈکٹ ڈومین اور آرکیٹیکچرل لیئر کی درجہ بندی کرتی ہے اور وقت کے ساتھ خلا کو ٹریک کرتی ہے.
پلانز کو اعلٰی درجے کی دستاویزات کے طور پر سمجھا جاتا ہے. عارضی ہلکے پھلکے منصوبے چھوٹی تبدیلیوں کے لیے استعمال ہوتے ہیں، جبکہ پیچیدہ کام کو عمل درآمد کے پلانز(نئی ونڈو میں کھلتا ہے) میں پیش رفت اور فیصلوں کے لاگز کے ساتھ محفوظ کیا جاتا ہے، جو ریپوزٹری میں چیک اِن کیے جاتے ہیں. فعال پلانز، مکمل شدہ منصوبے اور معلوم تکنیکی قرض سبھی ورژنڈ اور ایک ہی جگہ پر موجود ہیں، جس سے ایجنٹس بیرونی سیاق و سباق پر انحصار کیے بغیر کام کر سکتے ہیں.
یہ تدریجی انکشاف کو فعال کرتا ہے: ایجنٹس ایک چھوٹے، مستحکم نقطۂ آغاز سے شروع کرتے ہیں اور انہیں سکھایا جاتا ہے کہ آگے کہاں دیکھنا ہے، بجائے اس کے کہ ابتدا ہی میں وہ مغلوب ہو جائیں.
ہم اس کو میکانکی طور پر نافذ کرتے ہیں. مخصوص لنٹرز اور CI جابز تصدیق کرتے ہیں کہ نالج بیس تازہ ترین، کراس-لنکڈ اور درست طور پر ساختہ ہے. ایک بار بار چلنے والا "doc-gardening" ایجنٹ پرانی یا متروک دستاویزات کی تلاش کے لیے اسکین کرتا ہے جو حقیقی کوڈ کے رویے کی عکاسی نہیں کرتیں اور درستگی کے لیے pull requests کھولتا ہے.
جیسے جیسے کوڈ بیس ارتقاء پذیر ہوا، Codex کے ڈیزائن فیصلوں کے لیے فریم ورک کو بھی ارتقاء پذیر ہونا پڑا.
چونکہ ریپوزٹری مکمل طور پر ایجنٹ کے ذریعے تیار کی گئی ہے، اس لیے اسے سب سے پہلے Codex کی پڑھنے کی صلاحیت کے لیے بہتر بنایا گیا ہے. اسی طرح جیسے ٹیمیں نئے انجینئرنگ ہائرز کے لیے اپنے کوڈ کی نیویگیبیلٹی بہتر بنانے کا ہدف رکھتی ہیں، ہمارے انسانی انجینئرز کا مقصد یہ ممکن بنانا تھا کہ ایک ایجنٹ مکمل کاروباری ڈومین کے بارے میں براہِ راست ریپوزٹری سے ہی استدلال کر سکے.
ایجنٹ کے نقطۂ نظر سے، جو کچھ بھی وہ چلتے وقت سیاق و سباق میں مؤثر طور پر رسائی حاصل نہیں کر سکتا، وہ مؤثر طور پر موجود نہیں ہوتا. Google Docs، چیٹ تھریڈز، یا لوگوں کے ذہنوں میں موجود علم نظام کے لیے قابل رسائی نہیں ہے. ریپوزٹری-لوکل، ورژن شدہ آرٹیفیکٹس (مثلاً، کوڈ، مارک ڈاؤن، اسکیماز، قابلِ عمل پلانز) یہی سب کچھ ہے جو یہ دیکھ سکتا ہے.
ہم نے یہ سیکھا کہ وقت کے ساتھ ساتھ ہمیں ریپو میں مزید اور مزید سیاق و سباق شامل کرنے کی ضرورت ہے. وہ Slack کی گفتگو جس نے ٹیم کو ایک آرکیٹیکچرل پیٹرن پر ہم آہنگ کیا؟ اگر یہ ایجنٹ کے لیے قابلِ دریافت نہیں ہے، تو یہ اسی طرح ناقابلِ فہم ہے جیسے تین ماہ بعد شامل ہونے والے نئے ملازم کے لیے یہ نامعلوم ہوگا.
Codex کو زیادہ سیاق و سباق فراہم کرنے کا مطلب ہے کہ درست معلومات کو منظم کرنا اور نمایاں کرنا تاکہ ایجنٹ اس پر بہتر طور پر استدلال کر سکے، بجائے اس کے کہ اسے بے ترتیب ہدایات سے مغلوب کر دیا جائے. بالکل اسی طرح جیسے آپ کسی نئے ساتھی کو پروڈکٹ کے اصولوں، انجینئرنگ کے معیارات اور ٹیم کی ثقافت (ایموجی کی ترجیحات سمیت) پر شامل کرتے ہیں، ایجنٹ کو یہ معلومات دینے سے بہتر ہم آہنگی والا نتیجہ حاصل ہوتا ہے.
اس فریم ورک نے بہت سے سمجھوتوں کو واضح کیا. ہم نے انحصارات اور تجریدات کو ترجیح دی جنہیں ریپو کے اندر مکمل طور پر داخلی بنایا جا سکے اور جن پر استدلال کیا جا سکے. جن ٹیکنالوجیز کو اکثر "بورنگ" کہا جاتا ہے، وہ مرکبیت، API استحکام اور تربیتی سیٹ میں نمائندگی کی وجہ سے ایجنٹس کے لیے ماڈل بنانا زیادہ آسان ہوتی ہیں. بعض اوقات، عوامی لائبریریوں کے غیر واضح اپ اسٹریم رویے کے گرد کام کرنے کے بجائے ایجنٹ سے فعالیت کے ذیلی حصے دوبارہ نافذ کروانا زیادہ سستا تھا. مثال کے طور پر، ایک عمومی p-limit-اسٹائل پیکیج شامل کرنے کے بجائے، ہم نے اپنا map-with-concurrency helper نافذ کیا: یہ ہماری OpenTelemetry instrumentation کے ساتھ مضبوطی سے مربوط ہے، اس کی 100% ٹیسٹ کوریج ہے اور یہ بالکل اسی طرح کام کرتا ہے جیسا کہ ہمارا رن ٹائم توقع کرتا ہے.
سسٹم کے مزید حصے کو ایسی شکل میں لانا جسے ایجنٹ براہ راست جانچ، توثیق اور ترمیم کر سکے، فائدہ بڑھاتا ہے—صرف Codex کے لیے نہیں، بلکہ دوسرے ایجنٹس کے لیے بھی (مثلاً) Aardvark) جو کوڈ بیس پر بھی کام کر رہے ہیں.
صرف دستاویزات مکمل طور پر ایجنٹ کے ذریعے تیار کردہ کوڈ بیس کو مربوط نہیں رکھ سکتی ہیں. انویریئنٹس کو نافذ کرتے ہوئے، نفاذ کی باریک بینی سے نگرانی کیے بغیر، ہم ایجنٹس کو بنیاد کو متاثر کیے بغیر تیزی سے کام کرنے کی اجازت دیتے ہیں. مثال کے طور پر، ہم Codex سے حد پر ڈیٹا شیپس کو پارس کرنے(نئی ونڈو میں کھلتا ہے) کا تقاضا کرتے ہیں، لیکن ہم اس بات پر کوئی پابندی نہیں لگاتے کہ یہ کیسے ہوتا ہے (ماڈل کو Zod پسند آتا ہے، لیکن ہم نے اس مخصوص لائبریری کی وضاحت نہیں کی ہے).
ایجنٹس ان ماحولوں میں سب سے زیادہ مؤثر ہوتے ہیں جہاں سخت حدود اور پیش گوئی کے قابل ساخت(نئی ونڈو میں کھلتا ہے) ہو، اس لیے ہم نے ایپلیکیشن کو ایک سخت معماری ماڈل کے گرد بنایا. ہر کاروباری ڈومین کو تہوں کے ایک مقررہ سیٹ میں تقسیم کیا جاتا ہے، جن میں انحصار کی سمتوں کی سختی سے تصدیق کی جاتی ہے اور قابل اجازت کناروں کا ایک محدود سیٹ ہوتا ہے. یہ پابندیاں میکانکی طور پر کسٹم لنٹرز (Codex-جنریٹ کردہ، یقیناً!) اور ساختی ٹیسٹس کے ذریعے نافذ کی جاتی ہیں.
نیچے دی گئی ڈایاگرام یہ قاعدہ دکھاتی ہے: ہر کاروباری ڈومین کے اندر (مثال کے طور پر، ایپ سیٹنگز)، کوڈ صرف لیئرز کے ایک مقررہ سیٹ کے ذریعے "فارورڈ" پر انحصار کر سکتا ہے (اقسام → کنفیگریشن → ریپو → سروس → رن ٹائم → UI). کراس-کٹنگ خدشات (توثیق کاری، کنیکٹر، ٹیلی میٹری، خصوصیت کے جھنڈے) ایک واحد واضح انٹرفیس کے ذریعے داخل ہوتے ہیں: فراہم کنندگان. کچھ اور ممنوع ہے اور اس پر میکانکی طور پر عمل درآمد ہوتا ہے.
یہ وہ قسم کا آرکیٹیکچر ہے جسے آپ عام طور پر اس وقت تک مؤخر کرتے ہیں جب تک کہ آپ کے پاس سینکڑوں انجینئرز نہ ہوں. کوڈنگ ایجنٹس کے ساتھ، یہ ایک ابتدائی شرط ہے: پابندیاں وہ عناصر ہیں جو زوال یا آرکیٹیکچرل ڈریفٹ کے بغیر تیز رفتاری کو ممکن بناتی ہیں.
عملی طور پر، ہم ان قواعد کو حسب ذوق لنٹرز اور ساختی ٹیسٹس کے ذریعے نافذ کرتے ہیں، نیز "ذوقی غیر متغیرات" کے ایک چھوٹے مجموعے کے ساتھ. مثال کے طور پر، ہم کسٹم لنٹس کے ذریعے اسٹرکچرڈ لاگنگ، اسکیما اور اقسام کے لیے نام رکھنے کے اصول، فائل سائز کی حدود اور پلیٹ فارم کے لحاظ سے مخصوص قابلِ اعتماد ہونے کی ضروریات کو جامد طور پر نافذ کرتے ہیں. چونکہ لنٹس حسب ضرورت ہیں، ہم ایجنٹ کے سیاق و سباق میں اصلاحی ہدایات شامل کرنے کے لیے خطا کے پیغامات لکھتے ہیں.
انسان-مرکوز ورک فلو میں، یہ قواعد شاید باریک بین یا محدود کرنے والے محسوس ہوں. ایجنٹس کے ساتھ، وہ ضرب دینے والے بن جاتے ہیں: ایک بار انکوڈ ہو جانے کے بعد، وہ ایک ہی وقت میں ہر جگہ لاگو ہو جاتے ہیں.
اسی وقت، ہم واضح طور پر بتاتے ہیں کہ پابندیاں کہاں اہمیت رکھتی ہیں اور کہاں نہیں رکھتیں. یہ ایک بڑی انجینئرنگ پلیٹ فارم تنظیم کی قیادت کرنے کے مترادف ہے: حدود کو مرکزی طور پر نافذ کریں، مقامی سطح پر خود مختاری کی اجازت دیں. آپ کو حدود، درستگی اور قابلِ تکراریت کی گہری پروا ہے. ان حدود کے اندر، آپ ٹیموں—یا ایجنٹس—کو اس بات میں نمایاں آزادی دیتے ہیں کہ حل کس طرح ظاہر کیے جائیں.
نتیجے میں حاصل ہونے والا کوڈ ہمیشہ انسانی اسلوبی ترجیحات سے میل نہیں کھاتا اور یہ ٹھیک ہے. جب تک آؤٹ پٹ درست، برقرار رکھنے کے قابل اور مستقبل کی ایجنٹ رنز کے لیے قابلِ فہم ہو، یہ معیار پر پورا اترتا ہے.
انسانی ذوق کو مسلسل نظام میں واپس شامل کیا جاتا ہے. ریویو تبصرے، ریفیکٹرنگ pull request اور صارف کے سامنے آنے والے بگز کو دستاویزی اپ ڈیٹس کے طور پر محفوظ کیا جاتا ہے یا براہِ راست ٹولنگ میں انکوڈ کیا جاتا ہے. جب دستاویزات ناکافی ثابت ہوتی ہیں، تو ہم اس اصول کو کوڈ میں شامل کر دیتے ہیں
جب Codex کا تھروپٹ بڑھا، تو بہت سے روایتی انجینئرنگ معیارات نقصان دہ ثابت ہونے لگے.
ریپوزٹری کم سے کم بلاکنگ مرج گیٹس کے ساتھ کام کرتی ہے. pull requests مختصر مدت کے لیے ہوتے ہیں. ٹیسٹ فلیکس کو اکثر پیش رفت کو غیر معینہ مدت تک روکنے کے بجائے فالو اپ رنز کے ذریعے حل کیا جاتا ہے. ایسے نظام میں جہاں ایجنٹ کا تھروپٹ انسانی توجہ سے کہیں زیادہ ہو، اصلاحات سستی ہیں اور انتظار مہنگا ہے.
کم تھروپٹ والے ماحول میں یہ غیر ذمہ دارانہ ہوگا. یہاں، یہ اکثر صحیح سمجھوتہ ہوتا ہے.
جب ہم کہتے ہیں کہ کوڈ بیس Codex ایجنٹس کے ذریعے تیار کیا گیا ہے، تو ہمارا مطلب کوڈ بیس کی ہر چیز سے ہوتا ہے.
ایجنٹس پیدا کرتے ہیں:
- پروڈکٹ کوڈ اور ٹیسٹ
- CI کنفیگریشن اور ریلیز کے ٹولز
- اندرونی ڈویلپر ٹولز
- دستاویزات اور ڈیزائن کی تاریخ
- تجزیہ کے ہارنیسز
- تبصرے اور جوابات کا جائزہ لیں
- وہ اسکرپٹس جو ریپوزٹری کا خود انتظام کرتے ہیں
- پروڈکشن ڈیش بورڈ کی تعریف کی فائلیں
انسان ہمیشہ عمل میں شامل رہتے ہیں، لیکن ہم پہلے کے مقابلے میں تجرید کی ایک مختلف سطح پر کام کرتے ہیں. ہم کام کو ترجیح دیتے ہیں، صارف کی آراء کو قبولیت کے معیار میں تبدیل کرتے ہیں اور نتائج کی تصدیق کرتے ہیں. جب ایجنٹ کو مشکل پیش آتی ہے، تو ہم اسے ایک اشارہ سمجھتے ہیں: یہ شناخت کریں کہ کیا چیز غائب ہے—ٹولز، گارڈ ریلز، دستاویزات—اور اسے ریپوزٹری میں واپس شامل کریں، ہمیشہ Codex سے ہی فکس لکھوائیں.
ایجنٹس ہمارے معیاری ترقیاتی ٹولز براہ راست استعمال کرتے ہیں. وہ جائزے کی رائے حاصل کرتے ہیں، ان لائن پر ردعمل/جواب دیتے ہیں، اپ ڈیٹس پش کرتے ہیں اور اکثر اپنی ہی pull requests کو سکویش اور ضم کرتے ہیں.
جیسے جیسے ترقیاتی لوپ کے مزید حصے کو براہ راست نظام میں انکوڈ کیا گیا—جیسے کہ جانچ، توثیق، جائزہ، فیڈبیک ہینڈلنگ اور بحالی—ریپوزٹری نے حال ہی میں ایک اہم سنگ میل عبور کیا ہے جہاں Codex مکمل طور پر ایک نئی خصوصیت کو چلا سکتا ہے.
ایک واحد پرومپٹ کے ساتھ، ایجنٹ اب یہ کر سکتا ہے:
- کوڈ بیس کی موجودہ حالت کی تصدیق کریں
- رپورٹ شدہ بگ کو دوبارہ پیدا کریں
- ناکامی کو ظاہر کرنے کے لیے ویڈیو ریکارڈ کریں
- ایک درستگی نافذ کریں
- ایپلیکیشن کو چلا کر درستگی کی تصدیق کریں
- قرارداد کا مظاہرہ کرنے والی دوسری ویڈیو ریکارڈ کریں
- pull request کھولیں
- ایجنٹ اور انسانی فیڈبیک کا جواب دیں
- بلڈ ناکامیوں کی نشاندہی کریں اور ان کو درست کریں
- انسانی فیصلے کی ضرورت ہو تو ہی کسی انسان کو منتقل کریں
- تبدیلی کو شامل کریں
یہ رویہ اس ریپوزٹری کی مخصوص ساخت اور ٹولزوں پر بہت زیادہ انحصار کرتا ہے اور اسے اسی طرح کی سرمایہ کاری کے بغیر عمومی طور پر قابلِ اطلاق نہیں سمجھا جانا چاہیے—کم از کم، ابھی نہیں.
مکمل ایجنٹ کی خود مختاری نئے مسائل بھی متعارف کراتی ہے. Codex ریپوزٹری میں پہلے سے موجود پیٹرنز کی نقل کرتا ہے—یہاں تک کہ ناہموار یا غیر موزوں پیٹرنز بھی. وقت کے ساتھ، یہ ناگزیر طور پر انحراف کا باعث بنتا ہے.
ابتدائی طور پر، انسانوں نے اس مسئلے کو دستی طور پر حل کیا. ہماری ٹیم ہر جمعہ (ہفتے کا 20%) "AI کی گندگی" کو صاف کرنے میں وقت گزارتی تھی. حیرت کی بات نہیں، یہ پیمانے پر پورا نہیں اترا.
اس کے بجائے، ہم نے جسے ہم "سنہری اصول" کہتے ہیں، انہیں براہ راست ریپوزٹری میں انکوڈ کرنا شروع کیا اور ایک بار بار ہونے والا صفائی کا عمل تیار کیا. یہ اصول رائے پر مبنی، میکانکی قواعد ہیں جو کوڈ بیس کو قابلِ فہم اور یکساں رکھتے ہیں تاکہ مستقبل کے ایجنٹ رنز کے لیے یکسانیت اور وضاحت برقرار رہے. مثال کے طور پر: (1) ہم انویرئینٹس کو مرکزی رکھنے کے لیے ہاتھ سے بنائے گئے مددگاروں کے بجائے مشترکہ یوٹیلیٹی پیکجز کو ترجیح دیتے ہیں اور (2) ہم ڈیٹا کی "YOLO-style" میں جانچ نہیں کرتے—ہم حدود کی توثیق کرتے ہیں یا ٹائپ شدہ SDKs پر انحصار کرتے ہیں تاکہ ایجنٹ غلطی سے اندازہ لگائی گئی شکلوں پر بنیاد نہ رکھ سکے. باقاعدہ وقفوں پر، ہمارے پاس پس منظر میں Codex کے ٹاسکس کا ایک مجموعہ ہوتا ہے جو انحرافات کے لیے اسکین کرتا ہے، کوالٹی گریڈز کو اپ ڈیٹ کرتا ہے، اور ہدفی ری فیکٹرنگ پل ریکوئسٹ کھولتا ہے. ان میں سے زیادہ تر کا ایک منٹ سے بھی کم وقت میں جائزہ لیا جا سکتا ہے اور خودکار طور پر ضم کیا جا سکتا ہے.
یہ گاربیج کلیکشن کی طرح کام کرتا ہے. تکنیکی قرض ایک زیادہ سود والے قرض کی طرح ہے: یہ تقریباً ہمیشہ بہتر ہوتا ہے کہ اسے مسلسل چھوٹے چھوٹے حصوں میں کم کیا جائے، بجائے اس کے کہ اسے بڑھنے دیا جائے اور پھر تکلیف دہ جھٹکوں میں اس سے نمٹا جائے. انسانی ذوق کو ایک بار محفوظ کیا جاتا ہے، پھر کوڈ کی ہر لائن پر مسلسل لاگو کیا جاتا ہے. یہ ہمیں روزانہ کی بنیاد پر خراب پیٹرنز کو پکڑنے اور حل کرنے کی اجازت دیتا ہے، بجائے اس کے کہ انہیں دنوں یا ہفتوں تک کوڈ بیس میں پھیلنے دیا جائے.
یہ حکمت عملی اب تک OpenAI میں اندرونی لانچ اور اپنانے تک کامیابی سے کام کر رہی ہے. حقیقی صارفین کے لیے ایک حقیقی پروڈکٹ کی تعمیر نے ہماری سرمایہ کاریوں کو حقیقت میں مضبوطی سے قائم رکھنے میں مدد کی اور ہمیں طویل مدتی پائیداری کی طرف رہنمائی کی.
ہم ابھی تک یہ نہیں جانتے کہ ایک مکمل طور پر ایجنٹ کے ذریعے تیار کردہ نظام میں معماری ہم آہنگی برسوں کے دوران کیسے ترقی کرتی ہے. ہم ابھی بھی یہ سیکھ رہے ہیں کہ انسانی فیصلہ کہاں سب سے زیادہ اثر ڈالتا ہے اور اس فیصلے کو کیسے انکوڈ کیا جائے تاکہ وہ بڑھتا رہے. ہمیں یہ بھی معلوم نہیں کہ جیسے جیسے ماڈل وقت کے ساتھ مزید قابل ہوتے جائیں گے، یہ نظام کیسے ارتقاء پذیر ہوگا.
جو بات واضح ہو چکی ہے: سافٹ ویئر بنانا اب بھی نظم و ضبط کا تقاضا کرتا ہے، لیکن یہ نظم و ضبط کوڈ کے بجائے زیادہ تر اس کے سہارے کے ڈھانچے میں نظر آتا ہے. وہ ٹولنگ، تجریدات اور فیڈبیک لوپس جو کوڈ بیس کو مربوط رکھتے ہیں، دن بدن زیادہ اہمیت اختیار کر رہے ہیں.
اب ہمارے سب سے مشکل چیلنجز ایسے ماحول، فیڈبیک لوپس اور کنٹرول سسٹمز ڈیزائن کرنے پر مرکوز ہیں جو ایجنٹس کو ہمارا مقصد حاصل کرنے میں مدد دیں: بڑے پیمانے پر پیچیدہ، قابلِ اعتماد سافٹ ویئر بنانا اور برقرار رکھنا.
جب Codex جیسے ایجنٹس سافٹ ویئر لائف سائیکل کے بڑے حصے سنبھالیں گے، تو یہ سوالات اور بھی زیادہ اہمیت اختیار کر جائیں گے. ہم امید کرتے ہیں کہ کچھ ابتدائی اسباق شیئر کرنے سے آپ کو یہ سمجھنے میں مدد ملے گی کہ اپنی کوشش کہاں لگانی ہے تاکہ آپ بس چیزیں بنا سکیں.
