مرکزی نیویگیشن

ایجنٹک کوڈنگ میں ریویو کی رکاوٹ دور کرنا

ایجنٹک کوڈنگ رکاوٹ کو کوڈ جنریٹ کرنے سے اس کے جائزے کی طرف منتقل کرتی ہے, اس لیے پُراعتماد ریویو کے ورک فلوز ضروری ہیں.

انتظامی خلاصہ

  • ایجنٹک کوڈنگ اپنانے والی زیادہ تر ٹیموں میں رکاوٹ کوڈ جنریٹ کرنے سے منتقل ہو کر ریویو میں آ جاتی ہے, اور اس عمل کو بہتر کیے بغیر مجموعی رفتار میں اضافہ تقریباً صفر رہتا ہے.

  • بڑے پیمانے کے CI ماحول میں, (جہاں ہر رات لاکھوں جانچیں ہوتی ہیں اور سینکڑوں انجینئر کام کرتے ہیں), ایجنٹ کا سب سے مفید کام کوڈ جنریٹ کرنا نہیں بلکہ مسئلے کو ذمہ دار ٹیم تک پہنچانا اور ابتدائی چھان بین کرنا ہے.

  • ایجنٹ کا مفید نتیجہ کڑی جانچ پر پورا اترتا ہے اور محض مماثل نمونے دکھانے کے بجائے سبب واضح کرتا ہے.

  • شواہد جمع کرنے اور سیاق و سباق مرتب کرنے والی سطح کا ڈیزائن, مواد بنانے والی سطح سے زیادہ اہم ہے.

ایجنٹک کوڈنگ پر زیادہ تر گفتگو اب بھی ایک سادہ وعدے سے شروع ہوتی ہے: زیادہ کوڈ, زیادہ تیزی سے لکھنا.

کبھی یہ تصور مزید پھیل کر ایک بلند ہدف بن جاتا ہے, جس میں ایجنٹس کام کی منصوبہ بندی کرتے, PR کھولتے اور بہت کم انسانی مداخلت سے تبدیلیاں جاری کرتے ہیں. لیکن زیادہ تر انجینئرنگ ٹیموں کے لیے مستقبل قریب کا سب سے واضح فائدہ زیادہ محدود ہے. یہ تکراری عمل کی لاگت کم کرنے کے بارے میں ہے.

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

صرف کوڈ جنریٹ کرنے کی رفتار بڑھانے سے ٹیم خود بخود تیز نہیں ہو جاتی. اس سے ریویو, تصدیق اور اعتماد قائم کرنے پر صرف ہونے والی محنت بڑھ سکتی ہے.

اصل رکاوٹ اعتماد ہے

بہت سے انجینئرنگ ماحول میں مہنگا مرحلہ پہلا مسودہ بنانا نہیں بلکہ اس پر اعتماد حاصل کرنا ہے.

کیا اس تبدیلی نے واقعی مسئلہ حل کیا یا سسٹم کو بہتر بنایا؟ کیا اس کی وجہ سے کہیں اور کوئی نئی خرابی پیدا ہوئی؟ کیا کوڈ میں خرابی, ماحول, ٹیسٹس یا کسی ڈیپنڈنسی میں ہے؟ کیا تجویز کردہ حل اصل وجہ کو دور کر رہا ہے یا صرف نظر آنے والی علامت کو؟

ایجنٹس یہاں انجینئروں کی جگہ لے کر نہیں بلکہ بے ترتیب شواہد کا منظم ابتدائی جائزہ لے کر مدد کر سکتے ہیں: لاگز کا معائنہ کرنا, حالیہ تبدیلیوں کا موازنہ کرنا, متعلقہ اشاروں کا خلاصہ تیار کرنا, ممکنہ وجوہات کا سراغ لگانا, جانچیں چلانا اور ایسا نتیجہ پیش کرنا جس پر انسان مزید سوالات کر سکے.

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

زیادہ جائزے والے طریقۂ کار کیوں موزوں ہیں

