اے آئی پی آر ریویو کی رکاوٹ کو کیسے توڑا جائے: کوڈ بیس سے آگاہ جائزہ لینے والوں کی تعمیر کے لیے ایک ٹیک اونر گائیڈ

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

مسئلہ تب ہی ظاہر ہوا جب میں نے چیک کیا کہ ایجنٹ کون سا توثیق مڈل ویئر درآمد کر رہا ہے۔

ہمارے کوڈ بیس میں MongoDB کی حمایت یافتہ v1 مڈل ویئر اور MySQL کی حمایت یافتہ v2 مڈل ویئر تھا، جسے ہم نے پچھلی سہ ماہی منتقلی میں گزارا تھا۔

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

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

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

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

کلاس کو یہ بتانا چاہیے کہ آیا ٹیم Claude Code، Cursor، Cline، GitHub Copilot، یا کوئی مرکب استعمال کرتی ہے۔ ساخت اوزار سے زیادہ اہم ہے۔

انڈیکس

ایک پرانی رکاوٹ اور AI کے ذریعہ تخلیق کردہ

یہ سمجھنے کے لیے کہ یہ فکس کیوں ضروری ہے، یہ یاد رکھنے میں مدد کرتا ہے کہ کچھ سال پہلے کوڈ کے جائزے کس طرح کے تھے۔

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

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

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

لیکن رکاوٹ دور نہیں ہوئی۔ یہ منتقل ہوگیا۔

AI کو بڑے پیمانے پر اپنانے کے بعد سے ہفتوں میں، ہماری نظرثانی کی قطار دوگنی ہو گئی ہے۔ پھر تین گنا ہو گیا۔ انجینئرز PRs کو میرے پڑھنے سے زیادہ تیزی سے کھول رہے تھے۔

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

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

CircleCI 2026 اسٹیٹ آف سافٹ ویئر ڈیلیوری رپورٹ اس بات کی تصدیق کرتی ہے کہ میں اکیلا نہیں ہوں۔ 22,000 سے زیادہ تنظیموں میں 28 ملین سے زیادہ CI ورک فلو کے ساتھ، رپورٹ فیچر برانچ تھرو پٹ میں سال بہ سال 59% اضافہ ظاہر کرتی ہے۔ یہ سرکل سی آئی کا اب تک کا سب سے بڑا اضافہ ہے۔ اس اہم مقام پر جہاں کوڈ کو اصل میں پیداوار میں فروغ دیا جاتا ہے اسی مدت کے دوران میڈین ٹیم کے لیے 7% کی کمی واقع ہوئی۔ تعمیراتی کامیابی کی شرح 70.8 فیصد تک گر گئی، جو پانچ سالوں میں سب سے کم ہے۔

یہ پیٹرن پوری صنعتوں میں یکساں تھا۔ AI نے تحریر کو تیز کر دیا ہے۔ باقی نظام نے لاگت کو جذب کیا۔

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

جائزہ لینے کی نئی نوکری عمل میں کیسی نظر آتی ہے۔

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

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

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

جب تک کہ جائزہ لینے والے کو یاد نہ ہو کہ ہک موجود ہے، اس قسم کی نقل کوڈ کے جائزوں میں ظاہر نہیں ہوتی ہے۔

ایک اور مثال جو میں مستقل طور پر دیکھ رہا ہوں: ایک ایجنٹ اسٹیٹس فیلڈ کا لفظی تار سے موازنہ کرتا ہے۔ "completed" اس کے بجائے Status.Completed باقی سروس کے ذریعہ استعمال کردہ شمار۔ کوڈ بھاگ گیا۔ ٹیسٹ چلایا گیا ہے۔ اینوم کی اگلی ری فیکٹرنگ نے خاموشی سے فائل کو چھوڑ دیا۔ کچھ دن بعد، کسی نے آدھا دن ایک اسٹیٹ مشین کو ڈیبگ کرنے میں گزارا جو ٹھیک کام کر رہی تھی جب تک کہ ایجنٹ کے لٹریلز خود بخود مطابقت پذیر ہونا بند نہ ہو جائیں۔

ایک بار دریافت ہونے کے بعد، درستگی 2 منٹ کے اندر مکمل ہو گئی، لیکن فی PR دریافت کرنے میں مناسب وقت لگا۔ رگڑ مشکل نہیں تھا۔ یہ تکرار تھی۔

پیٹرن نے خود کو بڑے مسائل میں دہرایا۔

میں نے ایک بار ایک ایجنٹ سے ایونٹ تخلیق وزرڈ بنانے کو کہا۔ وزرڈ کو کئی ڈراپ ڈاؤنز اور ایک نئے جز کی ضرورت تھی۔

مشترکہ UI اجزاء کے ساتھ ایک ڈیزائن سسٹم فولڈر ہے، اور ٹیم کے اصول آسان ہیں۔ پہلے وہاں چیک کریں، اور اگر آپ کچھ نیا بنا رہے ہیں تو وہاں رجسٹر کریں۔

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

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

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

