لوپ انجینئرنگ۔
ماخذ: Addy Osmani
ترجمہ: پیگی، بلاک بیٹس

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

یہ چکر تقریباً پانچ ماڈیولز پر مشتمل ہے: Automations (ٹائمڈ ایکشنز اور ٹریج کاروائیاں)، Worktrees (متعدد متوازی ڈویلپمنٹ ماحولوں کو الگ کرنا)، Skills (منصوبوں کے علم اور ٹیم کے معمولات کو جمع کرنا)، Plugins/Connectors (GitHub، Linear، Slack، ڈیٹا بیس جیسے اصل ٹولز سے جُڑنا)، Sub-agents (انفیکشن اور جانچنے والے کو الگ کرنا)، اور ایک باہری میموری لیئر، جیسے Markdown فائل یا Linear بورڈ، جو حالت اور پیش رفت کو محفوظ رکھنے کے لیے استعمال ہوتا ہے۔

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

یہ نص درج ذیل ہے:

لوپ انجینئرنگ (Loop Engineering) آپ کے اس کردار کو ختم کر رہا ہے جس میں آپ "ایجینٹس کو پرامپٹس لکھتے ہیں"۔ آپ کو ایک ایسا نظام ڈیزائن کرنا ہوگا جو آپ کی جگہ ایجینٹس کو پرامپٹ دے۔ یہاں لوپ (Loop) کو ایک ریکرسیو مقصد کے طور پر سمجھا جا سکتا ہے: آپ ایک مقصد تعریف کرتے ہیں، اور AI اسے مکمل کرنے تک بار بار دہراتا ہے۔ یہ تقریباً پانچ اجزاء پر مشتمل ہے، اور اب Claude Code اور Codex دونوں ان پانچ اجزاء کو حاصل کر چکے ہیں۔

میں یہ سمجھتا ہوں کہ یہ شاید ہمارے مستقبل میں کوڈنگ ایجینٹس کے ساتھ تعاون کا طریقہ ہوگا۔ تاہم، یہ سب ابھی ابتدائی مراحل میں ہے اور میں شک کے ساتھ ہوں۔ آپ کو ٹوکن لاگت پر بہت احتیاط کرنی ہوگی، کیونکہ مختلف استعمال کے انداز کے لحاظ سے لاگت میں بہت بڑا فرق ہو سکتا ہے، خاص طور پر اس بات پر منحصر کرتے ہوئے کہ آپ "ٹوکن فراوان" ہیں یا "ٹوکن محدود"۔ آپ کو کسی ایسے طریقے کی ضرورت ہوگی جو معیار میں کمی نہ ہونے دے۔ "AI کا زبالہ پیدا کرنا" (slop) کے بارے میں فکر بھی منطقی ہے۔ تاہم، آئیے دیکھتے ہیں کہ اس کا اصل مطلب کیا ہے۔

@steipete نے حال ہی میں کہا تھا: "آپ کو اب کوڈنگ ایجینٹس کو پرامپٹس نہیں لکھنے چاہئیں۔ آپ کو کچھ لوپ ڈیزائن کرنے چاہئیں جو آپ کے ایجینٹس کو پرامپٹ کریں۔" اسی طرح، Anthropic کے Claude Code کے سربراہ @bcherny نے کہا: "میں اب Claude کو پرامپٹ نہیں کر رہا۔ میرے پاس کئی لوپ چل رہے ہیں جو Claude کو پرامپٹ کرتے ہیں اور خود فیصلہ کرتے ہیں کہ اگلا قدم کیا ہونا چاہئے۔ میرا کام صرف لوپ لکھنا ہے۔"

تو، اس کا کیا مطلب ہے؟

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

اب، آپ ایک چھوٹا سا سسٹم بنارہے ہیں: جو خود کام دریافت کرے گا، ٹاسکز تقسیم کرے گا، نتائج کی جانچ کرے گا، مکمل ہونے کا ریکارڈ رکھے گا، اور اگلے قدم کا فیصلہ کرے گا۔ یعنی، آپ اس سسٹم کو ایجنٹس کو چلانے کے لیے متحرک کررہے ہیں، نہ کہ خود اپنی طرف سے بار بار اسے ہدایات دے رہے ہیں۔ میں نے پہلے اس کا "قريب" — ایجنٹ ہارنس انجینئرنگ (Agent Harness Engineering) — لکھا تھا، جو ایک منفرد ایجنٹ کے لیے رن ٹائم ماحول تعمیر کرتا ہے؛ اور فیکٹری ماڈل (Factory Model)، جو سافٹ ویئر تعمیر کرنے والا سسٹم ہے۔ لوپ انجینئرنگ (Loop Engineering) ہارنس کے ایک لیول اوپر ہے۔ یہ ہارنس کی طرح ہے، لیکن ٹائم آؤٹ کے ساتھ چلتا ہے، چھوٹے مددگار بناتا ہے، اور خود کو غذاء فراہم کرتا ہے۔

