AI coding agents تیز ہیں، مگر productivity کا سیدھا جواب اب بھی نہیں

مختصر جواب یہ ہے کہ AI coding agents بعض coding interactions اور ابتدائی output کو تیز کر سکتے ہیں، مگر اس سے پوری engineering ٹیم کی productivity خود بخود نہیں بڑھتی۔ اگر code جلد بنے لیکن review، debugging، rework یا production incidents بڑھ جائیں تو محنت ختم نہیں ہوئی؛ workflow کے اگلے حصے میں منتقل ہوئی ہے۔

اسی لیے کسی ایک benchmark، فیصد یا generated lines کی بنیاد پر rollout کا فیصلہ کمزور ہوگا۔ developer یا engineering manager کو رفتار، قابلِ استعمال delivery، معیار، review burden، code کی سمجھ اور developer experience الگ ناپنے چاہییں؛ موجودہ شواہد کسی ایک، ہر context پر لاگو ہونے والے جواب کی حمایت نہیں کرتے۔

تیز agent اور تیز delivery ایک چیز نہیں

agent کا response time ایک systems metric ہے، developer productivity نہیں۔ جولائی 2026 میں درج Microsoft Research کی production-scale تحقیق نے جون 2026 کے sampled GitHub Copilot traces میں 3.2 ملین users، 13 ملین sessions اور 761 ملین LLM calls کا تجزیہ کیا؛ اس میں ہر user-initiated turn کے اندر LLM calls اور tool execution تقریباً ایک کے مقابل ایک تھے، جبکہ turns کے درمیان کئی منٹ کے idle periods بھی ملے۔

یہ تحقیق دکھاتی ہے کہ agent خودکار loops میں تیزی سے کارروائیاں کر سکتا ہے، لیکن اس کا موضوع workload اور infrastructure تھا، مکمل features، escaped defects یا reviewer time نہیں۔ چنانچہ یہ تیز interaction کا مضبوط ثبوت ہے، end-to-end productivity gain کا نہیں۔

Code volume بھی ادھورا اشارہ ہے۔ agent زیادہ files بدل کر بڑا pull request بنا سکتا ہے، مگر غیر ضروری تبدیلیاں الگ کرنے، generated logic سمجھنے یا failures درست کرنے میں اضافی وقت لگے تو output بڑھنے کے باوجود delivery سست ہو سکتی ہے۔

مطالعات کے فیصد براہ راست کیوں نہیں ملتے

AI-assisted development کی research میں productivity کبھی task completion time، کبھی accepted suggestions، commits، code volume، artifact quality یا satisfaction سے ظاہر کی جاتی ہے۔ ASE 2026 Research Papers میں درج systematic review نے 187 منفرد productivity اور productivity-related markers شناخت کیے، جبکہ انفرادی مطالعات عموماً صرف پانچ markers استعمال کرتی تھیں۔

اسی review کے مطابق مثبت اثرات perceived اور tendency-based findings میں objective یا statistically evaluated نتائج کی نسبت زیادہ نمایاں تھے۔ اس سے مثبت مطالعات باطل نہیں ہوتیں؛ البتہ مختلف tools، tasks، codebases، developer experience اور outcomes کو ایک فیصدی مقابلے میں رکھنا گمراہ کن ہو سکتا ہے۔

مثلاً autocomplete سے isolated function جلد مکمل کرنا، mature repository میں issue حل کرنا اور tested change کو production تک پہنچانا الگ outcomes ہیں۔ کسی نتیجے کو اسی کام، ماحول اور metric تک محدود رکھنا چاہیے جس میں وہ ناپا گیا تھا۔

محسوس ہونے والی رفتار اور ناپا گیا وقت الگ ہو سکتے ہیں

اس فرق کی واضح مثال 2025 کا randomized controlled trial ہے۔ METR کے تجربے میں 16 تجربہ کار open-source developers نے mature repositories میں 246 حقیقی tasks کیے جن پر انہیں اوسطاً پانچ سال کا سابقہ تجربہ تھا؛ early-2025 AI tools کی اجازت پر completion time 19 فیصد بڑھا، حالانکہ شرکا نے بعد میں اندازہ لگایا کہ AI نے انہیں 20 فیصد تیز کیا تھا۔