عام دھاگہ یہ ہے کہ یہ تمام غلطیاں کہیں کہیں کوڈ میں، سلیک تھریڈ میں، یا لیڈ انجینئر کے سر میں لکھی جاتی ہیں جو ان کو روک سکتی تھیں۔ معلومات موجود تھیں۔ ایجنٹ اسے نہیں دیکھ سکتا تھا۔

واضح اگلا اقدام 2026 میں مارکیٹ میں سیلاب آنے والے AI PR جائزہ لینے والوں میں سے ایک کو انسٹال کرنا تھا۔

ہم نے کئی چیزوں کا جائزہ لیا۔ Anthropic نے مارچ 2026 میں Claude Code Review شروع کیا، ٹوکن کے استعمال کی بنیاد پر چارج کرنا، فی جائزہ ₩(15-₩)25 کی اوسط سے۔ CodeRabbit Pro سالانہ بل آنے پر فی ڈیولپر $24 فی ماہ یا ماہانہ بل آنے پر فی ڈیولپر $30 چارج کرتا ہے، اور سیٹوں کا حساب اس ڈویلپر کے لیے کیا جاتا ہے جو حقیقت میں PR کھولتا ہے۔ مارچ 2026 میں، گریپٹائل نے 50 جائزوں کے ساتھ فی سیٹ $30 فی سیٹ کے بنیادی پلس استعمال کے ماڈل میں تبدیل کیا، اس کے بعد ہر اضافی جائزے کی لاگت $1 تھی۔ GitHub نے اعلان کیا کہ تمام Copilot منصوبے 1 جون 2026 کو استعمال پر مبنی بلنگ میں منتقل ہو جائیں گے، اور کوڈ کے جائزے اس تاریخ کے بعد AI کریڈٹ اور GitHub ایکشن دونوں کو استعمال کریں گے۔

کم PR والیوم والی چھوٹی ٹیموں کے لیے، ان میں سے کوئی بھی ڈیل بریکر نہیں ہو سکتا۔ بڑی ٹیموں کے لیے جو بڑے پیمانے پر AI سے چلنے والی ترقی کو چلاتے ہیں، لاگتیں تیزی سے بڑھ جاتی ہیں۔ 10 افراد کی ایک ٹیم جو روزانہ 5 PRs چلاتی ہے صرف ایک ہفتے میں Greptile میں شامل جائزوں کو مکمل کرتی ہے۔ CodeRabbit Pro $24 فی سیٹ$ پر ڈویلپرز کے ساتھ لکیری پیمانے پر۔ $15-$25 فی PR پر، پریمیم کلاڈ کوڈ ریویو فی جائزہ سب سے مہنگا آپشن ہے۔

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

ایک آرام دہ جائزہ لینے والے نے v1/v2 مڈل ویئر کا پتہ نہیں لگایا ہوگا۔ یہ جاننے کا کوئی طریقہ نہیں تھا کہ آیا v2 سرکاری راستہ تھا۔ ایک آرام دہ جائزہ لینے والے نے ڈپلیکیٹ ڈراپ ڈاؤن کو نہیں پکڑا ہوگا۔ ہمارے پاس یہ جاننے کا کوئی طریقہ نہیں تھا کہ آیا ہمارا ڈیزائن سسٹم موجود ہے۔ ایک آرام دہ جائزہ لینے والے نے نظرانداز فن تعمیر کو نہیں دیکھا ہوگا۔ کنٹرولر کے لیے یہ جاننے کا کوئی طریقہ نہیں تھا کہ اسے ریپوزٹری کو کال نہیں کرنا چاہیے۔

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

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

اس سے ایک اور سوال پیدا ہوتا ہے۔ اگر اصول پروڈکٹ ہے، تو فی سیٹ یا کسی اور کے ریپر کے لیے فی جائزہ کیوں ادا کریں؟

اس لیے میں نے رخ بدل دیا۔

احساس: قواعد کو کوڈ بیس میں منتقل کریں۔

ایک بار جب ہم نے اصولوں کو مصنوعات کے طور پر سوچنا شروع کیا تو آگے کا راستہ صاف ہو گیا۔

میں نے اپنے آپ سے ایک سادہ سا سوال پوچھا: میں اصل میں کوڈ ریویو میں کیا کر رہا تھا جو AI نہیں تھا؟ جواب بار بار ایک ہی نظر آتا ہے۔ میں ایک جائزہ تبصرہ ٹائپ کر رہا تھا جس نے ٹیم کے بارے میں میری کچھ یادوں کو اپنی لپیٹ میں لے لیا۔

"ریاست کی گنتی کا استعمال کریں، نہ کہ سٹرنگ لٹریلز۔” "ہمارے پاس پہلے سے ہی اس کے لئے ایک ہک ہے۔ /hooks/useDeleteItem” "کنٹرولرز کو ریپو پرت سے درآمد نہیں کیا جانا چاہئے۔ اسے ایپ لیئر کے ذریعے روٹ کریں۔” "نیا جزو بنانے سے پہلے اپنے ڈیزائن سسٹم فولڈر کو چیک کریں۔”