مجھے حیرانی ہوئی کہ اب یہ صرف "ٹول لیول" کا مسئلہ نہیں رہا۔ ایک سال پہلے، اگر آپ کو ایک لوپ چاہیے تھا، تو آپ کو بہت سارے bash اسکرپٹ لکھنے پڑتے تھے، اور ان اسکرپٹس کی ہمیشہ دیکھ بھال کرتے رہنا پڑتا تھا۔ یہ آپ کا اپنا کام تھا اور صرف آپ کے لیے تھا۔ اب، یہ کمپوننٹس براہ راست مصنوعات میں ڈال دیے گئے ہیں۔ Steinberger نے جو صلاحیتیں درج کی ہیں، وہ تقریباً ہر ایک Codex ایپلیکیشن میں ملتی ہیں، اور تقریباً اسی طرح Claude Code میں بھی۔ جب آپ سمجھ جائیں کہ ان کی شکل ایک جیسی ہے، تو آپ اس بات پر الجھنے کے بجائے ایک لوپ ڈیزائن کرنے لگیں گے: چاہے آپ کون سے ٹول میں بیٹھ جائیں، وہ جاری رہے۔

پانچ اجزاء، اور کچھ تفصیلات

ایک لوپ کو پانچ چیزوں کی ضرورت ہوتی ہے، اور ایک معلومات کو یاد رکھنے کی جگہ کی بھی۔ میں پہلے انہیں فہرست کرتا ہوں، پھر ان کا ایک ایک کر کے مطابقت کرتا ہوں۔

سب سے پہلے، Automations (آٹومیشن ٹاسکس): منصوبہ بندی کے مطابق ٹریگر ہو کر خودکار طور پر دریافت اور ڈائیورٹ کریں۔

دوم، ورکٹریز (Worktrees): دو متوازی کام کرنے والے ایجنٹس کو ایک دوسرے کے فائلز پر گامزن نہ ہونے دیں۔

تیسری، مہارتیں: منصوبے کی معلومات لکھ دیں تاکہ ایجنٹ ہر بار اندازہ لگانے پر مجبور نہ ہو۔

چوتھا، پلگ انز اور کنیکٹرز: ایجنٹ کو آپ کے استعمال کی جا رہی ٹولز سے جوڑیں۔

پانچویں، سب-ایجینٹس: ایک منصوبہ پیش کرنے کے لیے، دوسرا منصوبے کی جانچ کے لیے۔

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

اب، دونوں مصنوعات میں یہ پانچ اجزاء موجود ہیں۔

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

آٹومیشنز وہ چیزیں ہیں جو loop کو ایک بار کے ہاتھ سے چلائے گئے کام سے الگ کرتی ہیں اور اسے اصل میں loop بنا دیتی ہیں۔ Codex ایپ میں، آپ Automations ٹیب پر ایک آٹومیشن بناسکتے ہیں، پروجیکٹ منتخب کریں، اس کے لیے استعمال ہونے والا پرامپٹ، رن کی فریکوئنسی، اور یہ کہ یہ آپ کے لوکل checkout میں چلے گا یا بیکگراؤنڈ worktree میں۔ جو رن رزلٹس مسائل کو ظاہر کرتے ہیں وہ Triage inbox میں جاتے ہیں، جبکہ مسائل والے رن خودبخود آرکائیو ہو جاتے ہیں، جو بہت اچھا ہے۔ OpenAI کے اندر بھی اس کا استعمال تھکا دینے والے لیکن ضروری کاموں کے لیے کیا جاتا ہے، جیسے روزانہ issue分流، CI فیل ہونے کے وجوہات کا خلاصہ، commit briefs تحریر کرنا، اور پچھلے ہفتے کسی نے داخل کیے گئے bug کا تعاقب۔ آٹومیشنز skill بھی بلاسکتی ہیں، اس لیے آپ دہرائے جانے والے کاموں کو قابلِ برقرار رکھ سکتے ہیں: ایک پلانڈ تاسک میں پورا اسکرین بھر کا نسخہ پیسٹ نہ کرکے صرف $skill-name ٹرگر کریں۔

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

