AI agent نے code لکھ دیا؛ اب فیصلوں کا audit trail کون محفوظ کرے؟

مسلسل چلنے والے coding agents کے فیصلوں کا audit trail انجینئرنگ ٹیم کی ذمہ داری ہے۔ ہر agent run کو کام کے ٹکٹ، بنائی گئی pull request اور انسانی منظوری سے جوڑیں۔ محفوظ ریکارڈ سے بعد میں معلوم ہونا چاہیے کہ agent کو کیا کام دیا گیا، اس نے کون سا سیاق استعمال کیا، کس اختیار سے کیا بدلا، کیا جانچا گیا اور کون سا خطرہ باقی رہنے کے باوجود تبدیلی منظور ہوئی۔

ستمبر ۲۰۲۶ کی Atlassian کی تحقیق کے مطابق، ۱۱۰۰ سے زیادہ engineers اور engineering leaders کے سروے میں ۹۴ فیصد engineering leaders نے کہا کہ ان کی تنظیم AI استعمال کرتی ہے، مگر صرف ۱۹ فیصد نے اس کے لیے governed engineering system بنایا تھا؛ کمپنی کے داخلی تجربے میں Atlassian Teamwork Graph کا سیاق استعمال کرنے والے agents کے جوابات کا معیار ۴۴ فیصد بہتر ہوا اور tokens کا استعمال ۴۸ فیصد کم رہا۔ یہ داخلی نتیجہ دوسری ٹیموں میں اسی بہتری کی ضمانت نہیں دیتا، لیکن یہ دکھاتا ہے کہ agent کو فراہم کیا گیا سیاق بھی فیصلے کے ریکارڈ میں اہم ہے۔

ریکارڈ کا مالک کون ہو؟

Agent اپنی کارروائی درج کر سکتا ہے، مگر اپنے اختیار، قبولیت کے معیار یا merge کے فیصلے کا حتمی مالک نہیں ہو سکتا۔ engineering lead کو طے کرنا ہوگا کہ run کس کام کے لیے شروع ہو، ثبوت کہاں محفوظ ہوں اور کس مرحلے پر انسان کی منظوری لازم ہو۔ روزمرہ عمل میں کام کا دائرہ مقرر کرنے، repository کی اجازت سنبھالنے اور pull request منظور کرنے کی ذمہ داریاں واضح افراد سے منسوب ہونی چاہییں۔

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

کام سے پہلے سیاق اور اختیار کیسے مقرر ہوں؟

ہر run کو ایک متعین task سے باندھیں۔ ٹکٹ میں مطلوبہ نتیجہ، قبولیت کے معیار، متعلقہ repository اور وہ حصے درج ہوں جنہیں agent نہیں بدل سکتا۔ سیاق کے ریکارڈ میں صرف دستاویز کا نام کافی نہیں؛ اس کا ورژن یا commit، متعلقہ architectural فیصلہ اور run کے دوران دی گئی نئی ہدایت بھی شامل ہو۔ اس طرح reviewer دیکھ سکے گا کہ تبدیلی کس معلومات پر مبنی تھی اور آیا وہ معلومات اس کام کے لیے درست تھیں۔

Permissions کا الگ اندراج رکھیں: agent کون سی repositories پڑھ سکتا تھا، کہاں لکھ سکتا تھا، کون سے tools چلا سکتا تھا اور کیا اسے کسی بیرونی نظام میں write-back کی اجازت تھی۔ پڑھنے، code بدلنے، tests چلانے اور deployment کے اختیارات ایک ہی وسیع اجازت میں نہ سموئیں۔ اگر run کے دوران دائرہ بڑھایا جائے تو اجازت دینے والے شخص، وجہ اور وقت کو اسی run سے جوڑیں؛ ورنہ بعد میں یہ طے کرنا مشکل ہوگا کہ agent نے حد پار کی تھی یا مجاز حد بدل گئی تھی۔

ستمبر ۲۰۲۶ کے Atlassian کے Jira اعلان میں Agent loops، Standards اور AI Review کو private early access میں بتایا گیا، جبکہ Agent Context Controls اور Agent Usage Dashboard کی عمومی دستیابی paid Jira صارفین کے لیے آنے والے مہینوں میں متوقع تھی۔ اس اعلان کو ان controls کی ہر ٹیم کے لیے موجودہ دستیابی نہ سمجھیں۔ بنیادی ریکارڈ ٹکٹ، repository اور review کے ایسے workflow میں قائم کیا جا سکتا ہے جو کسی ایک vendor کی خصوصیت پر منحصر نہ ہو۔

ہر agent run میں کم از کم کون سا ثبوت ہو؟

ایک مختصر، یکساں ریکارڈ reviewer کو تبدیلی سمجھنے اور incident کے وقت متعلقہ کارروائی ڈھونڈنے میں مدد دیتا ہے۔ اسے run کے آغاز پر بنائیں، کارروائی کے دوران واقعات شامل کریں اور pull request پر انسانی فیصلے کے ساتھ مکمل کریں:

• Task intent: ٹکٹ کی شناخت، مطلوبہ نتیجہ، قبولیت کے معیار اور کام شروع کروانے والے شخص کا حوالہ۔
• Source context: پڑھی گئی repositories، دستاویزات اور فیصلوں کے حوالہ جات، ان کے ورژن یا commits، اور دورانِ کام ملنے والی نئی ہدایات۔
• Permissions: agent کی شناخت، مجاز read اور write scope، دستیاب tools، اجازت کی مدت اور دائرہ بدلنے کی منظوری۔
• Tool calls: استعمال شدہ tool، کارروائی کی ترتیب، کامیابی یا ناکامی، اور بیرونی نظام میں ہر write-back کا حوالہ۔
• Generated changes: branch، commits، بدلی ہوئی files، pull request اور تبدیلی کی بیان کردہ وجہ۔
• Tests: چلائی گئی جانچ اور اس کا نتیجہ، نیز وہ جانچ جو نہیں چل سکی اور اس کی وجہ۔ صرف «tests passed» کافی تفصیل نہیں۔
• Reviewer: انسانی reviewer، اٹھائے گئے اعتراضات، ان کے جواب اور منظوری یا واپسی کا فیصلہ۔
• Unresolved risks: باقی خدشات، انہیں قبول کرنے کی وجہ اور بعد میں ان کا ذمہ دار شخص۔

اس schema کا مقصد پوری گفتگو محفوظ کرنا نہیں، بلکہ فیصلے کی بنیاد دوبارہ سمجھنے کے قابل رکھنا ہے۔ ایک مستقل run ID کو ٹکٹ، tool log، test result اور pull request سے جوڑیں؛ commits کی شناخت الگ درج کریں۔ یوں ریکارڈ مختلف نظاموں میں بٹا ہو تب بھی متعلقہ شواہد مل سکتے ہیں۔ اگر کوئی حوالہ عارضی نظام کی طرف جاتا ہے تو اس کے دستیاب رہنے کی مدت پہلے سے طے کریں۔

Pull request میں انسانی فیصلہ کیسے محفوظ ہو؟

Pull request کو review کا مرکزی مقام بنائیں۔ اس میں task اور agent run کے حوالہ جات، commits، جانچ کے نتائج اور وہ سوالات درج ہوں جن پر reviewer کو فیصلہ کرنا ہے۔ GitHub کی agent session دستاویزات کے مطابق Copilot cloud agent کے ہر commit message میں session log کا لنک ہوتا ہے، اور اس log میں repository سمجھنے، تبدیلی کرنے اور کام کی توثیق کے لیے استعمال ہوئے tools دیکھے جا سکتے ہیں۔ یہ ایک مخصوص product میں traceability کی مثال ہے؛ دوسری ٹیموں کو اپنے workflow میں یہی ربط خود قائم کرنا ہوگا۔

ایک فرضی مثال میں agent کو authentication کے کسی حصے میں تبدیلی کا ٹکٹ ملتا ہے۔ اس کی pull request میں صرف بدلی ہوئی files کے بجائے متعلقہ design decision کا ورژن، agent کی write permission، test run کا نتیجہ اور وہ سوال بھی درج ہوگا جس کا جواب ابھی نہیں ملا۔ reviewer code اور ثبوت دیکھ کر تبدیلی واپس بھیج سکتا ہے، یا باقی خطرہ قبول کرنے کی وجہ لکھ کر منظوری دے سکتا ہے۔ agent کا اپنا خلاصہ انسانی sign-off کی جگہ نہیں لیتا۔

مشترک سیاق میں write-back کی منظوری بھی واضح رکھیں۔ agent ٹکٹ میں اپنی کارروائی اور تجویز درج کر سکتا ہے، لیکن نئی architectural بات کو مصدقہ فیصلہ بنا کر شامل کرنے کا اختیار مقررہ مالک کے پاس ہونا چاہیے۔ اس حد کا مقصد یہ ہے کہ اگلا agent کسی غیر منظور شدہ نتیجے کو قائم شدہ اصول سمجھ کر استعمال نہ کرے۔ فیصلے کے بعد ریکارڈ میں منظور شدہ متن یا ورژن کا حوالہ شامل کریں، تاکہ تجویز اور نافذ شدہ فیصلہ الگ پہچانے جا سکیں۔

Incident کے وقت کیا محفوظ ہونا چاہیے؟

غیر متوقع خرابی کی تحقیق میں سوال صرف یہ نہیں ہوتا کہ code کس نے لکھا۔ یہ بھی جاننا پڑتا ہے کہ تبدیلی کس task کے لیے تھی، agent نے کون سا سیاق پڑھا، اسے کس نظام تک رسائی ملی، کون سی جانچ رہ گئی اور انسان نے کس بنیاد پر merge کیا۔ run ID سے ان حوالوں تک پہنچنے کا راستہ پہلے سے موجود ہونا چاہیے۔ اگر session log بعد میں دستیاب نہ ہو تو محفوظ ٹکٹ، commits، test evidence اور منظوری کا ریکارڈ تحقیق کو آگے بڑھانے کے لیے ضروری بنیاد دیتے ہیں۔

ایک مفید audit trail وہ ہے جس سے reviewer agent سے دوبارہ پوچھے بغیر تبدیلی کا مقصد، اختیار، جانچ اور باقی خطرہ سمجھ سکے۔ incident responder کو اسی ریکارڈ سے متعلقہ run، اس کی کارروائی اور انسانی فیصلے تک پہنچنا چاہیے۔ جہاں یہ ربط ٹوٹتا ہے، وہاں مسئلہ code کی نسبت سے زیادہ فیصلے کے ثبوت کا ہے؛ اسے pull request کے مرحلے پر محفوظ کرنا بعد کی تحقیق کے لیے بنیادی شرط ہے۔

یہ بھی پڑھیں:

• Webflow Source میں agent کو code ملے گا، مگر publish اختیار محدود رہ سکتا ہے
• OpenAI کا research intern آ گیا—3.1 agent-days، مگر خود مختاری نہیں
• ServiceNow کے تین flaws کا اسکور 10.0—کون سے instances خطرے میں ہیں؟