ہر تبصرہ وہ علم تھا جو میرے دماغ میں رہتا تھا اور ایک وقت میں ایک PR تبصرہ کوڈبیس میں آتا تھا۔ اگلی بار جب ایجنٹ اسی طرح کی PR بناتا ہے تو اسے کوئی معلومات دستیاب نہیں ہوتی ہیں۔

لہذا ہوشیار جائزہ لینے والوں کو خریدنا حل نہیں تھا۔ اس کا حل یہ تھا کہ قواعد کو ایسی جگہ لکھ دیا جائے جہاں ٹیم کے تمام ایجنٹ ان کا جائزہ لینے سے پہلے انہیں پڑھ سکیں۔

اگر آپ نے تین مختلف PRs میں تین بار "لفظی کے بجائے شماریات کا استعمال کریں” ٹائپ کیا، تو یہ ایک اصول تھا جو آپ کے ایجنٹوں کو اب سے جاننے کی ضرورت ہے۔ چوتھا، اگر اس نے ڈیزائن سسٹم فولڈر کی طرف اشارہ کیا تو یہ اصول تھا۔ اگر آپ نے PR تبصرے میں 4-پرت کے فن تعمیر کو دو بار بیان کیا تو یہ اصول تھا۔

ہمیں ان قوانین کو لاگو کرنے کے لیے ایک جگہ کی ضرورت تھی۔ یہ میری توقع سے کم واضح فیصلہ نکلا۔

دو فائلیں جنہوں نے سب کچھ بدل دیا: AGENTS.md اور CLAUDE.md

جب آپ کسی AI ایجنٹ کو پراجیکٹ کا مستقل سیاق و سباق فراہم کرنے کے طریقے کی تحقیقات شروع کرتے ہیں، تو آپ کو تقریباً فوری طور پر دو مسابقتی اصولوں کا سامنا کرنا پڑتا ہے۔

پہلا ہے۔ AGENTS.mdیہ ایک کھلا معیار ہے جس نے حقیقی رفتار حاصل کی ہے۔ InfoQ کے مطابق، 2025 کے وسط تک، فارمیٹ کو 20,000 سے زیادہ GitHub ریپوزٹریز نے پہلے ہی اپنا لیا تھا اور اسے روایتی دستاویزات، یعنی مشین کے پڑھنے کے قابل سیاق و سباق جو کہ README.md جیسی انسانی دیکھی جانے والی فائلوں کے ساتھ موجود ہے۔

اسٹینڈرڈ کی اپنی سائٹ رپورٹ کرتی ہے کہ اس وقت اسٹینڈرڈ کو 60,000 سے زیادہ اوپن سورس پروجیکٹس میں استعمال کیا جاتا ہے اور یہ لینکس فاؤنڈیشن کے اندر واقع Agentic AI فاؤنڈیشن کی انتظامی ذمہ داری میں منتقل ہو گیا ہے۔ اس فارمیٹ کو OpenAI Codex، GitHub Copilot، Google Gemini، Cursor، اور Windsurf، دوسروں کے درمیان تعاون یافتہ ہے۔

دوسرا ہے۔ Claude.mdیہ کلاڈ کوڈ کے لیے انتھروپک کے اصول ہیں۔ کلاڈ کوڈ آرٹیکل دو تکمیلی میموری سسٹمز کی وضاحت کرتا ہے: CLAUDE.md، جو مستقل سیاق و سباق کو براہ راست لکھتا ہے، اور ایک خودکار میموری میکانزم جو کلاڈ کو اپنے نوٹوں کو تبدیل شدہ اور مشاہدہ شدہ نمونوں پر ذخیرہ کرنے کی اجازت دیتا ہے۔ پہلے سے طے شدہ طور پر، کلاڈ کوڈ CLAUDE.md پڑھتا ہے، AGENTS.md نہیں۔

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

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

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

اس فائل کو استعمال کرنے کے پہلے مہینے سے، دو حقیقی اصول سامنے آئے:

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

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

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

جہاں سروس کے لیے مخصوص میموری فائلیں رکھی جاتی ہیں۔

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

کام کرنے والے پیٹرن: ہر سروس یا ایپ کے اپنے منفرد پیٹرن ہوتے ہیں۔ AGENTS.md جڑ اور پروجیکٹ کی سطح پر AGENTS.md یہ ان کی طرف اشارہ کرنے والا اشارہ بن جاتا ہے۔

خدمت سے AGENTS.md یہ مندرجہ ذیل کا احاطہ کرتا ہے:

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

ایک ہی دبلی پتلی قوانین لاگو ہوتے ہیں۔ اسے مختصر رکھیں، مثالیں بتائیں، اور ضروری ہدایات کا اظہار کریں۔

