AI-सहायित कोडिंग के बारे में गलत होने के बारह तरीके

• AI-सहायित कोडिंग का मूल्य code lines, tickets, या satisfaction जैसे आसान numbers में समेटना मुश्किल है, और मूल्यांकन का तरीका निष्कर्षों को विकृत कर सकता है
• code lines तथा commit, Pull Request, और ticket counts केवल गतिविधि मापते हैं; जैसे ही वे लक्ष्य बन जाते हैं, उन्हें आसानी से manipulate किया जा सकता है और वे quality नहीं बता पाते
• acceptance rate और adoption rate सिर्फ यह संकेत हैं कि सुझाव देखने में ठीक लगे या tool deploy हुआ, लेकिन वे correctness, security, या maintainability की गारंटी नहीं देते
• toy tasks, बिना control group वाले before-and-after comparisons, voluntary user comparisons, और weak baselines के कारण LLM effects और selection bias को अलग करना कठिन हो जाता है
• productivity का आकलन करने के लिए review, debugging, security, technical debt, team bottlenecks, और long-term changes सहित system-level metrics की जरूरत होती है

---

मूल्यांकन का विषय और पूर्वधारणाएँ

• AI-सहायित coding tools के subscription cost के मुकाबले उनके मूल्य को साबित करने की कोशिश करते समय generated code lines, completed tickets, और developer satisfaction surveys — तीनों अलग-अलग तरीकों से गलत निष्कर्ष दे सकते हैं
• मुख्य मुद्दा LLM-सहायित coding के मूल्य पर नहीं, बल्कि इस बात पर है कि उसके प्रभाव का मूल्यांकन करने का तरीका कितनी आसानी से भटक सकता है
• यही आलोचना थोड़े बदलाव के साथ agile development, test-driven development, और अन्य software development practices पर किए गए दावों पर भी लागू की जा सकती है
• इससे यह निष्कर्ष निकलता है कि अगर software engineering ने human sciences के research methods को ठीक से अपनाया होता, तो वह ऐसे phenomena के अध्ययन में कहीं आगे होती

गलत productivity metrics

• generated code lines गिनना

  • code lines लंबे समय से productivity के proxy metric के रूप में उपयोग होते रहे हैं, क्योंकि productivity को सीधे मापना कठिन है
  • LLM ज्यादा code बना सकते हैं, लेकिन इससे बेहतर परिणाम की गारंटी नहीं मिलती
  • LLM अपनाने के बाद अगर किसी team में प्रति developer code lines 40% बढ़ गईं, तो हो सकता है उसने productivity नहीं बल्कि verbosity मापी हो
  • उलझे हुए 2000 lines के logic को साफ-सुथरी 200 lines से बदलना, code-line metric में नुकसान जैसा दिखेगा
  • ज्यादा code का मतलब है ज्यादा पढ़ना, maintain करना, और debug करना; AI से पैदा होने वाला भविष्य का बोझ line counts में दिखाई नहीं देता

• commit, Pull Request, और tickets गिनना

  • 2023 में McKinsey ने individual developer productivity को commits, Pull Requests, और code reviews जैसी activity counts से मापने का सुझाव दिया
  • Goodhart’s law के अनुसार, जब कोई measure लक्ष्य बन जाता है, तो वह अच्छा measure नहीं रह जाता
  • अगर commit count track किया जाए, तो developers छोटे और अधिक commits करेंगे; अगर ticket count track किया जाए, तो tickets को छोटे हिस्सों में तोड़ा जाएगा
  • numbers बेहतर दिख सकते हैं, जबकि underlying work में कोई सुधार न हुआ हो
  • activity output नहीं है, और output भी अपने-आप value नहीं बन जाता

• suggestion acceptance rate को quality signal मानना

  • LLM coding assistants की high suggestion acceptance rate को अक्सर इस बात के प्रमाण के रूप में पेश किया जाता है कि tool उपयोगी है
  • acceptance rate केवल यह मापता है कि generated code developer को इतना plausible लगा कि उसने Tab दबा दिया; यह correctness, security, या maintainability नहीं मापता
  • समय के दबाव में developers ज्यादा suggestions स्वीकार करते हैं, जिनमें unsafe suggestions भी शामिल हो सकती हैं
  • 400 developers पर की गई एक corporate study में average acceptance rate 33% और high developer satisfaction मिला, लेकिन accepted code की correctness या security को track नहीं किया गया
  • जो metric plausible दिखने वाली चीज़ को reward करे, वह ज़रूरी नहीं कि वास्तव में अच्छी चीज़ को reward करे

