ڈیوآپس پایونیر چیتنے ہیں: AI ایجنٹ کی اپنائی کے لیے صرف ٹولز نہیں، بلکہ سسٹم لیول کے تبدیلیوں کی ضرورت ہے

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

مضمون کا مصنف، ذریعہ: InfoQ

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

بہت سے کاروباروں کا کہنا ہے کہ وہ AI میں تبدیلی کر رہے ہیں، لیکن وہ صرف ڈویلپرز کے لیے Cursor، Claude Code جیسے ٹولز خریدنا، کچھ تربیتی سیشن منعقد کرنا، اور باقی لوگوں کو اپنے آپ تلاش کرنے پر چھوڑ دینا ہے۔ اگر آخرکار Agent کا اثر نہیں ہوتا، تو ذمہ داری پھر صرف استعمال کرنے والوں پر چھوٹ جاتی ہے۔

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

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

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

مرکزی نقطہ نظر درج ذیل ہے:

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

2009 میں، بہت سے لوگوں نے مجھے بتایا کہ لگاتار ڈیلیوری کا خیال پاگل پن ہے۔

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

اور اب، اینڈ فیکٹری کو بالکل وہی مزاحمت کا سامنا ہے۔

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

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

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

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

میں سمجھتا ہوں کہ حاضرین میں سے زیادہ تر لوگ کسی ٹیم کے ساتھ کام کرتے ہیں، نہ کہ اکیلے، اور ٹیم کے ساتھ تعاون کرنا اور صرف ایک شخص کClaude Code کے ساتھ کام کرنا بالکل الگ باتیں ہیں۔

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

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

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

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

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

اب میں کمپنی کے ڈیولپرز کو ایک تجویز دینا چاہوں گا: ایجنٹ کی پیدا کردہ کوڈ کو درست نہ کریں، بلکہ اس کوڈ کو پیدا کرنے والے سسٹم کو درست کریں۔ جیسے کچھ سال پہلے کسی نے کہا تھا: وہ چیز بنانے کی بجائے، اس چیز کو بنانے والی چیز بنائیں۔ ہم اب اسی تجریدی سطح پر ہیں، جہاں ہم Context، Harness، اور لوپس کے ذریعے "چیزیں بنانے والی چیز" تخلیق کر رہے ہیں۔ جو لوگ اب بھی "Human in the Loop"، آٹو-کمپلیشن، اور Prompt ٹیوننگ کے مرحلے پر ہیں، انہیں اپنے آپ کو سسٹم سوچ تک بلند کرنے کا خیال کرنا چاہیے۔

ہم جو کچھ سچ مچ کر کرنا چاہتے ہیں، وہ انسانی مداخلت کو کم سے کم کرنے کے لیے اچھی انجینئرنگ کی روایات استعمال کرنا ہے۔ شروع میں، سب کو "vibe coding" پسند آیا — صرف ایک Prompt ڈال دیا، نتیجہ ملا، اور آگے بڑھ گئے۔ لیکن اب ہمیں یہ واضح ہو رہا ہے کہ ہم صرف Agent کو ہدایات دینے کے لیے Prompt استعمال نہیں کر رہے، بلکہ ہم یہ کہہ رہے ہیں: "ٹیسٹ کے ساتھ کوڈ لکھو، دستاویزات اپڈیٹ کرو، اور کوڈنگ سٹائل پر عمل کرو۔" جو باتیں ہم اچھے انجینئرز سے کہتے تھے، وہی باتیں اب ہم Agent کو کہ رہے ہیں۔ اگر آپ کی ٹیم میں کوئی اب بھی "YOLO (پہلے چلاؤ، بعد میں سوچیں)" والے غیر منظم طریقے سے vibe coding کر رہا ہے، تو آپ کو فوراً اسے روکنا چاہیے۔ انجینئرنگ کی روایات نہ صرف آپ کے سسٹم کو برقرار رکھنے کے لیے ضروری ہیں، بلکہ Agent کے خود کو بہتر بنانے کے لیے بھی انتہائی اہم ہیں۔

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تو میں نے سنہا ہے کہ越来越多 کمپنیاں ایسے انٹرویو کا طریقہ اپنا رہی ہیں۔ پہلا مرحلہ، ایک مشق دیں جس میں انہیں AI کا استعمال کرتے ہوئے مسئلہ حل کرنے کی اجازت دی جائے، جتنا ہو سکے AI کا استعمال کریں۔ اگر AI ان کی مدد کر سکتا ہے، تو اس سے ظاہر ہوتا ہے کہ وہ AI کو مؤثر طریقے سے استعمال کرنے میں ماہر ہیں۔ دوسرا مرحلہ، ان سے اپنا حل چیک کرنے اور وضاحت کرنے کو کہیں کہ "آپ نے اس حل کو کیوں منتخب کیا؟ آپ نے اس کی تصدیق کیسے کی؟" — اس وقت آپ ٹیسٹنگ کی صلاحیت اور انجینئرنگ کا جائزہ لے رہے ہیں۔ پہلا حصہ AI استعمال کی صلاحیت کا ٹیسٹ ہے، دوسرا حصہ انجینئرنگ کی بنیادی صلاحیتوں کا۔ تیسرے، ان کے تعاون کا طریقہ بھی دیکھیں، کیا وہ شئیر کرنے کو تیار ہیں، کیا وہ کھلے ٹائپ ہیں یا اکیلے کام کرنے والے؟ کچھ لوگوں کی ٹیکنیکل صلاحیت بہت زیادہ ہوتی ہے لیکن وہ سب کچھ اپنے ہاتھوں میں رکھنا چاہتے ہیں، اس دور میں ایسے لوگ بالکل بھی مسائل پیدا کر سکتے ہیں۔