میکانکی طور پر اس کے کام کرنے کی وجہ یہ ہے کہ ایجنٹ موجودہ کام کے لیے مناسب فائل لوڈ کرتا ہے۔ جب کوئی انجینئر کسی ایجنٹ سے کچھ تبدیل کرنے کو کہتا ہے۔ backend/ایجنٹ پروجیکٹ کی سطح پر پڑھتا ہے۔ AGENTS.mdمیں نے تصدیق کی کہ یہ کام کرتا ہے۔ backend/ کی قیادت میں ہونا ضروری ہے backend/AGENTS.mdاور فائل لوڈ کریں۔ فرنٹ اینڈ کو لوڈ نہیں کرتا ہے۔ AGENTS.mdکیونکہ وہ کام کہیں اور ہے۔ سیاق و سباق کی ونڈو متعلقہ مواد کو فوکس میں رکھتی ہے۔

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

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

یہ ڈسک پر کیسا لگتا ہے۔

مزید جانے سے پہلے، مجموعی ساخت کو دیکھنا مفید ہے۔ ہمارا monorepo کیسا دکھتا ہے: بالکل فولڈر کے نام Claude Code کے اصولوں پر عمل کرتے ہیں۔ کرسر کا استعمال کرتے ہوئے: .cursor/اور اگر آپ Cline استعمال کرتے ہیں، .clinerules – لیکن شکل براہ راست بتائی جاتی ہے۔

project-root/
├── AGENTS.md                       # symlink to CLAUDE.md
├── CLAUDE.md                       # root memory file
├── README.md                       # human-facing project readme
│
├── .claude/                        # tool-specific config folder
│   ├── README.md                   # explains the .claude/ layout
│   ├── settings.json               # permissions and guardrails
│   ├── agents/                     # specialised subagents (optional)
│   ├── commands/                   # slash commands engineers run
│   │   ├── review-pr.md            # the PR review command
│   │   └── plan-feature.md         # implementation plan command
│   ├── hooks/                      # lifecycle hooks (optional)
│   ├── pr-rules/                   # rule files for PR review
│   │   ├── common.md               # rules that apply to every PR
│   │   ├── frontend.md             # rules for frontend changes
│   │   ├── backend.md              # rules for backend changes
│   │   ├── service-a.md            # rules for service-a
│   │   └── service-b.md            # rules for service-b
│   └── skills/                     # reusable workflows
│
├── frontend/
│   ├── AGENTS.md                   # frontend conventions
│   ├── docs/
│   │   ├── overview.md
│   │   ├── architecture.md         # routing, state, data layer
│   │   ├── design-system.md        # design system reference
│   │   └── testing.md              # test conventions
│   └── src/
│
├── backend/
│   ├── AGENTS.md                   # the four-layer pattern
│   ├── docs/
│   │   ├── overview.md
│   │   ├── architecture.md         # route -> controller -> app -> repo
│   │   ├── auth.md                 # v1 vs v2 middleware
│   │   ├── business-rules.md
│   │   └── integrations.md
│   └── src/
│
├── service-a/
│   ├── AGENTS.md
│   ├── docs/
│   │   ├── overview.md
│   │   ├── business-rules.md
│   │   └── integrations.md
│   └── src/
│
└── service-b/
    ├── AGENTS.md
    ├── docs/
    │   ├── overview.md
    │   ├── business-rules.md
    │   └── integrations.md
    └── src/

چند باتیں قابل توجہ ہیں:

کہ .claude/ فولڈر معیاری ذیلی فولڈر کے نام استعمال کرتے ہیں۔ commands، agents، hooks، skills. یہ کلاڈ کوڈ کے پلگ ان ماڈل کی پیروی کرتا ہے، لیکن زیادہ تر جدید AI کوڈنگ ٹولز میں ایک جیسے سلاٹ ہوتے ہیں۔ قواعد کی پیروی اس بات کو یقینی بناتی ہے کہ آپ کی ٹیم کا ہر فرد ساخت کو پہچانتا ہے اور بعد میں ٹولز کو تبدیل کرنے کی لاگت کو کم کرتا ہے۔

کہ pr-rules/ فولڈرز معیاری کنونشن نہیں ہیں۔ زون کے لیے مخصوص نظرثانی کے اصولوں کو رکھنے کے لیے بنایا گیا فولڈر جسے PR جائزہ کمانڈ منتخب طور پر لوڈ کرتی ہے۔ فون کرنے کی ضرورت نہیں ہے۔ pr-rules – نظرثانی کے قواعد کے موجود ہونے کے لیے جگہ رکھنے سے نام کم اہم ہے۔

ہر سروس کی اپنی ہے۔ AGENTS.md اور بھی ہے۔ docs/ فولڈر جڑ AGENTS.md یہ مختصر ہے اور ایک اشاریہ کے طور پر کام کرتا ہے۔ ایجنٹ سے کہو، "اگر آپ کسی فائل کو چھوتے ہیں، backend/یہ بھی پڑھیں backend/AGENTS.md پہلے۔ خدمت سے متعلق فائلیں پھر ضرورت کے مطابق گہری دستاویزات کی طرف اشارہ کرتی ہیں۔