• adoption rate को success metric मानना

  • “पूरे engineering organization में AI tool adoption rate 90% हासिल कर लिया” कहना purchase/deployment success है, productivity success नहीं
  • adoption rate केवल यह मापता है कि tool install हुआ और खोला गया या नहीं; यह नहीं बताता कि suggestions उपयोगी थीं, developers ने उन्हें बिना सोचे स्वीकार किया, या accepted suggestions सही थीं
  • high adoption rate और low suggestion quality का मेल developers को लाभ देने के बजाय tool संभालने में समय खर्च करा सकता है
  • IBM की enterprise AI coding assistant study में tool ने अक्सर net productivity gains दिए, लेकिन यह लाभ सभी users में समान नहीं था
  • adoption rate, benefit की तुलना में मापना आसान है, और ठीक इसी कारण इसे रिपोर्ट करना भी आसान होता है

experimental design की त्रुटियाँ

• artificial tasks का समय नापना

  • व्यापक रूप से उद्धृत GitHub Copilot study में users ने non-users की तुलना में task 55% तेजी से पूरा किया
  • task यह था कि JavaScript में scratch से एक HTTP server implement किया जाए; समय सीमा 90 मिनट थी, और developers की उस दिन कोई दूसरी ज़िम्मेदारी नहीं थी
  • वास्तविक software development में ऐसे large codebases को समझना शामिल है जिन्हें आपने खुद नहीं लिखा, ambiguous ticket requirements को समझना, teammates के साथ coordination, और meetings
  • greenfield toy tasks की speed, वास्तविक काम की speed की भविष्यवाणी नहीं करती
  • skilled open source developers पर किए गए एक randomized controlled trial में, प्रतिभागियों की अपेक्षाओं के विपरीत, AI tool access देने पर task completion time 19% बढ़ गया

• बिना control group वाले before-and-after comparisons

  • अगर जनवरी में LLM का उपयोग शुरू हुआ और जून तक Pull Requests तेज़ी से deploy होने लगे, तो ऐसा लग सकता है कि tool ने असर किया
  • लेकिन अगर उसी अवधि में 12 engineers hire किए गए, CI pipeline refactor हुई, और cloud provider बदला गया, तो कारण अलग करना संभव नहीं होता
  • अगर ऐसा कोई group ही न हो जिसने tool adopt न किया हो, तो LLM के प्रभाव और साथ-साथ हुए अन्य परिवर्तनों के प्रभाव को अलग करना कठिन है
  • internal validity के लिए एक भरोसेमंद counterfactual चाहिए, जिससे पता चल सके कि tool न होने पर क्या होता

• users और non-users की तुलना

  • जो developers LLM का उपयोग चुनते हैं और जो नहीं चुनते, उनकी तुलना करना दो conditions की नहीं बल्कि दो अलग समूहों की तुलना करना है
  • early adopters में late adopters या non-adopters की तुलना में प्रयोग करने की इच्छा, नए tools से परिचय, और पहले से high performance होने की संभावना अधिक होती है
  • selection bias के कारण देखा गया अंतर tool की नहीं बल्कि लोगों की विशेषता हो सकता है
  • यह तरीका लागू करने में सबसे सस्ता है, इसलिए industry AI productivity reports में यह एक आम design flaw बन गया है
  • एक बड़े IT organization में Copilot उपयोग को 2 साल तक track करने वाली longitudinal study में पाया गया कि tool adoption से पहले भी users, non-users की तुलना में लगातार अधिक active थे

• AI की तुलना ‘कुछ भी नहीं’ से करना

  • अगर AI-सहायित developers की तुलना ऐसे control group से की जाए जो कोई tool ही नहीं इस्तेमाल करता, तो baseline अवास्तविक हो जाती है
  • LLM assistant न होने पर भी developers documentation, coworkers, और खुद सोचने-समझने में समय लगाते हैं
  • असली सवाल यह है कि LLM tool उन alternatives से बेहतर है या नहीं जो developers के पास पहले से मौजूद हैं; लेकिन ऐसी comparisons बहुत कम होती हैं
  • weak baseline चुनने पर कोई भी tool अच्छा दिख सकता है, लेकिन इसका मतलब वास्तविक उपयोगिता नहीं होता

measurement scope में छूटे हुए हिस्से

