Technology · · 5 min read
Meta انجینئرنگ پر اے آئی کے اثرات جانچنے کے لیے کوڈ میں تبدیلیوں کا ڈیٹا استعمال کرتی ہے
Meta کے محقق Moritz Beller کے ساتھ گفتگو میں کمپنی کے ڈویلپرز کی پیداواری صلاحیت کے پیمانوں، اے آئی کے اثرات اور خودکار ٹیسٹنگ کی حدود کا جائزہ لیا گیا ہے۔
newsletter.getdx.com کی ایک رپورٹ کے مطابق، Meta یہ سمجھنے کے لیے کوڈ میں کی جانے والی انفرادی تبدیلیوں سے حاصل ہونے والی پیمائشیں استعمال کر رہی ہے کہ انجینئرنگ ٹولز اور مصنوعی ذہانت ڈویلپرز کے کام کو کیسے متاثر کر رہے ہیں۔ محقق Moritz Beller کا کہنا ہے کہ کمپنی میں ایک تبدیلی لکھنے میں صرف ہونے والا وقت سال بہ سال 40 فیصد سے زیادہ کم ہوا ہے، جبکہ انجینئرز زیادہ تعداد میں اور بڑی تبدیلیاں کر رہے ہیں۔
اس پیمانے کو diff authoring time کہا جاتا ہے، اور یہ کوڈ میں ایک تبدیلی تخلیق کرنے، اسے ٹیسٹ کرنے اور اس کا جائزہ لینے میں صرف ہونے والی فعال محنت کو ریکارڈ کرتا ہے۔ تبدیلیوں کو انفرادی طور پر دیکھنے سے Meta کو اس کے مقابلے میں زیادہ مرکوز تصویر ملتی ہے جو پورے دن میں ڈویلپر کے کیے گئے ہر کام کی بنیاد پر پیداواری صلاحیت کا حساب لگا کر حاصل ہوتی ہے۔
Meta اس پیمانے کو انفرادی انجینئرز کی درجہ بندی یا ان کی کارکردگی جانچنے کے لیے استعمال نہیں کرتی۔ اس کے بجائے، وہ ٹیموں، شعبوں اور پوری کمپنی میں موجود رجحانات کا جائزہ لیتی ہے۔ مقصد یہ معلوم کرنا ہے کہ کارکردگی میں کہاں گراوٹ آ رہی ہے، مفید بہتریوں کی نشان دہی کرنا اور یہ فیصلہ کرنا کہ انجینئرنگ ٹولز میں مزید سرمایہ کاری کہاں مناسب ہے۔
پیداواری صلاحیت کا زیادہ تفصیلی جائزہ
کمپنی diff authoring time کو متعدد پیمانوں میں سے ایک اشارہ سمجھتی ہے۔ اس کے ساتھ کام کی مقدار، تبدیلیوں کا حجم اور ان کا معیار بھی دیکھا جاتا ہے، کیونکہ کوئی ایک پیمانہ انجینئرنگ کی پیداواری صلاحیت کو قابلِ اعتماد طور پر بیان نہیں کر سکتا۔ مثال کے طور پر، کسی تبدیلی کو مکمل کرنے میں کم وقت لگنا لازماً فائدہ مند نہیں، اگر نتیجے میں بننے والا کوڈ ناقص ہو یا اس میں خاصی اصلاح درکار ہو۔
یہ طریقۂ کار Meta کو یہ جانچنے کی بھی اجازت دیتا ہے کہ فریم ورکس اور ڈویلپر ٹولز میں کی جانے والی تبدیلیاں عملی فوائد پیدا کرتی ہیں یا نہیں۔ رپورٹ میں React compiler میں خودکار memoization کی مثال دی گئی ہے۔ خود ہاتھ سے caching شامل کرنے کے مقابلے میں compiler کے خودکار طریقے نے تبدیلی لکھنے کے لیے درکار وقت میں تقریباً 30 فیصد کمی کی۔ Beller کے مطابق اس پیمانے کے نتائج اس بات کا ثبوت ہیں کہ ڈویلپمنٹ کے ماحول میں بنیادی بہتریاں انٹرفیس میں معمولی اصلاحات سے زیادہ اہم ہو سکتی ہیں۔
تبدیلی لکھنے کے وقت میں کمی کی مکمل وضاحت تیز تر ٹائپنگ یا کوڈ تیار ہونے سے نہیں ہوتی۔ Beller کا خیال ہے کہ ڈویلپرز بچنے والے وقت کو پس منظر کی معلومات جمع کرنے اور implementation سے متعلق کام نمٹانے میں استعمال کر رہے ہوں گے۔ ایسا معلوم ہوتا ہے کہ prompt لکھنے کا حصہ اس اضافی سرگرمی میں بہت کم ہے۔
جیسے جیسے کوڈ تیار کرنا کم مہنگا ہوتا جائے گا، زیادہ مشکل مسئلہ شاید یہ طے کرنا ہو گا کہ کوڈ کو کرنا کیا چاہیے۔ ڈویلپر کی نیت کی اہمیت اس وقت بڑھ جاتی ہے جب کوئی خودکار نظام تیزی سے implementation تیار تو کر سکتا ہو، لیکن نامکمل درخواست کو غلط سمجھ سکتا ہو۔
پیداواری صلاحیت کے پیمانے کیا نظرانداز کرتے ہیں
روایتی ٹیلی میٹری کوڈ میں ہونے والی تبدیلیاں ریکارڈ کرنے میں تو بہتر ہے، لیکن ان سے پہلے ہونے والے کام کو ریکارڈ کرنے میں کم مؤثر ہے۔ وائٹ بورڈ پر منصوبہ بندی، خیالات پر غور اور architecture سے متعلق گفتگو کسی نتیجے کے لیے نہایت اہم ہو سکتی ہے، مگر بعد میں بننے والی diff سے ان کا واضح تعلق موجود نہ ہو۔ اے آئی کے ذریعے تیار کیے گئے میٹنگ ٹرانسکرپٹس اور دیگر ریکارڈز مستقبل میں اس تیاری کے بعض حصوں کا مطالعہ آسان بنا سکتے ہیں۔
اس کا مطلب یہ نہیں کہ architecture کی اہمیت کم ہو گئی ہے۔ ڈیزائن دستاویز بنانے سے گریز کا مطلب صرف یہ ہو سکتا ہے کہ بوجھ reviewers پر منتقل ہو جائے، جنہیں مکمل implementation سے مطلوبہ ساخت کا اندازہ لگانا پڑے۔ چنانچہ تیز تر پیداوار انجینئرنگ کے عمل میں کہیں اور ہونے والے اضافی کام کو چھپا سکتی ہے۔
Beller کے اس سے پہلے کے Mind the Gap مطالعے میں خودکار طور پر ریکارڈ کی گئی سرگرمی کا ڈویلپرز کی جانب سے اپنی پیداواری صلاحیت کے جائزوں سے موازنہ کیا گیا تھا۔ کوڈنگ میں صرف ہونے والا وقت ایک اہم پیش گو تھا، لیکن آرام، خلل اور on-call ذمہ داریوں نے بھی اس بات پر اثر ڈالا کہ لوگوں نے خود کو کتنا پیداواری محسوس کیا۔ نئے ورژن میں یہ جانچنا ضروری ہو گا کہ ڈویلپرز agents کے ساتھ کیسے کام کرتے ہیں، انہیں agents پر کتنا اعتماد ہوتا ہے اور آیا بیک وقت کئی خودکار کاموں میں ہم آہنگی پیدا کرنا ذہنی دباؤ کو حد سے زیادہ بڑھا دیتا ہے۔
زیادہ پیداوار بہتر تجربۂ کار کی ضمانت بھی نہیں دیتی۔ گفتگو میں بتایا گیا ہے کہ پیداواری صلاحیت بڑھ سکتی ہے، جبکہ توجہ، ذہنی محنت اور مجموعی اطمینان میں کوئی تبدیلی نہ آئے یا وہ کم ہو جائیں۔ باہمی تعلقات، مشترکہ سمجھ بوجھ اور غیر رسمی معلومات کا تبادلہ انجینئرنگ کے کام کے لیے اہم ہیں، لیکن زیادہ تر پیمانوں میں ان کی نمائندگی کرنا اب بھی مشکل ہے۔
غیر ضروری میٹنگز کم کرنے سے کام کی رفتار بہتر ہو سکتی ہے، لیکن تعاون بہت زیادہ کم کر دینے سے ٹیمیں خیالات اور پس منظر کی معلومات سے محروم ہو سکتی ہیں۔ چھوٹی سماجی گفتگو بھی اہمیت رکھتی ہے: اس قسط میں زیرِ بحث تحقیق سے معلوم ہوا کہ میٹنگز سے پہلے اور بعد کی غیر رسمی گفتگو لوگوں کی جانب سے بتائی گئی پیداواری صلاحیت کی پیش گوئی انٹرنیٹ کے معیار کے مقابلے میں زیادہ مضبوطی سے کرتی ہے۔
اے آئی agents کے لیے ٹیسٹنگ کا چیلنج
اے آئی agents کے ذریعے unit اور end-to-end ٹیسٹ بنانا سستا ہو جاتا ہے، جس سے ان ڈویلپرز کے درمیان ایک دیرینہ خلا پُر ہونے کا امکان ہے جو پہلے بہت کم خودکار ٹیسٹ لکھتے تھے۔ لیکن کامیاب ہونے والے ٹیسٹس کا مجموعہ اس وقت گمراہ کن اطمینان دے سکتا ہے جب implementation اور ٹیسٹس دونوں ہی کسی مبہم درخواست کی ایک ہی غلط تشریح پر مبنی ہوں۔
کوئی agent ایسا کوڈ اور ٹیسٹس تیار کر سکتا ہے جو اندرونی طور پر ایک دوسرے سے مطابقت رکھتے ہوں، لیکن پھر بھی ڈویلپر کا اصل مقصد پورا نہ کرتے ہوں۔ یہ خطرہ implementation شروع ہونے سے پہلے درستگی کی تعریف طے کرنے کی اہمیت بڑھا دیتا ہے۔ گفتگو سے اشارہ ملتا ہے کہ جیسے جیسے agents زیادہ کوڈنگ کا کام سنبھالیں گے، specification-driven development، test-driven development کا ایک متبادل یا تکمیلی طریقہ بن سکتا ہے۔
خودکار implementation کی رفتار یہ خطرہ بھی بڑھاتی ہے کہ ٹیمیں لاعلمی میں ایک ہی چیز متوازی طور پر تیار کر رہی ہوں۔ بہتر پیمائش کے لیے صرف مکمل کیے گئے کوڈ ہی نہیں بلکہ ہم آہنگی، رابطے اور دہرائی گئی محنت کو بھی مدِنظر رکھنا ہو گا۔ Meta کا diff-level ڈیٹا نئے ٹولز کے بعض اثرات دیکھنے کا ایک طریقہ فراہم کرتا ہے، لیکن وسیع تر گفتگو سے واضح ہوتا ہے کہ انجینئرنگ کی پیداواری صلاحیت تکنیکی مسئلے کے ساتھ ساتھ انسانی اور تنظیمی مسئلہ بھی ہے۔