Agentic AI انجینئرنگ عملی طور پر: AI انجینئرز اور فارورڈ تعیناتی انجینئرز کلاڈ کوڈ، کوڈیکس اور جیمنی کے ساتھ کیسے تعمیر کرتے ہیں

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

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

METR نے سافٹ ویئر کے کاموں کی لمبائی کی پیمائش کی جو ایک AI ایجنٹ ماڈل ریلیز کے چھ سالوں میں اپنے طور پر مکمل کر سکتا ہے۔ ایک ہنر مند انسانی ماہر کے لیے اسی کام کو کرنے کے لیے درکار وقت کے طور پر اس کی تعریف کرتے ہوئے، ہم نے پایا کہ یہ تعداد 2019 (METR) کے بعد تقریباً ہر سات ماہ بعد دگنی ہو گئی ہے۔

یہ وکر خودکار تکمیل کے تھوڑا بہتر ہونے کے بارے میں نہیں ہے۔ یہ ایجنٹ کے "فیچر مکمل” سے "فیچر مکمل” تک اور اس کی موجودہ رفتار سے "اسپرنٹ مکمل” تک جانے کے بارے میں ہے۔

گود لینے والے نمبر پہلے ہی اس تبدیلی کی عکاسی کر رہے ہیں۔ گوگل کلاؤڈ اور ڈورا کی 2025 اسٹیٹ آف AI- فعال سافٹ ویئر ڈیولپمنٹ رپورٹ کے مطابق، 90% ڈویلپرز اب کام پر AI استعمال کر رہے ہیں، اور 80% سے زیادہ کا کہنا ہے کہ اس سے ان کی پیداواری صلاحیت میں بہتری آئی ہے۔ تاہم، تقریباً 10 میں سے 3 لوگ اب بھی اپنے ماڈلز (DORA) کے تیار کردہ کوڈ پر کم اعتماد کی اطلاع دیتے ہیں۔

اسٹیک اوور فلو کا 2025 ڈیولپر سروے عادت کے استعمال کے لیے ملتے جلتے نمبر فراہم کرتا ہے۔ 84% ڈویلپرز فی الحال AI ٹولز استعمال کر رہے ہیں یا استعمال کرنے کا ارادہ رکھتے ہیں۔ یہ پچھلے سال سے 76% زیادہ ہے، تقریباً نصف پیشہ ور ڈویلپرز روزانہ کی بنیاد پر AI ٹولز استعمال کرتے ہیں (اسٹیک اوور فلو)۔

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

یہ تضاد اس تحریر کا موضوع ہے۔ Anthropic’s Applied AI ٹیم نے AI Native SDLC کے نام سے ایک فریم ورک جاری کیا، جو 2026 میں ایک ہی مشاہدے پر بنایا گیا تھا۔ دوسرے لفظوں میں، جب ایجنٹس کوڈ لکھنے اور اس میں ترمیم کرنے سے زیادہ تیزی سے انسان پل کی درخواستوں کا جائزہ لے سکتے ہیں، تو سافٹ ویئر کی ترسیل میں رکاوٹیں اتنی زیادہ نہیں ہوتی ہیں جتنی منتقلی (Anthropic)۔

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

یہ گائیڈ ایک فریم ورک ہے جو تین طریقوں سے نافذ کیا گیا ہے: دوسرے لفظوں میں، یہ کنفیگریشن فائلوں اور کمانڈ آؤٹ پٹ پر مبنی ایک پریکٹیشنر کی پلے بک ہے۔

انڈیکس

شرطیں