• सिर्फ आसान आधा हिस्सा मापना

  • LLM code generation को तेज़ बनाते हैं, और यह हिस्सा मापना आसान है
  • कठिन आधा हिस्सा है: LLM-generated code की review time, confidently गलत suggestions के कारण खोया debugging time, plausible लेकिन unsafe code से बनी security vulnerabilities, और surrounding design को नज़रअंदाज़ कर दिए गए ad hoc solutions से पैदा technical debt
  • GitHub Copilot code study में generated code के एक महत्वपूर्ण हिस्से में security vulnerabilities थीं, और समय के दबाव में developers ने unsafe suggestions को अधिक दर से स्वीकार किया
  • 2025 में 5 प्रमुख LLMs के मूल्यांकन में कोई भी model industry security standards को पूरा करने वाला web application code नहीं बना सका
  • AI द्वारा लिखे गए 300,000 से अधिक commits के large-scale analysis में पाया गया कि 15% से अधिक ने कम-से-कम एक quality issue introduce किया, और उनमें से लगभग एक-चौथाई लंबे समय तक codebase में बने रहे
  • अगर आप केवल बढ़े हुए input को मापें और साथ बढ़ी हुई लागत को नज़रअंदाज़ करें, तो वह measurement नहीं, marketing है

• व्यक्ति नहीं, system को मापना चाहिए

  • individual coding speed सबसे आसान माप है, इसलिए अक्सर वही मापी जाती है
  • अगर AI tool developers को code 30% तेजी से लिखने दे, लेकिन team का ticket-to-production lead time न बदले, तो bottleneck code writing नहीं था
  • generated code बढ़ेगा तो review के लिए code भी बढ़ेगा; अगर AI केवल code quantity बढ़ाए और review capacity न बढ़ाए, तो cycle time खराब हो सकता है
  • professional developers पर empirical research में पाया गया कि AI tools ने less-experienced contributors का output बढ़ाया, लेकिन senior developers के लिए AI-generated code के कारण code review load 6.5% बढ़ा और उनकी productivity 19% घटी
  • pipeline के सिर्फ एक stage को optimize करके बाकी को नज़रअंदाज़ करना, productivity research नहीं बल्कि systems thinking की विफलता है

समय के साथ प्रभाव का विकृतिकरण

• developers से पूछना कि productivity बढ़ी या नहीं

  • “87% developers को लगता है कि AI tools से वे अधिक productive हैं” जैसे survey results को अक्सर tool के काम करने के प्रमाण के रूप में उद्धृत किया जाता है
  • self-reporting तीन कारणों से systematic misunderstanding पैदा कर सकती है
  • Hawthorne effect के कारण लोग तब अलग तरह से काम करते हैं जब उन्हें पता होता है कि उन्हें observe या evaluate किया जा रहा है
  • नया tool, नया होने के कारण, novelty effect पैदा करता है जिससे वह तेज़ महसूस होता है; यह एहसास आम तौर पर कुछ हफ्तों में गायब हो जाता है
  • social desirability bias के कारण respondents अक्सर वही जवाब देते हैं जो उन्हें लगता है कि survey सुनना चाहती है, खासकर जब management ने tool चुना हो

• केवल novelty-effect अवधि में मापना

  • अगर 4 हफ्ते की study productivity gain दिखाती है, तो उसने सिर्फ 4 हफ्तों की productivity gain ही दिखाई है
  • शुरुआती अवधि में developers नए tool के प्रति अधिक engaged रहते हैं, इसलिए observed performance long-term baseline की तुलना में inflated हो सकती है
  • वास्तव में महत्वपूर्ण effects कुछ हफ्तों में नहीं, बल्कि महीनों में सामने आते हैं
  • AI को सौंपे गए कामों में skill degradation, गलत suggestions से जमा technical debt, और team collaboration patterns में बदलाव — इन सबके लिए long-term observation चाहिए
  • short-term gains detect करने के लिए design की गई studies यह नहीं बतातीं कि study खत्म होने के बाद क्या होता है
  • Cursor अपनाने वाले 807 open source repositories के analysis में adoption के बाद development speed में बड़ा लेकिन अस्थायी उछाल दिखा, जबकि code complexity और static analysis warnings में महत्वपूर्ण और लगातार वृद्धि हुई

बेहतर व्याख्या के लिए निष्कर्ष