ایک ضمنی اثر کے طور پر تیار کردہ دستاویزات

سروس کے لیے مخصوص ترتیبات AGENTS.md فائل نے ایک مسئلہ کا انکشاف کیا جس سے میں خاموشی سے گریز کر رہا تھا۔ ہماری زیادہ تر سروسز کے پاس مناسب دستاویزات نہیں تھیں۔ یہ API حوالہ جات کا مواد نہیں ہے جو کوڈ میں موجود ہے، لیکن اعلی درجے کی "یہ سروس کیا کرتی ہے، اس پر کون سے کاروباری اصول لاگو ہوتے ہیں، یہ کیا استعمال کرتی ہے اور کیا پیدا کرتی ہے” ایسی معلومات جو اصل مصنف کے علاوہ کسی کے ذہن میں موجود نہیں ہے۔

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

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

پھر میں نے دستی طور پر آؤٹ پٹ کا جائزہ لیا، کسی بھی غلطی کو درست کیا، اور نتائج کا ارتکاب کیا۔ پہلا مسودہ 70-80% درست تھا۔ باقی 20 سے 30 فیصد میں، ایجنٹ نے ایک قابل فہم لیکن غلط اندازہ لگایا، اور یہیں پر انسانی جائزہ اہم ہے۔

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

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

جو نمونہ کام کرتا ہے اسے فی خدمت رکھنا ہے۔ AGENTS.md مواد کو نقل کرنے کے بجائے، یہ مختصر ہے اور دستاویز کی طرف اشارہ کرتا ہے۔ AGENTS.md انڈیکس جو ہمیشہ بھری ہوتی ہے۔ docs/ ہمارے پاس تفصیلات ہیں۔ ایجنٹ متعلقہ دستاویزات کو طلب پر لوڈ کرتے ہیں جب ان کے کام کی ضرورت ہوتی ہے۔

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

پی آر ریویو آرڈر بنانا

یہ وہ ٹکڑا ہے جس نے سب سے زیادہ براہ راست میری قطار کو غیر مسدود کردیا۔

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

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

PR کی تفصیل میں AI کا خلاصہ شامل ہوتا ہے، لہذا جب کوئی بھی PR کھولتا ہے، تو وہ اختلافات کو پڑھنے سے پہلے جائزہ لینے والے کا گرین سگنل سب سے اوپر دیکھیں گے۔

GitHub کو صاف رکھا جاتا ہے۔ PR کے بارے میں بات چیت ان مسائل کے بارے میں ہونی چاہئے جن کی اصل میں لوگوں کی ضرورت ہوتی ہے، نہ کہ بار بار آنے والے مسائل جن کو ٹیم پہلے سے ہی حل کرنا جانتی ہے۔

کمانڈز یہاں موجود ہیں: .claude/commands/review-pr.md. یہاں ایک عمومی ورژن ہے: آپ کے ٹولز کی کمانڈ کی ساخت مختلف ہو سکتی ہے، لیکن ظاہری شکل اہم ہے۔

# Review PR

Review the current branch's PR. Be direct. Cite `file:line`. Surface real issues,
no padding.

## 1. Scope the diff

Run, in order:

    gh pr view --json number,title,body,headRefName 2>/dev/null || true
    git fetch origin main
    git log --no-merges origin/main..HEAD --oneline
    git diff origin/main...HEAD --stat
    git diff origin/main...HEAD

Read the PR body. Note the stated intent. Every change should trace to it. Flag
anything that does not.

Use `...` (three dots) for the diff. It compares against the merge base and
excludes commits brought in by merging main.

## 2. Load rules

Always read `.claude/pr-rules/common.md`.

Then read the per-area file for each workspace touched in the diff:

| Workspace path | Rules file                      |
| -------------- | ------------------------------- |
| `frontend/**`  | `.claude/pr-rules/frontend.md`  |
| `backend/**`   | `.claude/pr-rules/backend.md`   |
| `service-a/**` | `.claude/pr-rules/service-a.md` |
| `service-b/**` | `.claude/pr-rules/service-b.md` |

For non-trivial changes, follow doc pointers inside the rules files (for
example, `backend/AGENTS.md`, `backend/docs/architecture.md`).

Apply every entry under each file's "Lessons learned" section as a check.

## 3. Output

Use exactly this format.

    ## Summary
    

    ## Blocking
    - [file:line] issue, why it blocks

    ## Should fix
    - [file:line] issue

    ## Nice to have
    - issue

    ## Verified
    - what was checked and looks good

If nothing blocks, say so. Do not manufacture concerns.

If you find an issue worth remembering for future PRs, suggest the bullet to
add to the relevant rules file's "Lessons learned" section. Do not edit the
rules file yourself, leave that to the human.