شروع کرنے سے پہلے، یقینی بنائیں کہ آپ کے پاس درج ذیل ہیں:

  • CLI کوڈنگ کرنے والا ایک ایجنٹ انسٹال ہوا۔: کلاڈ کوڈ، اوپن اے آئی کوڈیکس یا جیمنی سی ایل آئی۔ آپ کو صرف ایک کی ضرورت ہے جاری رکھنے کے لیے۔ ذیل کے حصے ہر ایک کے لیے متعلقہ کمانڈ یا فائل فراہم کرتے ہیں۔

  • Node.js 18+ (چیک کریں node --version)، کیونکہ تینوں ٹولز کو npm پیکجز کے طور پر تقسیم کیا گیا ہے۔

  • Git 2.30 یا اس سے زیادہ (چیک کریں git --version

  • GitHub ریپوزٹری کے ساتھ کام فعال ہیں۔اس کی وجہ یہ ہے کہ تعیناتی اور دیکھ بھال کا سیکشن CI ورک فلو استعمال کرتا ہے۔

  • CI/CD تصورات کا بنیادی علم: پل کی درخواستوں، برانچ کی حفاظت، اور پائپ لائنوں کی تعمیر کی خصوصیات۔ GitHub ایکشنز میں کسی گہرائی سے مہارت کی ضرورت نہیں ہے۔

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

npm install -g @anthropic-ai/claude-code
npm install -g @openai/codex
npm install -g @google/gemini-cli

یہاں یہ ہے کہ ہر آئٹم کیا پیش کرتا ہے:

  • claude-code ڈال claude راستے میں ایک کمانڈ جو مقامی ریپوزٹری کے خلاف مراعات یافتہ موڈ، ذیلی ایجنٹ اور مہارتوں کا استعمال کرتے ہوئے ایجنٹ سیشن چلاتا ہے۔

  • codex ڈال codex آپ اپنے روٹس پر اپنے سینڈ باکسنگ اور منظوری کے ماڈل اور میزبان کلاؤڈ آپریشن موڈ کے ساتھ کمانڈ جاری کر سکتے ہیں۔

  • gemini-cli ڈال gemini ایک ایکسٹینشن پر بنے ہوئے راستے میں ایک کمانڈ جو پرامپٹ، MCP سرور، اور سلیش کمانڈز کو ایک انسٹالیبل یونٹ میں بنڈل کرتی ہے۔

آپ کو تینوں کی ضرورت نہیں ہے۔ اس مفت درجے کا انتخاب کریں جس کے لیے آپ کا آجر پہلے ہی ادائیگی کر رہا ہے یا وہ جو آپ کے پروجیکٹ کے لیے صحیح ہے اور اس گائیڈ کے باقی حصے کے لیے اس کالم کی پیروی کریں۔

AI مقامی SDLC کیا ہے؟

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

شکل 1: AI سے چلنے والا سافٹ ویئر ڈویلپمنٹ لائف سائیکل (SDLC) اسے سیدھی پائپ لائن کے بجائے ایک بند ہیکساگونل لوپ کے طور پر کھینچا گیا تھا۔ منصوبہ بندی، ڈیزائن، تعمیر، جانچ، تعیناتی اور دیکھ بھال کے چھ مراحل بیرونی طور پر گھڑی کی سمت میں انجام پاتے ہیں۔ فن پارے ہر مرحلے سے اگلے مرحلے تک (intent.md، spec.md، plan.md پلس کوڈ، ٹیسٹ کے نتائج، review.md، bands.yaml) حرکت پذیر تیر کے آگے لوپ کے اندر واقع ہے۔ دیکھ بھال سے لے کر منصوبہ بندی تک کا دوہرا تیر قابل توجہ پہلی تفصیل ہے۔ یہ چھ انفرادی مراحل کو ایک دوسرے کے ساتھ چھ بڑھانے کے بجائے ایک خود کو متحرک کرنے والے چکر میں بدل دیتا ہے۔

تیروں کی پیروی کرتے ہوئے:

  • منصوبہ بندی اگلے اقدامات ہاتھ میں لیتی ہے۔ intent.md.

  • ڈیزائن ہاتھ spec.md.

  • دستکاری کی جانچ اور تعیناتی۔ plan.md اور آخر کار فرق۔

  • ہاتھ کی تعیناتی کے جائزے کے نتائج کے ساتھ منسلک پل کی درخواستوں کو برقرار رکھیں۔

  • اگر پروڈکشن میں کچھ غلط ہو جائے تو اسے رکھیں اور نیا لکھیں۔ intent.md لوپ دوبارہ شروع کریں۔ یہ بند لوپ کسی بھی انفرادی قدم سے زیادہ اختراع ہے۔

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

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

جب Anthropic کی Applied AI ٹیم نے 2026 میں اپنا AI سے چلنے والے SDLC فریم ورک کو شائع کیا، تو انہوں نے واضح طور پر اس مفروضے کو نام دیا اور پورے ماڈل کو ترتیب دیا کہ جب یہ مفروضہ درست نہ ہو تو کیا ہوتا ہے (Anthropic)۔ فریم ورک وہی چھ قدموں کے ناموں کو برقرار رکھتا ہے جو سافٹ ویئر انجینئر پہلے سے جانتے ہیں۔ فرق یہ ہے کہ ہر مرحلے پر کام کیسے تیار اور استعمال ہوتا ہے۔

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

  • منصوبہ بندی کی پیداوار intent.mdدرخواست گزار کے اپنے الفاظ میں مسئلہ کی مختصر وضاحت۔

  • ڈیزائن پیدا کرتا ہے spec.mdکھلے مسائل کے ساتھ تقاضے اور رکاوٹیں ان لائن ظاہر ہوتی ہیں۔

  • تعمیر بنائیں plan.mdعمل درآمد کا منصوبہ ان فائلوں کے نام بتاتا ہے جن کو تبدیل کیا جانا ہے، جس ترتیب میں انہیں تبدیل کیا جائے گا، وہ ٹیسٹ جو ان کی تصدیق کریں گے، اور کسی بھی فرق کی نشاندہی کی جائے گی۔

  • جانچ اور تعینات کریں پل کی درخواستیں تیار کریں جو خودکار جائزے کے نتائج کی متعدد پرتیں فراہم کرتی ہیں۔

  • دیکھ بھال ان واقعات کا ریکارڈ بناتی ہے جو نئے ڈیٹا میں واپس آتے ہیں۔ intent.md جب پیداوار میں کوئی چیز متوقع حد کی خلاف ورزی کرتی ہے۔

انتھروپک کا بیان ڈیزائن کے ارادے کو اچھی طرح سے پکڑتا ہے۔

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

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

نمونے ایجنٹوں کو سست کیے بغیر معائنہ کی اجازت دیتے ہیں۔ کسی تصریح دستاویز کا جائزہ لینے میں 10 منٹ لگتے ہیں، اور جس طرح سے کوڈ کا موازنہ کیا جاتا ہے وہ اسے کیش، دوبارہ استعمال اور موازنہ کرنے کی اجازت دیتا ہے۔ زبانی طور پر اس کا اظہار کرنا ناممکن ہے۔

جہاں کوڈ سستا ہونے پر رکاوٹیں بدل جاتی ہیں۔

انتھروپک عنوانات فریم ورک کے متعلقہ حصے کو "کوڈ اب رکاوٹ نہیں ہے” اور وضاحت کرتا ہے کہ کیوں درج ذیل لائنوں میں:

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

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

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

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

مندرجہ بالا خاکہ AI پر مبنی SDLC کے آگے روایتی SDLC کا وقت مختص کرتا ہے۔ روایتی ماڈل میں، بلڈ بار چارٹ پر حاوی ہے۔ سپرنٹ کیلنڈر کا زیادہ تر وقت کوڈ لکھنے اور ڈیبگ کرنے میں صرف ہوتا ہے، جبکہ نسبتاً کم وقت منصوبہ بندی، جانچ اور تعیناتی پر صرف ہوتا ہے۔ AI مقامی ورژن میں، تعمیرات کو چھوٹے حصوں تک کم کر دیا جاتا ہے، ایجنٹ کِک آف میٹنگ کے شیڈول میں لگنے والے وقت میں کام کے نفاذ کو تخلیق کر سکتے ہیں، اور منصوبہ بندی، جانچ/جائزہ، اور تعیناتی کی سلاخیں اس جگہ کو پُر کرنے کے لیے بڑھ جاتی ہیں جو عمارتیں لیتی ہیں۔ چارٹ کی مجموعی چوڑائی بہت کم تبدیل ہوتی ہے۔ شرح کو محدود کرنے کے عمل کو انجام دینے کے لیے فی الحال جو اقدامات اٹھائے گئے ہیں وہ کیا تبدیلیاں ہیں۔

انتھروپک کے اپنے فریموں کو انہی تین مراحل کا نام دیا گیا ہے۔

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

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

  • تیز رفتار تعمیر، مبہم منصوبہ بندی۔ اب جب کہ "کچھ غلط ہے” اور "کچھ ڈیلیور کیا گیا ہے” کے درمیان نوٹس لینے کے لیے کم وقت ہے، یہ ایک ایجنٹ کے لیے اعتماد کے ساتھ کسی غلط چیز کو تیز رفتاری سے نافذ کرنا اس کے مقابلے میں ایک انسان کے لیے وہی غلطی آہستہ کرنے کے مقابلے میں بدتر ہے۔

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

  • تیزی سے تعمیر، دستی تعیناتی. چونکہ انسانوں کو ابھی بھی تین ماحولوں میں دستی طور پر تعمیر کرنا ہے، ایجنٹ اس سے زیادہ تیزی سے کام پیدا کرتے ہیں جتنا کہ تنظیم جذب کر سکتی ہے۔

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

کلاڈ کوڈ، کوڈیکس، اور جیمنی CLI: ایک فریم ورک، تین الفاظ

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

جب آپ مرحلہ وار حصوں کو پڑھتے ہیں تو نیچے دی گئی جدول جائزہ لینے کے لیے ایک حوالہ ہے۔

صلاحیت کلاڈ کوڈ AI کوڈیکس کھولیں۔ جیمنی سی ایل آئی
میموری / سیاق و سباق کی فائل CLAUDE.mdمنصوبے کی جڑ میں ~/.claude/یا .claude/ (انسانیت) AGENTS.mdکوڈیکس ہوم ڈائرکٹری میں، میں نے پروجیکٹ روٹ (اوپن اے آئی) پر تشریف لے گئے۔ GEMINI.mdعالمی، پروجیکٹ، اور سب ڈائرکٹری کی سطحوں پر منسلک (گوگل)
دوبارہ قابل استعمال پرامپٹ / ایکسٹینشن سسٹم ذیلی ایجنٹس (اپنی سیاق و سباق کی کھڑکی، محدود ٹولز) اور مہارتیں، فولڈر پر مبنی اور خودکار درخواست (انتھروپک، اینتھروپک) یہ ٹیکنالوجی حسب ضرورت پرامپٹس کی جگہ لے لیتی ہے، جو اب فرسودہ ہو چکے ہیں۔ MCP سرور بیرونی ٹول تک رسائی کو الگ سے ہینڈل کرتا ہے (اوپن اے آئی)۔ ایکسٹینشن بنڈلز پرامپٹس، ایم سی پی سرورز، سلیش کمانڈز، ہکس، اور سب ایجنٹس کو ایک انسٹالیبل یونٹ میں (گوگل)
منظوری/سینڈ باکس ماڈل اجازت کے طریقے: دستی، خودکار، پلاننگ موڈ (Shift+Tab پر سوئچ کریں (انتھروپک)) دو آزاد محور: سینڈ باکس موڈ (صرف پڑھنے کے لیے، ورک اسپیس لکھنے، رسک سے مکمل رسائی) اور اجازت کی پالیسی (غیر بھروسہ، آن ڈیمانڈ، کبھی نہیں) (اوپن اے آئی) منظوری کے طریقے: پہلے سے طے شدہ، خودکار ترمیم، یولو(--yolo یا Ctrl+Y) اور اب بھی پختہ منصوبہ بندی موڈ (گوگل)
ہمارا CI کام anthropics/claude-code-actionکی طرف سے متحرک @claude تذکرہ یا منصوبہ بند واقعہ (انسانیت) openai/codex-actionپھانسی codex exec آپ اپنے CI ٹاسک (OpenAI) کے اندر پیچ لگا سکتے ہیں یا جائزے شائع کر سکتے ہیں۔ google-github-actions/run-gemini-cliPR اور ایشو ایونٹس (گوگل) کے ذریعے متحرک
مقامی PR کوڈ کا جائزہ کوڈ کا جائزہ: مقامی کے ساتھ ملٹی ایجنٹ سروس کا انتظام/code-review کمانڈ اور سیوریٹی ٹیگز کے ساتھ ان لائن تبصرے (انتھروپک) /review CLI میں @codex review GitHub یا کسی بھی نئے PR (OpenAI) پر P0/P1 مسائل کو جھنڈا لگانے کے لیے "آٹو ریویو” سیٹ اپ کریں۔ GitHub کے لیے جیمنی کوڈ اسسٹ، چیک ان کے ذریعے کنفیگر کیا جا سکتا ہے۔.gemini/config.yaml پانچ جائزے کے طول و عرض پر فائلیں (گوگل)
ہمیشہ چیٹ اسکرین کریں۔ Slack’s Claude Tag (Anthropic)، ایک مشترکہ تنظیمی ID جو ویب پر کلاڈ کوڈ تک کوڈنگ کے ارادے کو روٹ کرتی ہے۔ آفیشل کوڈیکس سلیک ایپ:@Codex ایک چینل میں کلاؤڈ ٹاسک بنائیں اور نتائج واپس پوسٹ کریں (سلیک)۔ اس تحریر تک، کوئی تصدیق شدہ فرسٹ پارٹی سلیک مقامی IDs نہیں ہیں۔ صرف تھرڈ پارٹی پل موجود ہیں۔

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

ایک بار جب تعمیر اب کوئی رکاوٹ نہیں رہے گی، تمام دکانداروں کو ارد گرد کا وہی بنیادی ڈھانچہ بنانے کی ضرورت ہوگی۔ بصورت دیگر، ٹول تیز لیکن انتظام کرنا مشکل ہوگا۔

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

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

انٹرآپریبلٹی کے بارے میں ایک اور چیز کا ذکر کرنا ضروری ہے کیونکہ یہ اس خیال کو کمزور کرتا ہے کہ آپ کو ایک ٹول چننا ہے اور اسے ہمیشہ کے لیے استعمال کرنا ہے۔ کلاڈ کوڈ کا اپنا میموری مضمون موجودہ میموری کو بازیافت کرنے پر تبادلہ خیال کرتا ہے۔ AGENTS.md فائل @AGENTS.md چونکہ یہ ایک حوالہ یا علامتی لنک ہے، اس لیے کلاڈ کوڈ سیشن وہی رولز فائل (انتھروپک) پڑھ سکتا ہے جو کوڈیکس سیشن پہلے سے استعمال کرتا ہے۔

AGENTS.md خود ایک کراس وینڈر اوپن اسٹینڈرڈ بن گیا ہے، جسے Codex سے بہت آگے اپنایا گیا ہے، اور ایک کمپنی (OpenAI) سے باہر برقرار رکھا گیا ہے۔ وہ ٹیمیں جو AGENTS.md میں قوانین کی فائلوں کو معیاری بناتی ہیں اور کلاڈ کوڈ درآمد کرتی ہیں، وہ ایک مشترکہ میموری فائل کا پورا فائدہ اٹھاتی ہیں، قطع نظر اس کے کہ ہر فرد انجینئر اس دن کس ٹول کو ترجیح دیتا ہے۔

منصوبہ بندی کے مراحل کو کیسے انجام دیا جائے۔

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

انتھروپک کا فریم ورک اس قدم سے تیار کردہ نمونے کہتا ہے۔ intent.mdیہ جان بوجھ کر غیر کشش ہے۔ یہ قبولیت کے معیار کے ساتھ جیرا ٹکٹ نہیں ہے جس کے حل سے پہلے ہی ریورس انجنیئر کیا گیا ہے۔ یہ ایک ٹرانسکرپٹ کی طرح ہے جو آپ کے اپنے الفاظ میں، انجینئر یا ایجنٹ کے تشریح شروع کرنے سے پہلے درخواست کنندہ کا کہنا ہے کہ آپ کو کیا ضرورت ہے۔

یہاں کم از کم ہے: intent.md آپ ٹیمپلیٹ کو کسی ذخیرہ میں بھیج سکتے ہیں اور اسے تمام نئے کاموں کے لیے دوبارہ استعمال کر سکتے ہیں۔

# intent.md

## Requested by
Name, role, date

## What they said
Paste the raw request. Do not clean it up yet. If it came from a support
ticket, a Slack thread, or an incident, link it.

## What problem this solves
One or two sentences, written after the raw request above, translating it
into a problem statement. This is the first place interpretation is allowed.

## Why now
What triggered this request. If it came out of an incident, name the
incident record it traces back to.

## Constraints already known
Anything the requester specified: deadline, budget, systems that cannot
change, regulatory requirement.

## Explicitly out of scope
What this request does not include, stated as what it does.

موجودہ صورتحال کچھ یوں ہے:

  • "انہوں نے کیا کہا” سیکشن جان بوجھ کر غیر ترمیم شدہ ہے تاکہ ہم اگلے مراحل میں غلط پڑھی جانے والی درخواستوں کو پروپیگنڈہ کرنے سے پہلے پکڑ سکیں۔

  • "اُنہوں نے کیا کہا” کو "اس مسئلے کو حل کرنے” سے الگ کرنا یقینی بناتا ہے کہ تشریح کا مرحلہ ایک بار تحریری طور پر ہوتا ہے، بجائے اس کے کہ درخواست کو پڑھنے والے اگلے فرد کو اندرونی طور پر۔

  • "اب کیوں” فیلڈ وہ ہے جو بحالی کے مرحلے پر لوپ کو بند کرتا ہے۔ پیداواری واقعے سے شروع ہونے والے ارادوں کو واضح طور پر بیان کیا جانا چاہیے اور اس واقعے کے ریکارڈ سے منسلک ہونا چاہیے جس نے اسے متحرک کیا۔

جب آپ درخواست لکھتے ہیں، تو اسی ٹیمپلیٹ کو مختصر رکھا جاتا ہے:

# intent.md

## Requested by
Maria, independent contractor and beta user, 2026-08-14

## What they said
"I have to check four different calendars every morning before I can tell
a client when I'm free. I've double-booked myself twice this month."

## What problem this solves
Contractors working across multiple clients cannot see a unified view of
their own availability without giving each client's calendar system
access to the others.

## Why now
Direct customer feedback during the private beta, not a production
incident.

## Constraints already known
Beta ships in six weeks. No budget for a dedicated calendar-sync vendor.

## Explicitly out of scope
Two-way sync or write access to any client's calendar. Read-only overlay only, for this release.

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

ہر ٹول ایجنٹوں کو براہ راست کوڈ میں کودنے کے بغیر اس مرحلے سے گزرنے کے لیے مختلف طریقہ کار فراہم کرتا ہے۔ Claude Code’s Planning Mode اس منظر نامے کے لیے بنایا گیا ایک وقف شدہ صرف پڑھنے کی اجازت کا موڈ ہے۔ ایجنٹ آپ کے کوڈبیس کی جانچ کر سکتا ہے اور نقطہ نظر تجویز کر سکتا ہے، لیکن یہ فائلوں میں ترمیم یا کمانڈز کو نہیں چلا سکتا جب تک کہ آپ Shift+Tab (Anthropic) کے ذریعے ایسا نہ کریں۔

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

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

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

ڈیزائن کے مرحلے کو کیسے چلائیں۔

جہاں ڈیزائن ہے intent.md بن جاتا ہے۔ spec.mdایک دستاویز جو حل کی تکنیکی شکل، حل سے وابستہ انٹرفیسز، اور تجارتی معاہدوں کی وضاحت کرتی ہے جسے ایجنٹوں کے نفاذ کوڈ لکھنا شروع کرنے سے پہلے کسی کو منظور کرنا ہوگا۔

اینتھروپک کا فریم ورک اس مرحلے کی وضاحت کرتا ہے "جہاں تقاضے اور ڈیزائن ایک سیشن میں سمٹ جاتے ہیں” (انتھروپک)۔ یہ روایتی عمل سے ایک اہم تبدیلی ہے جہاں پروڈکٹ کی وضاحتیں اور تکنیکی ڈیزائن کی دستاویزات ہر چند دن بعد مختلف لوگوں کے ذریعے لکھی جاتی ہیں اور ان کے درمیان میٹنگز کے ذریعے رابطہ کیا جاتا ہے۔

سروس spec.md ٹیمپلیٹ واضح طور پر منہدم رہتا ہے، حادثاتی طور پر نہیں۔

# spec.md

## Source
Link to the intent.md this spec answers.

## Approach
Plain description of the technical approach: which systems change, which
stay the same, and why this approach over the obvious alternative.

## Interfaces affected
API endpoints, database schemas, public function signatures. Anything
another team or another service depends on.

## Open concerns
Anything the agent or the author is not confident about. This section
exists specifically so uncertainty gets written down instead of quietly
resolved by whichever choice was easiest to implement.

## Explicitly rejected alternatives
What else was considered and why it lost. This is what keeps the next
person from re-litigating a decision six months from now.

## Sign-off
Who reviewed this and on what date.

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

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

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

تعمیراتی قدم کیسے چلائیں۔

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

اب کیا تبدیلیاں آتی ہیں کہ آپ کی تعمیرات منظور شدہ ماحول میں چلتی ہیں؟ plan.mdایڈہاک پرامپٹ کے بجائے ایک فوری ایجنٹ دلچسپ ہے، لیکن یہ آپ کو غلط ہدف کی بجائے صحیح ہدف کی طرف اشارہ کرتا رہتا ہے۔

کوئی راستہ نہیں plan.md مخصوص فائلوں کے نام جن کو تبدیل کیا جانا ہے، تبدیلیوں کی ترتیب، اور ٹیسٹ کا نام بتاتا ہے جو ہر تبدیلی کی جانچ کرتا ہے۔

# plan.md

## Source
Link to spec.md this plan implements.

## Files to change, in order
1. `src/models/user.py`: add the `last_login_at` field
2. `src/api/auth.py`: update login handler to set the new field
3. `tests/test_auth.py`: add coverage for the new field
4. `migrations/0042_add_last_login.py`: schema migration

## Tests that must pass before this plan is considered done
- Existing auth test suite, unmodified tests still green
- New test: login sets last_login_at to the current UTC timestamp
- New test: last_login_at is null for a user who has never logged in

## Rollback
How to revert if this ships broken: a single migration down-step and a
git revert of the three code changes, no data backfill required.

میموری فائل جسے ہر ٹول چھونے سے پہلے پڑھتا ہے اس بات کا تعین کرتا ہے کہ ایجنٹ کوڈ کیسے لکھتا ہے، نہ کہ خود منصوبہ۔ کوئی راستہ نہیں CLAUDE.md ذخیرہ کی جڑ ہے:

# CLAUDE.md

## Commands
- Run tests: `pytest tests/ -x -q`
- Run linter: `ruff check src/`
- Start local server: `python manage.py runserver`

## Codebase layout
Django monolith. Business logic lives in `src/services/`, not in views or
models. Views call services; services call models. Do not put business
logic directly in a view.

## Standards
- All new API endpoints require a corresponding entry in `openapi.yaml`
- Database migrations are one change per file, never bundled
- No new dependencies without an entry in `docs/decisions/`

## Test coverage
Every new function in `src/services/` needs a corresponding test in
`tests/services/`. Coverage below 85% fails CI.

اگر پروجیکٹ پہلے ہی معیاری ہے۔ AGENTS.md چونکہ یہ ایک کراس وینڈر فارمیٹ ہے، اس لیے اوپر کی فائل تقریباً ایک ڈائریکٹ پورٹ ہے۔ ان کا ایک ہی ڈھانچہ، ایک ہی مواد، مختلف فائلوں کے نام ہیں، اور جب آپ کوڈیکس ہوم ڈائرکٹری سے پروجیکٹ روٹ (اوپن اے آئی) پر جاتے ہیں تو کوڈیکس خود بخود انہیں پڑھتا ہے۔

کوئی راستہ نہیں GEMINI.md ورژن دوبارہ وہی مواد ہے اور Gemini CLI اسے عالمی ورژن کے ساتھ جوڑتا ہے۔ ~/.gemini/GEMINI.md اور سب ڈائرکٹری کی سطح کی فائلیں، تاکہ monorepo سروس سے متعلق مخصوص اوور رائیڈز (گوگل) کو کمپنی کے وسیع قوانین کی فائلوں کو پرت کرنے کے لیے استعمال کر سکے۔

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

ایک میموری فائل سے آگے دوبارہ قابل استعمال سلوک وہ جگہ ہے جہاں تین ٹولز زیادہ نمایاں طور پر مختلف ہوتے ہیں۔ کلاڈ کوڈ اسے دو میکانزم میں تقسیم کرتا ہے۔ سکلز، ایک فولڈر پر مبنی پیکج جس میں سب ایجنٹس ہیں جو اپنے سیاق و سباق کی ونڈو میں محدود ٹول رسائی کے ساتھ تنگ کاموں کے لیے چلتے ہیں جیسے کہ "SQL انجیکشن کے لیے اس فرق کا جائزہ لیں” اور جب Claude شامل ہوتا ہے تو خود بخود ان کو استعمال کیا جاتا ہے، جو حسب ضرورت سلیش کمانڈز ہوا کرتا تھا (Anthropic، Anthropic)۔

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

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

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

تینوں ٹولز ماڈل سیاق و سباق پروٹوکول کے ذریعے بیرونی سسٹمز، ڈیٹا بیس، ٹکٹ ٹریکرز اور ڈیزائن ٹولز سے جڑتے ہیں، جسے Anthropic نے Claude Code (Anthropic) کے مقامی فرسٹ کلاس حصے کے طور پر تخلیق کیا اور اوپن سورس کیا، جو کہ اس کے بعد سے ایک حقیقی کراس وینڈر معیار بن گیا ہے۔ کوڈیکس اپنے MCP کلائنٹ کے ذریعے اس کی حمایت کرتا ہے، اور Gemini CLI ریموٹ سرورز کے لیے OAuth 2.0 کے ذریعے اس کی حمایت کرتا ہے۔

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

ٹیسٹ مرحلہ کیسے چلائیں۔

انتھروپک اس مرحلے کو "عمل درآمد کے ذریعے بنے ہوئے مسلسل تشخیص” (انتھروپک) کے طور پر تیار کرتا ہے۔ یہ روایتی ماڈل کا جان بوجھ کر تضاد ہے، جہاں جانچ ایک ایسا مرحلہ ہے جو تعمیر مکمل ہونے کے بعد شروع ہوتا ہے۔

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

یہ وہ مرحلہ بھی ہے جہاں DORA رپورٹ کے کم مثبت نتائج متعلقہ ہو جاتے ہیں۔ 90% کے گود لینے کے اعداد و شمار کے ساتھ، 10 میں سے 3 ڈویلپر اب بھی کہتے ہیں کہ انہیں AI سے تیار کردہ کوڈ (DORA) پر کم اعتماد ہے۔ اس طرح کی عدم اعتمادی اس وقت معقول ہے جب ٹیسٹنگ فوری تعمیر کے مرحلے کے بعد ایک الگ مرحلہ ہے۔ جب کسی کو آپ کے کوڈ پر بھروسہ کرنے کی ضرورت ہوتی ہے، تو اس کی وجہ یہ ہے کہ اس نے ابھی تک اس کی تصدیق نہیں کی ہے۔ تاہم، اگر کسی انسان کے شیڈول کے لیے انتظار کرنے کی بجائے ہر کمٹ کے لیے تصدیق چلائی جائے، تو یہ خطرے کی بجائے انجینئرنگ کا ایک قابل حل مسئلہ بن جاتا ہے۔

کلاڈ کوڈ اسے ہکس کا استعمال کرتے ہوئے لاگو کرتا ہے، جو شیل کمانڈز ہیں جو خود بخود بعض لائف سائیکل ایونٹس پر عمل میں آتے ہیں، جیسے ایجنٹ فائل میں ترمیم کرنے سے پہلے یا بعد میں یا کمانڈ چلاتا ہے (انتھروپک)۔ یہاں ایک ہک ہے جو ہر بار کسی فائل میں ترمیم کرنے پر ٹیسٹ سویٹ چلاتا ہے اور اگر ایجنٹ ناکام ہوجاتا ہے تو پیشرفت کو روکتا ہے۔ .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "pytest tests/ -x -q --timeout=60"
          }
        ]
      }
    ]
  }
}