• productivity measurement को किसी एक number या आसान proxy metric में समेटना कठिन है
• LLM-सहायित coding के प्रभाव को समझने के लिए केवल code-writing speed नहीं, बल्कि review, debugging, security, maintainability, technical debt, team bottlenecks, और long-term changes को भी साथ देखना होगा
• control groups, realistic baselines, selection bias control, long-term observation, और system-level metrics के बिना AI tools के प्रभाव और अन्य परिवर्तनों के प्रभाव को अलग करना कठिन है
• जो values मापना आसान हैं, उन्हें रिपोर्ट करना भी आसान है; लेकिन आसान values, महत्वपूर्ण values की जगह नहीं ले सकतीं
• software development practices का मूल्यांकन करने के लिए human sciences के research methods को अधिक गंभीरता से अपनाने की आवश्यकता है

उद्धृत प्रमुख स्रोत

• Kent Beck, “Measuring Developer Productivity: Real-World Examples”: developer productivity measurement के व्यावहारिक उदाहरण
• Catherine M. Hicks, Carol Lee, Kristen Foster-Marks, “The New Developer: AI Skill Threat, Identity Change & Developer Thriving in the Transition to AI-Assisted Software Development”: AI-सहायित development transition में skill threat, identity change, और developer thriving पर चर्चा
• McKinsey, “Yes, You Can Measure Software Developer Productivity”: commits, Pull Requests, और code reviews जैसी activity-based productivity measurement का प्रस्ताव
• Peng2023: वह study जिसमें GitHub Copilot users ने HTTP server implementation task 55% तेजी से पूरा किया
• Becker2025: वह study जिसमें skilled open source developers को AI tool access देने पर task completion time 19% बढ़ा
• Pearce2022: GitHub Copilot-generated code की security vulnerabilities और time pressure में unsafe suggestions की बढ़ी acceptance का मूल्यांकन करने वाली study
• He2026: Cursor adoption के बाद short-term development speed बढ़ने और long-term code complexity तथा static analysis warnings बढ़ने की पुष्टि करने वाली study
• Xu2025: वह study जो दिखाती है कि AI-सहायित programming अनुभवी developers के लिए review और maintenance burden बढ़ाकर productivity घटा सकती है

[GN⁺]

Lobste.rs प्रतिक्रियाएँ

• लेखक Software Carpentry के संस्थापकों में से एक हैं, इसलिए वे LLM आने से बहुत पहले से ही software productivity measurement को बेहतर ढंग से करने के तरीकों पर सोचते रहे हैं
  उद्धृत METR शोध आम तौर पर दिखने वाले कारणों से कहीं अधिक दिलचस्प है। बहुत से लोगों के लिए हेडलाइन यह थी कि “AI ने लोगों को और धीमा बना दिया”, और इसका जवाब इस तरह दिया जा सकता है कि 2025-स्टाइल LLM अभी भी लगातार बेहतर हो रहे हैं
  लेकिन उससे भी अधिक दिलचस्प नतीजा यह है कि बाद में लोगों ने जो अनुमान लगाए, वे वास्तविक परिणामों की दिशा तक से मेल नहीं खाते थे। इसमें शायद ऐसा तत्व है जिसे ज़्यादातर कंपनियाँ नज़रअंदाज़ करती हैं, और जो किसी भी measurement को मूल रूप से कठिन बना देता है
  इस धुंधले एहसास पर भी भरोसा नहीं किया जा सकता कि कोई टूल लोगों को अधिक productive बनाता है। लोग खुद नहीं जानते
  इसके बाद आया follow-up study चयन पक्षपात के कारण व्यावहारिक रूप से विफल रहा

  The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
  डेवलपर्स का AI के बिना काम करने से इनकार करना इस बात का संकेत हो सकता है कि टूल अच्छी तरह काम करता है, या फिर इसका कि वे टूल पर धीरे-धीरे इतने निर्भर हो गए हैं कि अधिक कठिन काम करने की उनकी क्षमता पूरी तरह क्षीण हो गई है

  • मेरी परिकल्पना है कि लोग उन हिस्सों के लिए LLM पर ज़्यादा निर्भर होते हैं जिन्हें वे वास्तव में करना नहीं चाहते, और जब कोई काम करना पसंद न हो तो समय हमेशा बहुत धीमा लगता है