یہ ہر agent یا developer کا عمومی نتیجہ نہیں۔ نمونہ چھوٹا تھا، developers اپنے repositories سے پہلے ہی بہت واقف تھے اور AI کی اجازت والی حالت میں زیادہ تر Cursor Pro کے ساتھ Claude 3.5 یا 3.7 Sonnet استعمال ہوا۔ اس کی افادیت ایک محدود مگر اہم فرق دکھانے میں ہے: پسندیدگی اور محسوس ہونے والی آسانی، measured completion time کا متبادل نہیں۔

Well-being پھر بھی الگ قابلِ قدر outcome ہے۔ اگر agent ذہنی تھکن کم کرے، exploration آسان بنائے یا غیر دلچسپ کام سنبھالے تو اسے employee-experience benefit کے طور پر رپورٹ کیا جا سکتا ہے، خواہ cycle time فوری طور پر نہ بدلے۔

پانچ metrics کا vendor-neutral scorecard

ایک composite score سے آغاز نہ کریں، کیونکہ مثبت مجموعی عدد quality regression یا reviewer پر منتقل ہونے والی محنت چھپا سکتا ہے۔ یہ پانچ dimensions الگ دکھائیں:

• Cycle time: کام ready ہونے سے tested change کے merge یا deployment تک elapsed time ناپیں۔ agent response time کو الگ diagnostic رکھیں، جبکہ queue time اور active work کو خلط نہ کریں۔
• Defect escape: merge کے بعد اس تبدیلی سے منسلک bugs، rollbacks، hotfixes اور production incidents درج کریں۔ task size اور risk کے بغیر خام defect count منصفانہ موازنہ نہیں دیتا۔
• Review time: reviewer کا active وقت، revision rounds اور author rework الگ ریکارڈ کریں۔ pull request کے کھلے رہنے کا پورا دورانیہ review effort نہیں، کیونکہ اس میں انتظار بھی شامل ہوتا ہے۔
• Comprehension: author یا اگلے maintainer سے change کی منطق، failure modes اور اہم dependencies بیان کروائیں۔ مختصر follow-up modification یہ دکھا سکتی ہے کہ code سمجھا گیا ہے؛ صرف tests کا pass ہونا ownership ثابت نہیں کرتا۔
• Developer satisfaction: مختصر باقاعدہ survey میں focus، frustration، perceived effort اور agent دوبارہ استعمال کرنے کی خواہش الگ پوچھیں۔ اس نتیجے کو measured speed کے ساتھ دکھائیں، اس کی جگہ نہیں۔

Completed tasks، accepted changes اور change size مفید diagnostic metrics ہیں، مگر lines of code کو کامیابی کا بنیادی ہدف بنانا deletion، simplification اور incident prevention جیسے قیمتی کام کم دکھاتا ہے۔ زیادہ code صرف یہ بتاتا ہے کہ output بدلا؛ یہ نہیں کہ قابلِ اعتماد value زیادہ تیزی سے پہنچی۔

ایسا pilot جو رفتار کے ساتھ پوشیدہ لاگت بھی دکھائے

Comparable task categories بنائیں: routine tests، چھوٹے bug fixes اور codebase-wide refactors کو ایک ہی گروپ میں نہ ملائیں۔ ہر category میں agent-assisted اور معمول کے workflow کے قابلِ موازنہ نمونے لیں، اور developer seniority، repository maturity اور task risk بھی درج کریں۔

1. Rollout سے پہلے انہی پانچ dimensions کی baseline جمع کریں اور metric definitions تحریری طور پر طے کریں۔
2. Pilot میں tool، model، permissions، استعمال کی شدت اور task category محفوظ کریں؛ صرف licence مختص ہونے کو adoption نہ سمجھیں۔
3. Median کے ساتھ slow cases اور outcome distribution دیکھیں، کیونکہ چند مشکل reviews یا escaped defects اوسط رفتار کا فائدہ ختم کر سکتے ہیں۔
4. نتائج dimension-wise پیش کریں: cycle time، quality، reviewer اور author کا وقت، comprehension اور satisfaction الگ رہیں۔

ROI میں licence یا inference cost کے ساتھ developer time، reviewer time، rework اور incidents کی لاگت شامل کریں۔ نتیجہ task-specific ہو سکتا ہے: agent routine tests میں مفید اور حساس legacy changes میں غیر مؤثر نکل سکتا ہے۔ فیصلہ کن سوال code کی مقدار نہیں، بلکہ یہ ہے کہ کیا ٹیم نے قابلِ اعتماد تبدیلی کم مجموعی محنت میں پہنچائی اور کیا اسے بعد میں سمجھنا اور سنبھالنا آسان رہا۔