موجودہ صورتحال کچھ یوں ہے:

  • PostToolUse ہک پہلے کے بجائے ایجنٹ کے ایڈٹ یا رائٹ ٹول کال کو مکمل کرنے کے بعد چلتا ہے، اس لیے یہ ڈسک میں تبدیلیوں کی جانچ کرتا ہے۔

  • pytest -x ایجنٹ کو پارس کرنے والی مکمل ناکامی کی رپورٹ کو پھینکنے کے بجائے، یہ فیڈ بیک لوپ کو مختصر رکھتے ہوئے پہلی ناکامی پر رک جاتا ہے۔

  • اس کمانڈ میں بلاکنگ ایگزٹ کوڈ ایجنٹ کو اگلی شیڈول فائل میں جانے سے روکتا ہے۔ plan.md جب تک ٹیسٹ سویٹ دوبارہ سبز نہ ہو۔

کوڈیکس اور جیمنی سی ایل آئی یونیورسل لوکل ہکس فریم ورک کو کلیڈ کوڈ کی طرح پختگی کی حد تک دستاویز نہیں کرتے ہیں (اور آپ کے اپنے لیپ ٹاپ پر ایجنٹ کے وسط سیشن کو روکنے پر انحصار کرتے ہیں)۔ پائپ لائن میں دیگر پوائنٹس کی نسبت کم لاپتہ خصوصیات ہیں۔ کوڈیکس اور جیمنی CLI کیونکہ دونوں ٹولز مقامی لائف سائیکل ایونٹ سسٹم کے بجائے بنیادی طور پر CI کے ارد گرد ایک مسلسل تصدیقی کہانی بناتے ہیں۔ /review PR ٹرگرڈ ریویو پروڈکٹ (ذیل میں تعیناتی کے تحت بیان کیا گیا ہے) اسی قسم کے مسائل کو پکڑتا ہے جب کوئی فرق پل کی درخواست سے ٹکرا جاتا ہے۔

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

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