جو شخص AI کا بہترین استعمال کر سکے، مضبوط انجینئرنگ کی بنیاد رکھتا ہو، اور شیئر کرنے اور تعاون کے لیے تیار ہو، وہی وہ شخص ہے جسے آپ تلاش کر رہے ہیں۔ یہ وہ شخص نہیں جس نے صرف ML یا AI سیکھا ہو، نہ ہی کوئی ڈیکوڈنگ ماہر، بلکہ ایک مجموعی شکل ہے۔ آپ کو شاید ایسا کوئی امیدوار نہ ملے جس کے پاس تینوں گنجائشیں مکمل طور پر موجود ہوں، لیکن اس کا کوئی مسئلہ نہیں — جیسے کوئی امیدوار ایک شعبے میں بہت مضبوط ہو لیکن دوسرے شعبے میں رہنمائی کی ضرورت رکھتا ہو۔ اس کے علاوہ، ان مہارتوں کو "ابتدائی" یا "ماہر" کے طور پر ایک ساتھ نہ لبھائیں، کیونکہ یہ الگ الگ مہارت کے پہلو ہیں، اور ایک شخص کی AI استعمال کی صلاحیت "ماہر" ہو سکتی ہے جبکہ تعاون کا جذبہ "ابتدائی"۔

این جی اینیئرنگ ڈیپارٹمنٹ کو اپنے اوپر والوں کو جواب دینا ہے۔ ہم نے اتنے زیادہ لائسنس خریدے ہیں، کیا ہم اس کا ROI ثابت کر سکتے ہیں؟ کیا ڈیلیوری تیز ہوئی؟ شاید کچھ وعدے ہیں لیکن انہیں ثابت کرنا مشکل ہے۔ کیا کوالٹی بہتر ہوئی؟ اس کا بھی کہنا مشکل ہے۔ لیکن میں پہلے جو دو اشاریے بتائے تھے، ان پر واپس آئیں، آپ یہ دکھا سکتے ہیں کہ انٹروینشنز کتنی کم ہوئیں، کتنی بہتری آئی، اور ری یوز ریٹ کتنی بڑھی۔ "ایجنٹ کے ساتھ اور بغیر ایجنٹ کے کوڈنگ پراڈکٹوٹی" کا موازنہ کرنے کے بجائے، یہ زیادہ آسان اور زیادہ مقنع ہے۔

تو، جب کوئی شکایت کرتا ہے کہ ایجنٹ بہت زیادہ خرچ کر رہا ہے اور اس کی حد کو کم کرنے کا مطالبہ کرتا ہے، تو آپ کی فطری پ्रतिक्रियا یہ نہیں ہونی چاہیے کہ "ہم سب خرچوں کو ختم کر دیں"، بلکہ یہ ہونی چاہیے کہ "ہم خرچ کو کیسے بہتر بنائیں؟" سب سے آسان طریقہ یہ ہے کہ صحیح ماڈل منتخب کریں—ہر کام کے لیے سب سے طاقتور ماڈل کی ضرورت نہیں ہوتی، کچھ کاموں کے لیے سستے ماڈل کافی ہوتے ہیں۔ ڈویلپرز کو سکھائیں کہ کس صورتحال میں کونسا ماڈل استعمال کرنا چاہیے، اور مزید آگے، انہیں بہتر کنٹیکسٹ اور ہارنیس فراہم کریں، جس سے ایجنٹ کم راستوں پر جائے گا اور لاگت مزید کم ہو جائے گی۔

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

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

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

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