ایک اور اہم سیشن اندر پریمیٹ جس کا تعلق اس مضمون کے اصل موضوع سے زیادہ قریب ہے۔ /loop تھوڑے اوقات کے بعد دہرایا جائے گا؛ /goal تب تک جاری رہے گا جب تک کہ آپ نے جو شرط لکھی ہے وہ حقیقت میں پوری نہ ہو جائے۔ ہر چکر کے بعد، ایک الگ چھوٹا ماڈل فیصلہ کرتا ہے کہ کام مکمل ہو گیا ہے یا نہیں، اس لیے کوڈ لکھنے والا ایجنٹ خود اپنے کام کا جائزہ نہیں لیتا۔ آپ اسے ایک شرط دے سکتے ہیں، جیسے "test/auth میں تمام ٹیسٹ کامیاب ہو گئے ہیں اور lint صاف ہے"، اور پھر چلے جائیں۔ Codex میں بھی یہی صلاحیت ہے، جسے بھی /goal کہا جاتا ہے۔ یہ متعدد چکروں میں کام کرتا رہتا ہے جب تک کہ کوئی قابل تصدیق روکنے کی شرط پوری نہ ہو جائے، اور اس میں روکنا، دوبارہ شروع کرنا اور صاف کرنا شامل ہے۔ ایک ہی پریمیٹ، دونوں ٹولز میں موجود ہے۔ یہ تقریباً اس مضمون میں دہرائے جانے والے نمونے کا خلاصہ ہے۔

تو، Automations کام کو سطح پر لانے کے لیے ذمہ دار ہیں۔ loop کا باقی حصہ ان کاموں کو سنبھالنے کے لیے ذمہ دار ہے۔

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

کوڈیک میں ابتدائی طور پر worktree کی سہولت ہے، جس کا مطلب ہے کہ متعدد تھریڈز ایک ہی ریپوزٹری کو одно وقت میں پروسیس کر سکتے ہیں بغیر کسی تصادم کے۔ کلاڈ کوڈ بھی git worktree کے ذریعے اسی طرح کی علیحدگی حاصل کر سکتا ہے: آپ --worktree فلگ کا استعمال کرکے الگ الگ چیک آؤٹ میں ایک سیشن کھول سکتے ہیں، یا subagent پر isolation: worktree سیٹ کر سکتے ہیں تاکہ ہر چھوٹا ایجنٹ ایک نیا چیک آؤٹ حاصل کرے اور مکمل ہونے کے بعد خودبخود صاف ہو جائے۔ میں نے the orchestration tax میں اس بات کا انسانی پہلو لکھا ہے: worktrees مکینیکل تصادم کو ختم کر دیتے ہیں، لیکن آپ اب بھی اپنی حد تک ہیں۔ آپ کتنے ایجنٹس کو одно وقت چلا سکتے ہیں، اس کا فیصلہ نہ تو ٹولز بلکہ آپ کا review bandwidth (جائزہ لینے کا بینڈ ودث) کرتا ہے۔

اسکل ایک مکینزم ہے جو آپ کو ہر سیشن میں ایک ہی سیٹ کے پروجیکٹ کے کنٹیکس کو دوبارہ وضاحت کرنے کی ضرورت سے بچاتا ہے۔ دونوں ٹولز ایک ہی فارمیٹ استعمال کرتے ہیں: ایک فولڈر جس میں ایک SKILL.md فائل ہوتی ہے جس میں تفصیلات اور میٹا ڈیٹا محفوظ ہوتے ہیں؛ اس کے علاوہ اختیاری اسکرپٹس، حوالہ جات اور وسائل کے فائلز بھی ہو سکتے ہیں۔ کوڈیک آپ کے $ یا /skills کے استعمال پر اسکل چلائے گا، اور اس کے علاوہ جب آپ کا کام اس اسکل کے تفصیل سے ملتا جلتا ہو تو وہ خود بخود چل جائے گا۔ اسی لیے ایک مختصر، سادہ تفصیل عام طور پر ایک ذکاوت مند اور شاندار تفصیل سے بہتر ہوتی ہے۔ کلاڈ کوڈ بھی اسی طرح کام کرتا ہے، جس کے بارے میں میں نے اپنے ایجنٹ اسکلز میں اس نمونے کو لکھا ہے۔