تعیناتی کا مرحلہ کیسے چلایا جائے۔

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

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

تینوں وینڈرز اب اپنی اپنی GitHub ایکشنز پیش کرتے ہیں، لہذا آپ کو شروع سے اپنا CI انضمام بنانے کی ضرورت نہیں ہے۔ کلاڈ کورڈ کا anthropics/claude-code-action کا جواب @claude PR یا شمارے میں ذکر کیا گیا ہے، GitHub ایونٹ میں چلائیں یا آپ کے ترتیب کردہ شیڈول پر چلائیں (Anthropic):

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Review this diff against spec.md and plan.md for this PR."

کوڈیکس کے مساوی، openai/codex-actionپھانسی codex exec اس کا مطلب یہ ہے کہ ایجنٹوں کے پاس صرف ایک سادہ جائزے کے موڈ کے بجائے مکمل CLI فعالیت ہوتی ہے اور وہ پیچ لاگو کر سکتے ہیں یا جائزے کے تبصرے شائع کر سکتے ہیں اس پر منحصر ہے کہ اقدامات کیسے کنفیگر کیے گئے ہیں (اوپن اے آئی)۔

name: Codex Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  codex-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: openai/codex-action@v1
        with:
          openai_api_key: ${{ secrets.OPENAI_API_KEY }}
          command: "review this diff against the linked spec.md and flag P0/P1 issues"