• यह बात कि “नया टूल नया होने की वजह से तेज़ महसूस होता है, और वह एहसास आम तौर पर कुछ हफ्तों में गायब हो जाता है” मुझे उलटी लगती है
  नया टूल मुझे हमेशा धीमा करता है, क्योंकि मैं उससे परिचित नहीं होता। हाँ, उसमें और तेज़ होने की potential ज़रूर दिखती है, लेकिन मैं अभी उसे प्रभावी ढंग से इस्तेमाल नहीं कर पाता

  • इससे जुड़ा एक और असर भी है। खासकर जो लोग स्वेच्छा से नया टूल आज़माते हैं, वे अक्सर इतने उत्साही होते हैं कि उसकी कमियों को पूरा करने के लिए काम के घंटों के बाहर भी ज़्यादा काम करते हैं
    कुछ समय तक यह प्रभावशाली दिखता है, लेकिन आखिरकार लोग अपने सामान्य कामकाजी तरीके पर लौट आते हैं और यह असर स्वाभाविक रूप से गायब हो जाता है

• Measurement कठिन है। एक अर्थ में AI-assisted coding को मापने की कोशिश करना ही गलती हो सकती है
  यह साफ़ है कि कुछ काम इससे तेज़ हो जाते हैं, और संभवतः ऐसे तरीके भी हैं जिनसे इसका इस्तेमाल करके काम को और तेज़ बनाया जा सकता है
  ज़्यादा महत्वपूर्ण सवाल यह है कि वे तरीके क्या हैं, और उस प्रक्रिया में हम क्या खोते हैं

  • Productivity और काम की गति में बढ़ोतरी एक ही बात नहीं हैं। कोई काम तेज़ हो जाने पर भी, अगर वही bottleneck नहीं था या उस speedup की कोई लागत है, तो productivity पर उसका सकारात्मक असर ज़रूरी नहीं
    मूल लेख इसे “आसान आधे हिस्से को ही मापना” कहकर उठाता है

• इस सवाल पर कि “अगर अगले हफ्ते आपका मैनेजर आपसे कहे कि कंपनी ने जिस AI coding tool का subscription लिया है, वह अपनी कीमत वसूल कर रहा है, तो क्या आप generated code lines मापेंगे या closed tickets की संख्या?”, Claude पहले से ही billing records में code lines, acceptance rate और token usage मापता है
  closed tickets की संख्या टीम की velocity होगी, लेकिन AI output उसमें सिर्फ एक तत्व है, और sprint velocity को Jira मापता है
  वैसे भी यह सवाल इस आधार पर आसानी से manipulate किया जा सकता है कि आप मानते क्या हैं कि मैनेजर किस output को देखना चाहता है, और बहुत संभव है कि ऐसा पहले से हो भी रहा हो

• मुझे लगता है कि लेखक एक बहुत महत्वपूर्ण सवाल छोड़ देता है। वह है, “AI के उपयोग से किस तरह का नुकसान होता है?”
  मुझे लगता है कि यह सवाल किसी भी दूसरे सवाल से अधिक बुनियादी है। नुकसान को मापना कहीं आसान है। एक Git forge चलाइए और देखिए कि crawler किस तरह खून की गंध सूँघते शार्क की तरह टूट पड़ते हैं
  scraper द्वारा पूरे इंटरनेट को DDoS करना एक मापने योग्य समस्या है, और जो लोग self-hosting करते हैं उनके लिए यह रोज़मर्रा की वास्तविकता है
  AI के जिन तथाकथित फ़ायदों को हम ठीक से माप भी नहीं पाते, क्या वे crawler द्वारा किए जा रहे बेहद वास्तविक नुकसान को सहने लायक हैं?
  और अगर हम crawler चलाने और उन requests को संभालने में लगने वाली ऊर्जा, training cost, inference cost, और लगातार बड़े होते data centers की ज़रूरत को भी जोड़ दें तो?
  मुझे लगता है कि यह पूछना कहीं अधिक महत्वपूर्ण है कि AI के वे तथाकथित फ़ायदे क्या वास्तव में इन सब कुर्बानियों के लायक हैं

  • इस तरह के “हमें X के बारे में बात करनी चाहिए” वाले मुद्दों में जो बात हमेशा खटकती है, वह यह है कि पारिस्थितिक नुकसान पर लिखे लेखों में मैंने ठीक उलटा तर्क भी देखा है
    जैसे, “अगर ये ऊर्जा का उपयोग न भी करें, तब भी ये खराब code बनाते हैं, इसलिए वही ज़्यादा महत्वपूर्ण बात है”, या “coding की बात क्यों कर रहे हैं, असली नुकसान तो surveillance में इसका इस्तेमाल है” — और बहस इसी तरह बार-बार खिसकती रहती है