तुम्हारी टीम पहले से कहीं ज़्यादा तेज़ कोड ship कर रही है। Sprint velocity charts ऊपर और दाईं तरफ जा रहे हैं। Pull requests — यानी review के लिए propose किए गए code changes के बंडल — ऐसे approve हो रहे हैं जैसे तेल लगी रेल। PM AI coding tools का credit दे रहा है। सब सिर हिला रहे हैं। Life is good.
बस bug tickets बढ़ रहे हैं। Reverts — जब तुम कोई change undo करते हो क्योंकि उसने कुछ तोड़ दिया — ज़्यादा हो रहे हैं। Backlog फूलता जा रहा है। कोई dots connect नहीं कर रहा क्योंकि dashboard कह रहा है कि तुम कमाल कर रहे हो।
30 मार्च 2026 को, Singapore Management University के researchers ने अब तक का सबसे बड़ा empirical study publish किया — AI-generated code quality पर। उन्होंने 6,275 GitHub repositories में 304,362 verified AI-authored commits (ऐसे code changes जो confirmed तौर पर AI tools से आए) का analysis किया, पाँच major tools पर: GitHub Copilot, Claude, Cursor, Gemini, और Devin। Timeframe: जनवरी 2024 से अक्टूबर 2025।
जो उन्हें मिला, वो तुम्हारी velocity celebration की हवा निकाल देगा।
उन repos में researchers ने 484,606 distinct issues identify कीं। उनमें से 89% code smells थीं — ऐसे patterns जो आज तो चलते हैं लेकिन कल सड़ जाएँगे। लगभग 6% runtime bugs थे। और 5.1% security vulnerabilities। Tool के हिसाब से 15% से 29% AI commits में कम से कम एक problem आई। Gemini सबसे ऊपर बैठा 28.7% पर। Copilot ने 17.3% score किया — बेहतर ज़रूर, लेकिन फिर भी हर छठा commit अपने साथ कचरा लेकर आ रहा है।
और असली तमाचा: 24.2% AI-introduced issues अभी भी ज़िंदा थीं code के latest version में। Security issues की survival rate 41.1% — किसी भी category में सबसे ज़्यादा। फरवरी 2026 तक, study ने 110,000 से ज़्यादा surviving issues track कीं जो AI ने वहाँ रखीं और किसी इंसान ने कभी साफ नहीं कीं। Researchers ने सीधे-सीधे कहा: AI assistants लगभग उतने ही code smells fix करते हैं जितने create करते हैं, लेकिन "bugs और security problems ज़्यादा create करते हैं बनिस्बत जितने resolve करते हैं।"
एक दिन पहले, 29 मार्च को, Exceeds AI ने benchmark data publish किया जो बताता है कि organization level पर ये क्यों matter करता है। उनके analysis के मुताबिक safe AI code ratio 25–40% है total output का — वो range जहाँ teams को genuine 10–15% productivity gains मिलते हैं बिना rework के दलदल में फँसे। Current global average? 41–42%। यानी line पहले ही पार हो चुकी है। 40% से ऊपर AI code वाली teams में 20–25% ज़्यादा rework rates दिखे। और ये रहा वो productivity paradox जो हर engineering manager की नींद उड़ा दे: developers को लगता है कि 20% faster हैं लेकिन review overhead, debugging, और fixes गिनो तो actually 19% slower निकलते हैं।
Perceived speed ऊपर जाती है। Actual throughput नीचे आता है। Dashboard झूठ बोलता है।
6 अप्रैल को, University of Victoria की researcher Margaret-Anne Storey ने एक नए paper में इस problem को नाम दिया। वो इसे "Cognitive Debt" कहती हैं — टीम की shared understanding का धीरे-धीरे घुलना। जब AI developers की समझने की speed से तेज़ code generate करता है, तो टीम अपने ही system को safely modify करने की capability खो देती है। ये सिर्फ technical debt नहीं है (गंदा code जो "बाद में" fix करोगे)। ये knowledge debt है — कोई भी पूरी तरह नहीं समझता कि codebase करता क्या है।
इसका मतलब ये नहीं कि AI coding tools बंद कर दो। Productivity gains real हैं, और जिन्न वापस बोतल में नहीं जा रहा। लेकिन तुम्हारी टीम को जो सवाल पूछना चाहिए वो ये नहीं है कि "AI हमारे लिए कितना code लिख सकता है?" बल्कि ये है कि "हमारी review process और test coverage कितना AI-generated code झेल सकती है बिना गाड़ी के पहिए उखड़े?"
Velocity हमेशा से एक vanity metric था — एक नंबर जो impressive लगता है लेकिन ये नहीं बताता कि तुम कुछ solid बना रहे हो या हवा में महल। अब, बिना quality denominator के, ये एक खतरनाक metric है। तुम्हारा sprint chart ऊपर और दाईं तरफ है। तुम्हारा bug count भी। Same chart। अलग कहानी।