جیمنی google-github-actions/run-gemini-cli یہ ایک ہی PR اور ایشو ایونٹس پر چلتا ہے اور مطابقت پذیر بلاکنگ کنفرمیشن (گوگل) کی بجائے متضاد طور پر اور مجموعی پروجیکٹ سیاق و سباق میں چلتا ہے۔

name: Gemini Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  gemini-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: google-github-actions/run-gemini-cli@v1
        with:
          gemini_api_key: ${{ secrets.GEMINI_API_KEY }}
          prompt: "Review this pull request for correctness, efficiency, and maintainability."

خام CI کام کے علاوہ، ہر وینڈر اپنی اپنی کنفیگریشن اسکرینوں کے ساتھ وقف شدہ کوڈ ریویو پروڈکٹس بھی پیش کرتا ہے۔ Claude Code’s Code Review ایک منظم سروس ہے جو متعدد خصوصی ایجنٹوں کو متوازی طور پر چلتی ہے۔ اس میں ان لائن PR تبصرے والے لوگوں تک پہنچنے سے پہلے غلط مثبت کو فلٹر کرنے کے لیے ایک علیحدہ تصدیقی مرحلہ شامل ہے۔ @claude review یا مقامی /code-review حکم (انسانیت)۔

کوڈیکس کی جائزہ سطح ہے /review CLI مصنف کے احکامات @codex review یہ ایک "خودکار جائزہ” ترتیب ہے جو تمام نئے PRs پر چلتی ہے، GitHub PR میں ذکر کے ساتھ یا اس کے بغیر۔ GitHub موڈ میں، ہم جان بوجھ کر صرف انتہائی شدید P0 اور P1 مسائل کو جھنڈا لگانے تک محدود ہیں نہ کہ تمام اسٹائل نِٹس (OpenAI)۔