مهارات وہ جگہ بھی ہیں جہاں آپ کے ارادوں کو دوبارہ دوبارہ استعمال نہیں کیا جاتا۔ میں نے intent debt میں کہا تھا کہ ہر سیشن شروع ہونے پر ایجنٹ کول اسٹارٹ ہوتا ہے، اور جب تک آپ کے ارادوں میں خالی جگہ ہوگی، وہ اسے اپنے اعتماد کے اندازوں سے بھر دے گا۔ مہارتیں اس طرح کے ارادوں کو باہر لکھ دیتی ہیں: پروجیکٹ کے معاہدے، تعمیر کے مراحل، "ہم اس طرح نہیں کرتے کیونکہ پہلے اس حادثے کا واقعہ ہوا تھا" وغیرہ — سب کچھ ایک جگہ لکھ دیا جاتا ہے جسے ایجنٹ ہر بار چلائے جانے پر پڑھتا ہے۔ مہارتیں نہ ہونے پر، ہر لوپ کا ہر مرحلہ آپ کے پورے پروجیکٹ کو دوبارہ سے نکالنے کے لیے مجبور ہوتا ہے؛ مہارتیں ہونے پر، یہ تقریباً مرکب سود کی طرح کام کرتا ہے۔

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

ایک صرف فائل سسٹم کو دیکھنے والا لوپ، ایک چھوٹا لوپ ہے۔ کنیکٹرز MCP کے بنیاد پر تعمیر کیے گئے ہیں، جو ایجنٹس کو آپ کے ایشو ٹریکر کو پڑھنے، ڈیٹا بیس کو کوئری کرنے، اسٹیجنگ API کو بلانے، یا Slack میں پیغام بھیجنے کی اجازت دیتے ہیں۔ Codex اور Claude Code دونوں MCP کو سپورٹ کرتے ہیں، اس لیے آپ جو بھی ایک کے لیے کنیکٹر لکھتے ہیں، وہ عام طور پر دوسرے میں بھی استعمال ہو سکتا ہے۔ پلگ انز کنیکٹرز اور سکلز کو ایک ساتھ پیکج کرتے ہیں، تاکہ آپ کے ٹیم میمبرز مکمل کنفگریشن کو ایک بار میں انسٹال کر سکیں، نہ کہ پورا سسٹم یاد کر کے دوبارہ تعمیر کریں۔

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

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

کوڈیک صرف آپ کی درخواست پر سب ایجینٹس بنائے گا، جو متوازی طور پر چلیں گے اور پھر اپنے نتائج کو ایک جواب میں ملا دیں گے۔ آپ اپنے ایجینٹس کو .codex/agents/ میں TOML فائل کے ذریعے تعریف کر سکتے ہیں: ہر ایجینٹ کا ایک نام، تفصیل، ہدایات، اور ضرورت کے مطابق ماڈل اور استدلال کی شدت ہوتی ہے۔ اس طرح، آپ کا سیکیورٹی ریویور ایک高强度 استدلال والی طاقتور ماڈل ہو سکتا ہے، جبکہ آپ کا ایکسپلورر ایک تیز، صرف پڑھنے والی ہلکی ماڈل ہو سکتا ہے۔ کلاڈ کوڈ بھی .claude/agents/ میں سب ایجینٹس اور ایجینٹ ٹیمز کے ذریعے اسی قسم کی صلاحیت فراہم کرتا ہے، جس سے متعدد ایجینٹس ایک دوسرے کے درمیان کام منتقل کر سکتے ہیں۔ دونوں طرف سب سے عام تقسیم یہ ہے: ایک ایجینٹ تلاش کرتا ہے، ایک ایجینٹ عمل میں لاتا ہے، اور ایک ایجینٹ معیار کے مطابق تصدیق کرتا ہے۔