کمانڈ کے ڈیزائن کے انتخاب میں سے کچھ توقع سے زیادہ اہم نکلے۔

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

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

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

ہر PR میں، جب انسان کچھ ٹھیک کرتا ہے یا AI کچھ تجویز کرتا ہے، تو ہم اسے MD فائل میں شامل کرتے رہتے ہیں اور مستقبل کے لیے ایجنٹ کو بہتر بناتے رہتے ہیں۔ نتائج تیزی سے ترکیب کیے جاتے ہیں۔

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

گارڈریلز: صرف پڑھنے کے لیے بطور ڈیفالٹ

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

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

پہلا ہے۔ راز اور ترتیب. اس کی کوئی بھی پڑھائی جو اسناد کے طور پر نظر آتی ہے مسدود ہے۔ مندرجات یہ ہیں۔ .env تمام قسموں کی فائلیں (.env، .env.local، .env.production، .env.testوغیرہ) .npmrc، .netrc، .pgpass، id_rsa، id_ed25519، *.pem، *.key، *.p12، **/credentials.json، **/secrets.json، **/.aws/**، **/.ssh/**، **/.gcloud/**اور **/.kube/**. ماحولیات کے ڈھیر بھی بند ہیں۔ env، printenv، set، export. ایجنٹوں کے پاس ان چیزوں کو پڑھنے یا بازگشت کرنے کی کوئی معقول وجہ نہیں ہے۔

دوسرا ہے۔ تباہ کن گٹ آپریشنز. ایجنٹ Git کی تاریخ پڑھ سکتا ہے، لیکن اسے دوبارہ نہیں لکھ سکتا یا آگے نہیں بڑھا سکتا۔ مسدود: git push، git commit، git revert، git cherry-pick، git merge، git rebase، git reset --hard، git tag. اجازت یافتہ: git fetch، git status، git log، git diff، git show، git branch، git rev-parse، git merge-base، git config --get.

تیسرا ہے۔ PR اور مسائل کے لیے لکھنا. ایجنٹ GitHub کی حالت پڑھ سکتا ہے، لیکن اس پر کارروائی نہیں کر سکتا۔ مسدود: gh pr create، gh pr edit، gh pr merge، gh pr close، gh pr comment، gh pr review، gh issue create، gh issue edit، gh issue close، gh issue comment، gh release create، gh repo create، gh repo edit، gh repo delete. اجازت یافتہ: gh pr view، gh pr list، gh pr diff، gh pr checks، gh issue view، gh issue list، gh release view.

چوتھا ہے۔ ورک فلو اور آٹومیشن کنٹرول. یہ وہ سطح ہے جہاں خراب یا گمراہ ایجنٹ سب سے زیادہ نقصان پہنچا سکتا ہے۔ مسدود: gh workflow run، gh run rerun، gh run cancel، gh secret، gh variable، gh auth، gh ssh-key، gh gpg-keyاور لامحدود gh api.

شیل کمانڈز کے لیے جن پر ایجنٹ کو قانونی طور پر عمل کرنا چاہیے، جیسے کہ تعمیر اور جانچ کے حکم، وائٹ لسٹ میں مخصوص پیٹرن شامل کریں۔ pnpm test، pnpm lint، pnpm format:check، pnpm build، pnpm vitest. وائٹ لسٹ سے باہر کے آئٹمز کو انسانی تصدیق کی ضرورت ہوتی ہے۔ یہ آپ کا اپنا سیٹ اپ ہے۔ میں نے صرف اپنی پسند کا ذکر کیا۔

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

ایک بار جب ڈھانچہ اپنی جگہ پر تھا اور گارڈریلز اپنی جگہ پر تھے، نظام کام کرنے لگا۔ جس چیز کی مجھے توقع نہیں تھی وہ یہ تھی کہ آنے والے مہینوں میں چیزیں کتنی بہتر ہوں گی۔

پیچیدہ لوپس ایک حقیقی فرق کرتے ہیں۔

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

پہلے مہینے میں جائزہ کا بوجھ 35 فیصد کم ہوا۔ PRs کی تصدیق کرنے میں لگنے والے وقت کو تقریباً ایک تہائی کم کر دیا گیا ہے۔ یہ ٹھیک ہے اور یہ زندگی بدلنے والا نہیں ہے۔

یہ وہ اوزار نہیں تھے جو وقت کے ساتھ بدلتے رہے۔ یہی اصول تھا۔

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

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

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

AI PR جائزہ لینے والے ٹولز کا جائزہ لیتے وقت زیادہ تر ٹیمیں یہی کھو دیتی ہیں۔ وہ آج کے کیچ کو دیکھتے ہیں اور فیصلہ کرتے ہیں کہ کیا اس سے نمٹنے کی قیمت ہے۔ آج کا کیچ درست اعداد و شمار نہیں ہے۔ صحیح نمبر چھ ماہ کے بعد کیچ ریٹ ہے، جب کہ رولز فائل ٹیم کی تمام بار بار کی غلطیوں کو جذب کر لیتی ہے۔

آج میں نے جو واحد قاعدہ لکھا ہے وہ میرا جائزہ لینے کا کچھ وقت بچائے گا۔ 100 سے زیادہ PRs کے ساتھ، آپ اس سے بھی زیادہ بچا سکتے ہیں۔ ایک سال کے بعد، رولز فائل ٹیکنیکل ڈائریکٹر کے جمع کردہ ذوق کا ریکارڈ شدہ ورژن بن جاتی ہے۔ اس دوران، میں نے مختلف کاموں کے لیے Claude Code، GitHub Copilot CLI، اور کرسر کے درمیان سوئچ کیا۔ AI ٹولز بدل جاتے ہیں، لیکن ریپوزٹری میں رولز فائلیں وہی رہتی ہیں۔

ایسا کرنے کا نظم و ضبط یہ ہے کہ قواعد کی فائل کو ایک زندہ دستاویز کے طور پر سمجھا جائے۔ تمام دوبارہ جائزے کے تبصرے فائل میں پروموشن کے امیدوار ہیں۔ اگر آپ دو مختلف PRs میں ایک ہی رائے درج کرتے ہیں، تو یہ درج ذیل اصولوں کے تحت آتا ہے: pr-rules/. ریویو آرڈر میں "گولی کی تجویز” کی رہنمائی ہی اسے عملی بناتی ہے۔ AI ان پٹ کرتا ہے اور انسان فیصلہ کرتے ہیں۔

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

موجودہ پروجیکٹ میں صفر سے شروع کریں۔

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

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

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

اصل میں شروع کرنے کا طریقہ یہاں ہے:

چلائیں /init (یا آپ کے آلے کے برابر)۔ کلاڈ کے کوڈ میں: /init یہ پروجیکٹ کو اسکین کرتا ہے، اس کی واضح شکل (زبان، فریم ورک، انٹری پوائنٹ، بلڈ کمانڈز) کا تخمینہ لگاتا ہے اور ابتدائی معلومات کو پُر کرتا ہے۔ CLAUDE.md. آؤٹ پٹ ایک نقطہ آغاز ہے، مکمل فائل نہیں. اسے پڑھیں، اس سے جو کچھ پیدا ہوتا ہے اسے حذف کر دیں، اور کنکال رکھیں۔

پھر ہم تین مزید شامل کرتے ہیں۔ ہر آئٹم گولی کی لمبائی ہے۔

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

دوسرا، دریافت کرنے کا اصول۔ کوڈ کا ایک نیا ٹکڑا منتخب کریں جس کے ڈپلیکیٹ ہونے کا زیادہ امکان ہے – آپ کی ٹیم کے پاس سب سے اہم مشترکہ وسائل۔ ہمارے لیے یہ ایک ڈیزائن سسٹم تھا۔ بلٹ پوائنٹ پڑھتا ہے: "نیا UI جزو بنانے سے پہلے، درج ذیل کو چیک کریں: /src/design-system/ پہلے۔”

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

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

اگر تین اصول بھی بہت بوجھل ہیں تو ایک سے شروع کریں۔ اپنے کوڈ بیس سے ایک اہم لائن چنیں اور اسے لکھ دیں۔

"نہیں any ٹائپ اسکرپٹ میں ٹائپ کریں۔

کل مزید شامل کریں۔ آپ اپنی دہرائی جانے والی 5% غلطیوں کو پہلے ہفتے میں پکڑ سکتے ہیں۔ اگر آپ کو 20~30 PRs ملتے ہیں، تو آپ 20~30% حاصل کر سکتے ہیں۔ اصولوں کی فائل کو پہلے متاثر کن ہونا ضروری نہیں ہے۔ اس کا وجود ہونا چاہیے اور بڑھتا رہنا چاہیے۔

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

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

غلطی پہلے دن سے ایک کامل فائل بنانے کی کوشش کر رہی ہے۔ صحیح فائل وہی ہے جس سے آپ شروع کرتے ہیں اور ترمیم کرتے رہتے ہیں۔

اب بھی انسانی جائزہ کی ضرورت ہے۔

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

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

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

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

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

2 ہفتے کا سیٹ اپ پلان

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

دن 1: میموری فائل کو بوٹسٹریپ کریں۔

چلائیں /init (یا مساوی ٹول) پروجیکٹ کی جڑ سے۔ پیدا شدہ پڑھتا ہے CLAUDE.md (یا AGENTS.md)۔ ان میں سے بیشتر کو حذف کریں۔ تکنیکی اسٹیک اور پروجیکٹ ڈھانچے کے حصوں کو برقرار رکھیں۔

پچھلے حصے سے تین اصول شامل کریں: ایک آرکیٹیکچرل قاعدہ، ایک دریافت ہونے کا اصول، اور ایک "کوئی رسائی نہیں” کا اصول۔ فیصلہ کریں کہ آپ دونوں فائلیں چاہتے ہیں یا علامتی لنک۔

دن 2: سب سے زیادہ خطرے والے علاقوں کے لیے سروس کے لیے مخصوص فائلیں شامل کریں۔

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

دن 3: ڈائرکٹری کا ڈھانچہ اور گارڈریلز ترتیب دینا

بنانا .claude/ فولڈر (یا اپنے ٹول کے مساوی فولڈر) کو جڑ میں رکھیں اور commands/ اور pr-rules/ ذیلی فولڈرز۔ اضافہ settings.json Guardrails سیکشن میں Deny List زمرہ استعمال کریں۔ جانچ کرتا ہے کہ آیا ایجنٹ پڑھنے کے قابل نہیں ہے۔ .env فائل، چلائیں git pushیا PR لکھیں۔ اگر ان میں سے کوئی کام کرتا ہے تو، کچھ اور کرنے سے پہلے ترتیبات میں ترمیم کریں۔

دن 4: PR جائزہ آرڈر لکھیں۔

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

دن 5: ایک حقیقی PR پر چل رہا ہے۔

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

ہفتہ 2: ریلیز اور دستاویزات

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

پھر ورکنگ سسٹم کام کرے گا۔ یہاں سے دیکھ بھال بتدریج آگے بڑھتی ہے۔ تمام دوبارہ جائزے کے تبصرے امیدوار کے اصول بن جاتے ہیں۔ ہر تعمیراتی فیصلہ متعلقہ اپ ڈیٹ کے لیے امیدوار اپ ڈیٹ بن جاتا ہے۔ AGENTS.md. ٹیم پہلے سے کیا کر رہی ہے اس کے ضمنی اثر کے طور پر نظام بہتر ہوتا ہے۔

کیا کام کر رہا ہے، کیا اب بھی بہتر ہو رہا ہے۔

کئی مہینوں کی مشق کے بعد میرا ایماندارانہ جائزہ یہ ہے۔

کیا کام کرتا ہے

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

ابھی ختم نہیں ہوا۔

AI میں ابھی بھی سیاق و سباق کے مسائل غائب ہیں، اور قواعد ان پر گرفت نہیں کرتے ہیں۔ قواعد کی فائلیں بڑی ہوتی ہیں اور صفائی کی ضرورت ہوتی ہے۔ اس کے لیے ہم نظم و ضبط کے پابند نہیں تھے۔

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

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

اگر آپ اس مضمون سے تین چیزیں لیتے ہیں تو یہ لیں:

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

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

ذریعہ

CircleCI کی 2026 اسٹیٹ آف سافٹ ویئر ڈیلیوری رپورٹ 22,000+ تنظیموں میں 28 ملین CI ورک فلو کا تجزیہ کرتی ہے: https://circleci.com/resources/2026-state-of-software-delivery/
CircleCI کی طرف سے ایک بلاگ پوسٹ جس میں سال بہ سال تھرو پٹ نمبرز کی تفصیل ہے، بشمول 59% فیچر کوارٹر گروتھ اور کلیدی سہ ماہی کمی: https://circleci.com/blog/five-takeaways-2026-software-delivery-report/
1 جون 2026 کو Copilot کے استعمال پر مبنی بلنگ میں منتقل ہونے کے بارے میں GitHub کا اعلان: https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/
GitHub تبدیلی لاگز جو copilot کوڈ کے جائزوں کی تصدیق کرتے ہیں GitHub ایکشن کے اوقات کا استعمال 1 جون 2026 سے شروع ہو جائیں گے۔
AGENTS.md، اوپن اسٹینڈرڈ کی آفیشل سائٹ، بشمول Agentic AI فاؤنڈیشن اور لینکس فاؤنڈیشن کا انتظام: https://agents.md/
میموری سسٹم پر انتھروپک کے کلاڈ کوڈ کی دستاویزات، بشمول CLAUDE.md، خودکار میموری، اور /init کمانڈ: https://code.claude.com/docs/en/memory
اینتھروپک کا کلاڈ کوڈ گٹ ہب ایکشن دستاویز، بشمول ٹوکن پر مبنی بلنگ اور تجویز کردہ لاگت کے انتظام کے نوٹس: https://code.claude.com/docs/en/github-actions
CodeRabbit کی قیمتوں کا دستاویز فی ڈویلپر کے ماہانہ سیٹنگ ماڈل کی تصدیق کرتا ہے: https://docs.coderabbit.ai/management/plans
گریپٹائل کا مارچ 2026 کی قیمتوں کا اعلان، 50 جائزوں کے ساتھ $30 فی سیٹ فی مہینہ پلس کے استعمال کا ایک بنیادی ماڈل متعارف کروا رہا ہے: https://www.greptile.com/blog/greptile-v4
ایک اچھا CLAUDE.md لکھنے پر HumanLayer کا مضمون، بشمول کمانڈ پر منحصر کارکردگی کے انحطاط پر ڈیٹا: https://www.humanlayer.dev/blog/writing-a-good-claude-md