دیگر دو کے برعکس، GitHub کے لیے Gemini Code Assist بنیادی طور پر چیک ان فائلوں کے ذریعے ترتیب دیا جاتا ہے۔ .gemini/config.yamlمیموری فائل سے ایک الگ سطح جو تعمیر کا انتظام کرتی ہے۔ ہم جائزہ لینے کے پانچ جہتوں میں خلاصہ اور ان لائن تبصرے شائع کرتے ہیں: درستگی، کارکردگی، برقراری، حفاظت اور دیگر جامع جانچ، اسکیل ایبلٹی، اور غلطی لاگنگ (گوگل)۔

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

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

یہ ایک مفید ذہنی ماڈل ہے۔ اگر ایجنٹ کوڈ لکھنا بند کر دیتا ہے، تو کوئی فرق نہیں کیا جاتا ہے۔ جائزہ مکمل ہو جاتا ہے جب ہم ایک فوری، باخبر منظوری کا فیصلہ کرنے کے لیے ضروری ثبوت جمع کر لیتے ہیں۔

دیکھ بھال کے اقدامات کیسے چلائیں۔

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

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

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

# monitoring/bands.yaml

- metric: p99_latency_ms
  service: checkout-api
  band: [0, 400]
  on_breach:
    severity: high
    action: open_incident
    write_intent: true

- metric: error_rate_pct
  service: checkout-api
  band: [0, 1.0]
  on_breach:
    severity: critical
    action: page_oncall
    write_intent: true

- metric: daily_active_users
  service: onboarding-flow
  band: [800, null]
  on_breach:
    severity: medium
    action: open_incident
    write_intent: false

موجودہ صورتحال کچھ یوں ہے:

  • ہر میٹرک میں ایک حد کے بجائے قابل قبول رینجز کے بینڈ ہوتے ہیں، جس سے ان قدروں کو پکڑنا اتنا ہی آسان ہو جاتا ہے جو بہت کم پڑ جاتی ہیں جتنی کہ بہت اونچی ہوتی ہیں۔

  • write_intent: true ایک ایسا طریقہ کار جو خود بخود خلاف ورزی کو نئے پلاننگ فیز سائیکل کے آغاز میں تبدیل کرتا ہے، ایک مسودہ بناتا ہے۔ intent.md خلاف ورزی شدہ میٹرک، سروس اور واقعے کے لنک کو نام دیں۔

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

جہاں ایجنٹوں کو صفحات یا تذکرے موصول ہوتے ہیں وہ اہم ہے جہاں تین ٹولز برابر نہیں ہیں۔ Claude Tag تنظیموں کے لیے اشتراک کی صلاحیتیں فراہم کرتا ہے۔ @Claude سلیک کے لیے ایک شناخت جو چینلز اور روٹس پر متضاد طور پر کام کرتی ہے جس میں ویب پر کلاڈ کوڈ کو کوڈنگ کے کاموں کا ذکر کیا گیا ہے۔ اس سے "کوئی شخص ناکام میٹرک کے ساتھ ایک واقعہ چینل میں بوٹ کو ٹیگ کرتا ہے” کو برقرار رکھنے کا ایک قابل عمل طریقہ (انسانیت پسند) بناتا ہے۔

اوپن اے آئی براہ راست مساوی پیش کرتا ہے: آفیشل کوڈیکس سلیک ایپ @Codex کسی چینل یا تھریڈ میں کلاؤڈ ٹاسک بنائیں، متعلقہ ریپوزٹری پر کام کریں، اور نتائج کو واپس اسی تھریڈ پر پوسٹ کریں جس کا ذکر (Slack) میں کیا گیا ہے۔

جیسا کہ اوپر بیان کیا گیا ہے، ابھی تک گوگل کا کوئی فرسٹ پارٹی مساوی نہیں ہے۔ فی الحال، صرف فریق ثالث اور کمیونٹی کے بنائے ہوئے پل Gemini CLI کو Slack سے جوڑتے ہیں۔ جیمنی پر مبنی دیکھ بھال کے اقدامات کے لیے ایک عملی حل یہ ہوگا کہ چیٹ کے تذکروں کا انتظار کرنے کے بجائے آپ کے موجودہ ان کال پیجنگ ٹول میں ویب ہُک کے ذریعے آٹومیشن کو روٹ کیا جائے (یہ ایک اچھا خیال ہے کہ کوئی واقعہ پیش آنے سے پہلے اسے ترتیب دیا جائے اور کسی بوٹ تک پہنچ جائے جو وہاں نہیں ہے)۔

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