میں نے اس خیال کو دو بار پیش کیا ہے: ایک بار code agent orchestra میں، اور دوسری بار adversarial code review میں۔ یہ loop کے لیے خاص طور پر اہم ہے، کیونکہ loop اس وقت چلتا ہے جب آپ نہیں دیکھ رہے ہوتے، اس لیے ایک ایسا ویریفائر جس پر آپ مکمل طور پر بھروسہ کرتے ہیں، وہی واحد وجہ ہے جس کی وجہ سے آپ چلے جانے کا ساہنس کر سکتے ہیں۔ سب ایجنٹس بالفعل زیادہ ٹوکن استعمال کرتے ہیں، کیونکہ ہر ایجنٹ اپنے مدل اور ٹول کالز کرتا ہے، اس لیے آپ انہیں صرف اس جگہوں پر استعمال کریں جہاں "دوسرا رائے خریدنے کے قابل" ہو۔ یہ تقریباً Claude Code کے /goal کا بنیادی کام بھی ہے: جس میں کام کرنے والے مدل کے بجائے ایک نیا مدل فیصلہ کرتا ہے کہ loop مکمل ہو گیا ہے یا نہیں۔ یعنی، یہ "سازن" اور "چیکر" کو الگ کرنے کا تصور خود رکنے کے شرط پر لاگو کرتا ہے۔

ایک لُوپ کیسے دکھائی دیتا ہے

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

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

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

دیکھیں کہ آپ نے حقیقت میں کیا کیا۔ آپ نے صرف ایک ڈیزائن کیا ہے۔ وہ مراحل آپ نے خود ہر ایک کو ہدایت نہیں دی۔ یہی Steinberger کے اس جملے کا عملی ورژن ہے۔ اور وہی لُوپ Codex پر چل سکتا ہے، اور Claude Code پر بھی، کیونکہ ڈھانچے خود ایک ہی ڈھانچے ہیں۔

لوپ اب بھی آپ کے لیے کچھ نہیں کرے گا

لوپ نے اپنا طریقہ تبدیل کر لیا ہے، لیکن آپ کو کام سے نہیں نکالے گا۔ حقیقت میں، جیسے جیسے لوپ زیادہ طاقتور ہوتا جائے گا، تین مسائل زیادہ تیز ہوتے جائیں گے، نہ کہ آسان۔

تصدیق اب بھی آپ پر منحصر ہے۔ ایک بے نگہبان چلنے والا لوپ، بے نگہبان غلطیاں بھی کر سکتا ہے۔ آپ نے verifier sub-agent اور میکر کو الگ کیا ہے تاکہ لوپ کہنے کے لیے کہ "مکمل ہو گیا" کچھ معنی رکھے۔ اس کے باوجود، "مکمل ہو گیا" ایک دعویٰ ہے، ثبوت نہیں۔ میں AI کے دور میں کوڈ ریویو میں ایک ہی جملہ دہراتا رہا ہوں: آپ کا فرض آپ کی تصدیق کردہ کامیاب کوڈ فراہم کرنا ہے۔

اگر آپ اسے خود پر چھوڑ دیں، تو آپ کی اپنی سمجھ بھی خراب ہوتی رہے گی۔ جتنا جلدی لُوپ آپ کے ذریعہ نہ لکھے گئے کوڈ کو فراہم کرے، اتنی ہی زیادہ فرق ہوگا آپ کی واقعی سمجھ اور سسٹم میں موجود حقیقی چیزوں کے درمیان۔ یہی تفصیل کا قرض (comprehension debt) ہے۔ اگر آپ لُوپ کے پیداوار کو نہ پڑھیں، تو ایک چکنے لُوپ کے ذریعہ یہ قرض اور زیادہ تیزی سے بڑھے گا۔

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

لوپ بنائیں، لیکن اب بھی انجینئر بنیں

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

تو، آپ بالکل اپنا لوپ بناسکتے ہیں، لیکن یہ نہ بھولیں کہ اپنے اسمارٹ ایجینٹ کو براہ راست ہدایات دینا اب بھی موثر ہے۔ کلید بات مناسب توازن تلاش کرنا ہے۔

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

اسی لیے لُوپ ڈیزائن پرمشق کرنا پرامپٹ انجینئرنگ کے مقابلے میں مشکل ہے، آسان نہیں۔ چرنی کا مطلب یہ نہیں کہ کام آسان ہو گیا، بلکہ لیوریج پوائنٹ منتقل ہو گیا۔

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

[Original Link]

لیو دونگ BlockBeats کے خالی پوسٹس کے بارے میں جاننے کے لیے کلک کریں

لیکٹ کے ساتھ جڑیں: BlockBeats کا افسانوی گروہ

ٹیلیگرام سبسکرائب گروپ：https://t.me/theblockbeats

ٹیلیگرام گروپ：https://t.me/BlockBeats_App

ٹویٹر کا افسانوی اکاؤنٹ：https://twitter.com/BlockBeatsAsia