بڑے پیمانے پر ڈیبگنگ کے ورک فلوز میں یہ بات خاص طور پر واضح ہوتی ہے. تصور کریں کہ کے وقت CI لاکھوں ٹیسٹس چلا رہا ہے, جو سینکڑوں انجینئرز کی جانب سے تبدیل کیے گئے کوڈ بیسز میں کیے جاتے ہیں (ہمارے ایک کلائنٹ کے لیے یہ ایک حقیقی صورتِ حال ہے). کسی خرابی کی صورت میں اسے ذمہ دار ٹیم تک پہنچانا مشکل ہوتا ہے. مسئلہ ایپلیکیشن کوڈ, کسی ڈیپنڈنسی, ٹیسٹ ہارنس یا سسٹم کی کسی اور سطح میں ہو سکتا ہے. لاگز کئی گیگا بائٹس تک پہنچ سکتے ہیں, اور مسئلہ سب سے پہلے دیکھنے والی ٹیم ضروری نہیں کہ وہی ٹیم ہو جو اس کی ذمہ دار ہو.

اس طرح کا ورک فلو فطری طور پر یہ تقاضا نہیں کرتا کہ ایک ایجنٹ حل لکھے. یہ ایسے سسٹم کے لیے موزوں ہے جو مسئلے کا دائرہ تیزی سے محدود کرے.

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

ڈائیگرام دکھاتا ہے کہ زیادہ جائزے والے طریقۂ کار کیوں موزوں ہیں.

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

نتیجے کے بجائے بہتر طریقۂ کار تلاش کریں

اسی لیے ٹیموں کو ان سسٹمز کا جائزہ لیتے وقت احتیاط کرنی چاہیے.

غلط سوال یہ ہے کہ آیا ایجنٹ تنہا کوئی متاثر کن چیز بنا سکتا ہے. بہتر سوال یہ ہے کہ آیا وہ کسی حقیقی طریقۂ کار کو بہتر بناتا ہے, بغیر اس کے کہ کہیں اور رکاوٹ پیدا ہو.

اس کا مطلب یہ دیکھنا ہے کہ نتیجہ تصدیق کے لیے کافی مخصوص ہے, وہ صرف نمونوں کی مماثلت کے بجائے سبب واضح کرتا ہے, اور جائزے کو مشکل بنانے کے بجائے آسان کرتا ہے. قابل یقین جواب لازماً مفید جواب نہیں ہوتا. عملاً ٹیمیں ایجنٹ کے نتیجے پر تب اعتماد کرتی ہیں جب وہ کڑی جانچ پر پورا اترے اور انہیں جانچنے کے لیے کوئی ٹھوس چیز دے.

ڈائیگرام دکھاتا ہے کہ نتیجے کے بجائے بہتر طریقۂ کار تلاش کریں.

مشکل کام اس عمل کو ڈیزائن کرنا ہے

گہرا سبق یہ ہے کہ مفید ایجنٹک سسٹم محض مواد بنانے پر منحصر نہیں ہوتے. ان کی افادیت اس بات پر منحصر ہے کہ شواہد کیسے جمع کیے جاتے ہیں, سیاق و سباق کیسے مرتب ہوتا ہے, نتائج کیسے جانچے جاتے ہیں اور جائزہ لینے والے کے سامنے غیر یقینی صورت حال کیسے واضح کی جاتی ہے.

اسی لیے مستقبل قریب میں ایجنٹک انجینئرنگ کا مکمل خود مختاری کی جانب ایک ہی بڑی چھلانگ لگانے کا امکان کم ہے. زیادہ امکان ایسے مضبوطی سے ڈیزائن کیے گئے عمل کا ہے, جہاں ایجنٹس ہر مرحلے کے درمیان ضائع ہونے والی محنت کم کرتے ہوئے ٹیموں کو کام کا معائنہ, ریویو, تصدیق اور اصلاح کرنے میں مدد دیں.

یہ مکمل خود مختاری کے وسیع تر تصور سے کم سنسنی خیز ہو سکتا ہے, مگر مفید سسٹم حقیقت میں جس طرح اپنائے جاتے ہیں اس سے کہیں زیادہ قریب ہے.

مصنفین

Atharva Tidke، George Montagu