آرٹفیکٹ پر مبنی فیڈ بیک لوپ کا فلو ڈایاگرام: intent.md spec.md فراہم کرتا ہے، جو plan.md فراہم کرتا ہے، جو ایجنٹ کی تعمیر فراہم کرتا ہے، جو پھر خودکار جانچ اور گیٹ کا جائزہ، تعیناتی، اور نگرانی کرتا ہے۔ نیلے نقطے والا تیر اگلے سائیکل کو متحرک کرنے کے لیے مانیٹرنگ سے نئے بنائے گئے intent.md پر واپس آ جاتا ہے۔

شکل 3: ایک طرفہ پائپ لائن اس کی بجائے بند لوپ کے طور پر کھینچی گئی ہے۔ بائیں سے دائیں پڑھیں، intent.md کھانا کھلانا spec.md، spec.md کھانا کھلانا plan.md، plan.md ایجنٹ کی تعمیرات فراہم کرتا ہے جو خودکار جانچ اور جائزہ گیٹس، تعیناتی اور نگرانی کا باعث بنتا ہے۔ نیلے نقطے والا واپسی تیر جو کہتا ہے کہ "اگلا سائیکل ٹرگر” زیادہ تر ٹیم کے عمل میں غائب ہے۔ نگرانی کی خلاف ورزیوں کو براہ راست نئے بنائے گئے سائیکل پر واپس بھیج دیا جاتا ہے۔ intent.mdروایتی پائپ لائن ڈایاگرام کی طرح تعیناتی پر ختم ہونے کے بجائے، یہ لوپ کو بند کر دیتا ہے۔

اوپر دیا گیا خاکہ اس سیکشن میں موجود ہر چیز کا نتیجہ ہے۔ bands.yaml کے ذریعے open_incidentایک ایونٹ ریکارڈ کے طور پر، ایک نیا بنایا گیا intent.mdآئیے منصوبہ بندی کے اس مرحلے پر واپس آتے ہیں جہاں سے یہ گائیڈ شروع ہوا تھا۔ دیکھ بھال سے لے کر منصوبہ بندی تک کا تیر وہ ایک لائن ہے جو آج کل ٹیم کے انجینئرنگ کے زیادہ تر عمل سے غائب ہے۔ یہ ان ٹیموں کے لیے بھی درست ہے جنہوں نے اپنے تعمیراتی مرحلے کے لیے ایجنٹ کوڈنگ ٹولز کو اپنایا ہے۔

ان فیڈ بیک ایرو کو بنائے بغیر بلڈز کے لیے تیز ایجنٹوں کو خریدنے سے آپ کو تیز رفتار کوڈ ملے گا (اور وہی سست دستی سوچ روڈ میپ عمل جو ہر ٹیم کے پاس پہلے سے موجود ہے)۔ تیر کا مطلب یہ ہے کہ چھ مراحل کو ایک چکر میں چھ انفرادی بہتریوں کی بجائے ایک دوسرے کے ساتھ رکھا جائے۔

ایک انجینئر 5 لوگوں کی ٹیم کو کیسے منظم کرتا ہے۔

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

GitHub کی Octoverse 2025 کی رپورٹ میں پتا چلا ہے کہ گزشتہ سال GitHub میں شامل ہونے والے تقریباً 80% ڈویلپرز نے پہلے ہفتے میں Copilot کا استعمال کیا۔ اس سے پتہ چلتا ہے کہ AI کی مدد سے ترقی تیزی سے نئے انجینئرنگ کیریئر کے لیے پہلے سے طے شدہ انٹری پوائنٹ بنتی جا رہی ہے، بجائے اس کے کہ برسوں کے تجربے (GitHub) پر بنائی گئی زیادہ جدید ٹیکنالوجیز۔

تقریباً نصف پیشہ ور ڈویلپرز پہلے سے ہی روزانہ کی بنیاد پر AI ٹولز استعمال کرتے ہیں (اسٹیک اوور فلو)، اسٹیک اوور فلو کے نتائج کے ساتھ مل کر کہ انجینئرز سنجیدگی سے اس اسٹیک کو استعمال کرنے والے ایک یا دو افراد کے اسٹارٹ اپ پر غور کر رہے ہیں کوئی غیر معمولی بات نہیں ہے۔ یہ نئے ڈویلپرز کی اوسط قدر کے قریب ہے۔

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

منصوبہ بندی کے اقدامات:

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

یہ 15 منٹ کا سیشن کسٹمر کے انٹرویوز اور تقاضوں کی دستاویزات میں دو افراد کی ٹیم کے ذریعے کیے گئے ایک ہفتے کے کام کی جگہ لے لیتا ہے۔

ڈیزائن کے مراحل:

ڈیزائن آرکیٹیکٹس کے وائٹ بورڈ سیشن کو بدل دیتا ہے۔ وہی سیشن، جو اب بھی صرف پڑھنے کے موڈ میں ہے، پیدا کرتا ہے: spec.md: ہم نے واضح طور پر کیلنڈر اوورلے سروس، ہر کلائنٹ کے کیلنڈر فراہم کنندہ کے لیے OAuth، ایک واحد نظریہ، اور بیٹا کے لیے پولنگ کے 5 منٹ کے وقفے کے حق میں ریئل ٹائم مطابقت پذیری کو مسترد کر دیا۔ کیونکہ ریئل ٹائم سنکرونائزیشن کے 6 ہفتے کی ڈیڈ لائن کو توڑنے کا زیادہ امکان تھا۔ قیاس میں "واضح طور پر مسترد: ٹائم لائن کی وجہ سے حقیقی وقت کی مطابقت پذیری” لکھنا بانیوں کو ہفتہ 5 میں دباؤ کے تحت اس فیصلے پر نظر ثانی کرنے سے روکتا ہے۔

تعمیراتی مراحل:

تحریر ایک پوری انجینئرنگ ٹیم کی جگہ لے لیتا ہے۔ کے ساتھ plan.md کیلنڈر انٹیگریشن، توثیق کے بہاؤ، اور یونیفائیڈ ویو اجزاء کو اس ترتیب میں نام دے کر، ایجنٹ کوڈنگ ٹول CLAUDE.md (یا AGENTS.mdیا GEMINI.md) بانی کی طرف سے ایک بار کیے گئے اسٹیک فیصلوں (کیلنڈر لائبریریوں، تصدیقی نمونوں، کاروباری منطق کے مقامات) کو انکوڈ کرتا ہے۔ اس گائیڈ کے ہر قارئین نے پہلے ہی اس حصے کے تیز ہونے کی توقع کی تھی۔ آیا بیٹا وقت پر ریلیز ہوتا ہے اس کا انحصار آس پاس کے حصوں پر ہوگا۔

ٹیسٹ کے مراحل:

ٹیسٹ QA انجینئر کی جگہ لے لیتا ہے۔ چونکہ ہک ہر فائل میں ترمیم کے بعد ٹیسٹ سوٹ چلاتا ہے، اس لیے بانی ڈیمو سے ایک ہفتے پہلے تک بغیر جانچ شدہ ایجنٹ آؤٹ پٹ کو ڈیبگ نہیں کرتے ہیں۔ تحریری امتحان کے معیار کا نظم و ضبط plan.md یہ وہ چیز ہے جس پر ایک سرشار QA انجینئر حقیقت کے بعد جانچ کرنے کے بجائے تعمیر شروع کرنے سے پہلے اصرار کرتا ہے۔

تعیناتی کے مراحل:

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

بحالی کے اقدامات:

برقرار رکھنا SRE آن کال روٹیشن کو بدل دیتا ہے۔ کوئی راستہ نہیں bands.yaml وائرڈ API کی خرابی کی شرحوں اور پولنگ آپریشن کی کامیابی کی شرحوں کا مشاہدہ کرنا جو مشترکہ کالنگ ٹول کے بجائے بانیوں کے فونز کو براہ راست کال کرتے ہیں جس کے ارد گرد کوئی بھی گردش نہیں کرتا ہے اس سائز کی کمپنی کے لئے پورے واقعے کے ردعمل کا کام ہے۔ اگر پولنگ آپریشن کی غلطی کی شرح صبح 2 بجے اس حد سے تجاوز کر جاتی ہے، تو نتیجے میں ہونے والا واقعہ کا ریکارڈ اگلے ہفتے کا پہلا ریکارڈ ہوگا۔ intent.md کیڑے کے بجائے، بانیوں کو پیر تک صرف نصف یاد ہے۔

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

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

Agentic AI سے چلنے والے SDLC پر جانے سے پہلے پری فلائٹ چیک لسٹ

اس فریم ورک کے ارد گرد اپنی ٹیم کے ورک فلو کو دوبارہ منظم کرنے سے پہلے، کام کرنے کے لیے درج ذیل کو ان مراحل میں گروپ کریں:

منصوبہ بندی اور ڈیزائن

  • [ ] نہیں intent.md ٹیمپلیٹ ریپوزٹری میں موجود ہے اور تمام نئی ملازمتیں آبادی والی کاپی سے شروع ہوتی ہیں۔

  • [ ] کوئی راستہ نہیں spec.md ٹیمپلیٹس موجود ہیں جن میں ایک واضح "اوپن ایشوز” سیکشن ہوتا ہے جسے انسان تعمیر شروع ہونے سے پہلے پڑھتے ہیں۔

  • [ ] درخواست کنندہ کے علاوہ ایک یا ایک سے زیادہ لوگ ایجنٹ کے ارادے کے خلاصے کی تصدیق کرتے ہیں اس سے پہلے کہ یہ تفصیلات بن جائے۔

تحریر

  • [ ] میموری فائل (CLAUDE.md، AGENTS.mdیا GEMINI.md) موجود ہے، ورژن کنٹرول میں چیک کیا جاتا ہے، اور پلیس ہولڈر ٹیکسٹ کے بجائے کمانڈ، فن تعمیر، اور کنونشن کا نام دیتا ہے۔

  • [ ] plan.md نفاذ شروع ہونے سے پہلے مخصوص فائلوں کے نام، تبدیلیوں کی ترتیب، اور ٹیسٹوں کی وضاحت کرتا ہے۔

ٹیسٹ

  • [ ] ایک ہک، پری کمٹ چیک، یا مساوی لوکل گیٹ خود بخود ٹیسٹ سوٹ پر عمل درآمد کرتا ہے اور ناکامی پر پیشرفت کو روکتا ہے۔

  • [ ] ٹیسٹ کے نتائج کو چیٹ میں پاس ہونے یا فیل ہونے کی اطلاع نہیں دی جاتی ہے، بلکہ اس مخصوص کمٹ سے منسلک ہوتی ہے جس کی وہ جانچ کر رہے ہیں۔

تقسیم

  • [ ] ہمارے CI آپریشنز (کلاڈ کوڈ، کوڈیکس، یا جیمنی) ہر پل کی درخواست کا خودکار جائزہ چلاتے ہیں۔

  • [ ] اس سے قطع نظر کہ ایک خودکار جائزے سے کیا پتہ چلتا ہے، تصدیق، ادائیگیوں، منتقلی، یا بنیادی ڈھانچے سے متعلق تبدیلیوں کے لیے واضح طور پر انسانی منظوری کے دروازے کی ضرورت ہوتی ہے۔

  • [ ] جب خودکار انضمام کو فعال کیا جاتا ہے، تمام سبز چیک ڈیفالٹ کے بجائے ایک متعین کم خطرے والے زمرے میں دائر کیے جاتے ہیں۔

برقرار رکھنا

  • [ ] مانیٹرنگ کنفیگریشنز میٹرکس کے لیے قابل قبول بینڈز کی وضاحت کرتی ہیں جو پلیٹ فارم کے ذریعے سامنے آنے والے تمام میٹرکس کے بجائے آپ کے کاروبار کے لیے اہم ہیں۔

  • [ ] خلاف ورزی کا زمرہ کم از کم سب سے زیادہ شدت کے ساتھ خود بخود ایک نیا خلاف ورزی کا زمرہ بنانے کے لیے منسلک ہو جاتا ہے۔ intent.mdمنصوبہ بندی کے لیے واپس لوپ کو بند کریں۔

  • [ ] کوئی، یہاں تک کہ کوئی دوسرا مرحلہ چلا رہا ہے، اس مرحلے میں پیش آنے والے واقعات کو پڑھنے اور اس کے مطابق عمل کرنے کا ذمہ دار ہے۔

نتیجہ

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

  • intent.md چاہے تشریح کلاڈ کوڈ کے پلاننگ موڈ، کوڈیکس کے صرف پڑھنے کے لیے سینڈ باکس، یا جیمنی سی ایل آئی کے پلان کی منظوری کے موڈ میں ہو، اس سے پہلے کہ کوئی بھی ان کی ترجمانی کرے اس میں مسائل پیدا ہو جاتے ہیں۔

  • spec.md اور plan.md یہ ایک ایجنٹ کی رفتار کو ذمہ داری کے بجائے اثاثے میں بدل دیتا ہے تاکہ وہ اہداف فراہم کر سکیں جنہیں انسان ان اہداف کے اوپر بنا سکتا ہے جن کا وہ پہلے ہی جائزہ لے چکے ہیں۔

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

  • ٹائرڈ جائزہ انسانی فیصلہ اب بھی اس بات پر مبنی ہے کہ یہ کہاں سب سے زیادہ قیمت کا اضافہ کرتا ہے: دھماکے کے رداس کے دروازے فرق کی ہر لائن کے بجائے تبدیل ہوتے ہیں۔

  • بینڈ اسٹائل مانیٹرنگ کنفیگریشن پیداواری سوچ کو براہ راست اگلے چکر میں منتقل کرنے کے لیے لوپ کو بند کریں۔ intent.md فالو اپ انویسٹی گیشن کے بجائے کوئی بھی اسے دوبارہ نہیں کھولے گا۔

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

آگے کیا دریافت کرنا ہے۔

30 سے ​​زیادہ اوپن سورس سافٹ ویئر سلوشنز اور ڈویلپر ٹولز کو دریافت کرنے کے لیے میرا GitHub ملاحظہ کریں جو میں نے اپنے ایجنٹ AI پر مبنی انجینئرنگ کے عمل کو استعمال کرتے ہوئے بنائے اور شیئر کیے ہیں۔

Scroll to Top