AI डेवलपमेंट की रफ़्तार बढ़ाता है, लेकिन बग 1.7 गुना अधिक होते हैं

• ओपन सोर्स 470 PR के विश्लेषण के अनुसार, AI द्वारा लिखे गए कोड में मानव-लिखित कोड की तुलना में औसतन 1.7 गुना अधिक समस्याएँ पाई गईं
• लॉजिक एरर, पठनीयता में गिरावट, और सुरक्षा कमजोरियाँ जैसी प्रमुख खामियाँ AI कोड में स्पष्ट रूप से अधिक थीं, और खासकर पठनीयता से जुड़ी समस्याएँ 3 गुना से अधिक बढ़ीं
• AI कोड में एरर हैंडलिंग की कमी, concurrency errors, और naming mismatch बार-बार देखे गए, जिससे review का बोझ और operational risk बढ़ा
• इसके कारणों में business logic की अपर्याप्त समझ, सतही शुद्धता पर ज़ोर, और कम-दक्ष patterns की पसंद शामिल बताए गए
• रिपोर्ट ने AI code quality management system को मज़बूत करने और AI-aware code review, security, तथा testing processes अपनाने की ज़रूरत पर ज़ोर दिया

---

AI vs Human Code Generation Report का अवलोकन

• CodeRabbit ने AI और मानव द्वारा लिखे गए कोड की गुणवत्ता में अंतर का अनुभवजन्य विश्लेषण करने के लिए यह अध्ययन किया
  • 470 ओपन सोर्स GitHub PR की जाँच की गई, जिनमें 320 AI co-authored थे और 150 केवल मानव द्वारा लिखे गए थे
  • सभी परिणामों को प्रति 100 PR पर issues की संख्या के रूप में normalize किया गया, और statistical ratio comparison के ज़रिए समस्या-प्रकार के अनुसार occurrence frequency मापी गई
• निष्कर्षतः, AI productivity बढ़ाता है, लेकिन error rate भी साथ में बढ़ाता है
  • AI-लिखित PR में औसतन 10.83 समस्याएँ थीं, जबकि मानव-लिखित PR में 6.45
  • खासकर उच्च-गंभीरता वाली त्रुटियाँ AI कोड में अधिक बार मिलीं

अध्ययन की सीमाएँ

• सीधे यह सत्यापित नहीं किया जा सका कि कोई PR AI द्वारा लिखा गया था या नहीं, इसलिए AI co-authored signal (co-authored-by) वाले PR को AI-लिखित श्रेणी में रखा गया
  • जिन PR में यह signal नहीं था, उन्हें मानव-लिखित माना गया, लेकिन पूरी तरह सटीक विभाजन संभव नहीं था
• इस सीमा के बावजूद, दोनों समूहों के बीच समस्या-पैटर्न का सांख्यिकीय अंतर महत्वपूर्ण रूप से दिखाई दिया
• पूरी methodology रिपोर्ट के अंत में प्रकाशित की गई है

10 प्रमुख निष्कर्ष

• सभी तरह की त्रुटियाँ केवल AI में ही नहीं पाई गईं, लेकिन अधिकांश श्रेणियों में AI कोड की error rate अधिक थी
  • मानव और AI दोनों एक जैसी गलतियाँ करते हैं, लेकिन AI उन्हें अधिक बार और बड़े पैमाने पर करता है

• 1. कुल issues की संख्या 1.7 गुना बढ़ी

  • AI-लिखित PR में औसतन 10.83 समस्याएँ, जबकि मानव-लिखित PR में 6.45
  • बहुत अधिक issues वाले PR (outliers) AI कोड में कहीं अधिक थे, जिससे review का बोझ बढ़ा

• 2. उच्च-गंभीरता वाली त्रुटियाँ बढ़ीं

  • major और critical issues 1.4~1.7 गुना अधिक थे

• 3. लॉजिक और correctness से जुड़ी समस्याएँ 75% बढ़ीं

  • इसमें business logic errors, गलत dependencies, control flow defects, और configuration errors शामिल थे
  • इन्हें ठीक करने की लागत अधिक होती है और production incidents तक पहुँचने की संभावना भी अधिक रहती है

• 4. पठनीयता की समस्याएँ 3 गुना से अधिक बढ़ीं

  • naming conventions, code structure, और expression consistency स्पष्ट रूप से कमजोर पाए गए
  • कोड ऊपर से व्यवस्थित दिखे, फिर भी local patterns के उल्लंघन बार-बार देखे गए

• 5. एरर हैंडलिंग और exception paths की कमी 2 गुना बढ़ी

  • null checks, guard conditions, और exception handling logic अक्सर गायब थे
  • यह प्रकार सीधे service outages से जुड़ सकता है

• 6. सुरक्षा समस्याएँ अधिकतम 2.74 गुना बढ़ीं

  • password handling में त्रुटियाँ और object reference vulnerabilities इसके प्रतिनिधि उदाहरण थे
  • ये पूरी तरह नई कमजोरियाँ नहीं थीं, लेकिन अधिकांश security defects का विस्तार हुआ

• 7. performance degradation की समस्याएँ कम थीं, लेकिन AI में अधिक केंद्रित

  • अत्यधिक I/O calls लगभग 8 गुना अधिक थीं
  • AI clarity-केंद्रित code को प्राथमिकता देता है, जिससे efficiency घटती है

• 8. concurrency और dependency errors लगभग 2 गुना बढ़े

  • क्रम संबंधी त्रुटियाँ, गलत dependency flow, और concurrency control का दुरुपयोग बार-बार देखा गया

• 9. formatting समस्याएँ 2.66 गुना बढ़ीं

  • indentation, spacing, और style mismatch जैसी औपचारिक त्रुटियाँ अधिक थीं
  • auto formatter और linter इस्तेमाल करने पर भी AI कोड में noise बढ़ा

• 10. naming inconsistency 2 गुना बढ़ी

  • अस्पष्ट नाम, शब्दावली में असंगति, और generic identifiers अधिक होने से reviewer पर संज्ञानात्मक बोझ बढ़ा

समस्याओं के कारण

• AI में business logic की समझ सीमित होती है
  • यह सांख्यिकीय patterns के आधार पर कोड बनाता है, इसलिए system rules छूट सकते हैं
• सतही शुद्धता पर केंद्रित generation
  • कोड ऊपर से सही लगता है, लेकिन control flow protection या dependency order errors मौजूद हो सकते हैं
• repository-विशिष्ट conventions का पालन न करना
  • naming, structure, और format rules सामान्यीकृत रूप में विकृत हो जाते हैं
• security patterns का कमजोर होना
  • स्पष्ट निर्देश न होने पर पुराने या कमजोर code patterns दोहराए जाते हैं
• efficiency से अधिक simplicity को प्राथमिकता
  • repeated I/O और non-optimized structures के उपयोग की प्रवृत्ति

engineering teams के लिए प्रतिक्रिया उपाय

• AI अपनाने का मतलब केवल speed बढ़ाना नहीं, बल्कि quality assurance system का पुनः डिज़ाइन भी है

• 1. AI को पर्याप्त context दें

  • business rules, configuration patterns, और architecture constraints स्पष्ट करने से त्रुटियाँ कम हो सकती हैं
  • prompt में repository-विशिष्ट guidelines और schemas शामिल करें

• 2. policy-आधारित code style लागू करें

  • CI formatter, linter, और style guide से पठनीयता संबंधी समस्याएँ रोकी जा सकती हैं

• 3. correctness safeguards जोड़ें

  • tests अनिवार्य करें, null/type checks, exception handling का standardization, और guard conditions को स्पष्ट करें

• 4. security defaults मज़बूत करें

  • credentials का केंद्रीकरण, password के direct usage पर रोक, और automatic SAST तथा security linter execution

• 5. efficient patterns को बढ़ावा दें

  • I/O batching, उपयुक्त data structure selection, और performance hints प्रदान करें

• 6. AI-aware PR checklist अपनाएँ

  • review के दौरान निम्नलिखित बिंदु जाँचें:
    • एरर paths कवर हुए हैं या नहीं
    • concurrency control सही है या नहीं
    • configuration values validate किए गए हैं या नहीं
    • password handling का तरीका सही है या नहीं

• 7. AI code review automation लागू करें

  • review fatigue बढ़ने से bug छूटने से बचने के लिए AI code review tool (CodeRabbit) के उपयोग का सुझाव
    • review quality का standardization और जाँच समय व संज्ञानात्मक बोझ में कमी

निष्कर्ष

• AI coding tools शक्तिशाली accelerator हैं, लेकिन बिना safeguards के acceleration जोखिमपूर्ण है
• AI-जनित कोड में variability, error rate, और severity तीनों अधिक हैं
• AI को replacement नहीं, बल्कि augmentation tool की तरह इस्तेमाल करते हुए quality, security, और testing systems को मज़बूत करना आवश्यक है
• speed और quality दोनों सुनिश्चित करने के लिए जानबूझकर की गई engineering management की ज़रूरत है
• AI code review tools का उपयोग गुणवत्ता बनाए रखने में व्यावहारिक मदद कर सकता है

[cshj55]

1.7 गुना है तो जितना सोचा था उससे कम ही है...?

[ds2ilz]

AI के साथ coding करते हुए मुझे भी काफ़ी हद तक ऐसे ही अनुभव हुए हैं। व्यवस्थित किए गए कारणों को देखें तो लगता है कि coding करते समय इंसान जिन patterns, naming conventions, edge case handling, guard conditions वगैरह को बुनियादी ज्ञान की तरह साथ लेकर चलता है, वे context में पर्याप्त रूप से दिए नहीं जाते, शायद इसलिए ऐसा होता है।
इसलिए मैंने ऐसे नियमों को अलग से इकट्ठा करके एक rule file बना रखी है, और coding करते समय मैं निर्देश देता हूँ कि उस file को ज़रूर पढ़कर उसका पालन किया जाए। फिर सिर्फ़ उस rule file को बेहतर करने से ही नतीजे काफ़ी अच्छे हो जाते हैं।

[princox]

मुझे डर है कि कहीं कोई यह राय न दे दे, "इतना ढेर सारा बनाया है, तो 1.7 गुना तो लगभग मुफ्त ही हुआ न..."

[kimjoin2]

लेकिन तेज़ तो था, है ना? वही meme याद आ रहा है lol

[GN⁺]

Hacker News की राय

• मुझे लगता है कि AI से पहले भी ‘vibe coding’ मौजूद थी

  • मैंने बहुत से डेवलपर्स को यह सोचे बिना हर जगह null check चिपकाते देखा है कि object null क्यों है
  • ऐसा तरीका कुछ क्षेत्रों में काम का हो सकता है, लेकिन अगर पूरा सिस्टम ऐसे बना हो तो maintenance एक दुःस्वप्न बन जाता है
  • AI-आधारित vibe coding उस स्टाइल को तेज़ करती लगती है जिसमें “यह क्यों काम कर रहा है” समझे बिना बस स्क्रीन पर मनचाहा नतीजा देख लिया जाता है
  • मैंने पहले ऐसी कंपनी में काम किया है जहाँ null check exceptions को निगल जाते थे, इसलिए errors चुपचाप दब जाते थे
    • टीम खुद को बहुत स्मार्ट समझती थी, लेकिन असल में सिस्टम StackOverflow से copy-paste किए गए code और पुराने MVP structure पर चल रहा था
    • ऐसे माहौल में independent thinking लगभग असंभव थी
    • फिर भी Claude Code जैसे tools अच्छी तरह डिज़ाइन किए गए codebase पर productivity को काफ़ी बढ़ा देते हैं
  • StackOverflow से copy-paste करके “चल रहा है तो ठीक है” पर रुक जाना ही vibe coding है
    • AI ने बस उस process को automate किया है
  • “जो देखना चाहते हो वही देखना” नहीं, बल्कि “कुछ भी स्क्रीन पर दिखा देना” ज़्यादा सही अभिव्यक्ति है
    • यूँ ही जोड़ दिया गया null-check बाद में सूक्ष्म data errors पैदा करता है, जिनकी जड़ तक पहुँचना बहुत मुश्किल होता है
  • मैं भी सहमत हूँ, लेकिन vibe coding ने StackOverflow-निर्भर डेवलपर्स को और तेज़ बना दिया है
    • ऐसे डेवलपर्स की संख्या बढ़ रही है जो खुद problem solve नहीं करते
    • ऊपर से पहले से भी reliability कम हो गई है
  • AI इस्तेमाल करते समय सबसे निराशाजनक बात यह है कि यह हर language में औसत दर्जे की code style को ज्यों का त्यों follow करती है
    • मैं उस सिद्धांत पर चलता हूँ कि “गलत data बनाओ ही मत, फिर उसे handle भी नहीं करना पड़ेगा”, लेकिन AI बार-बार इसे तोड़ती है
    • यह type definitions या invariant बनाए रखने पर लगभग ध्यान नहीं देती और बस strings और integers से काम चलाना चाहती है
    • इसलिए मैं AI को tab-complete आधारित तरीके से सीमित इस्तेमाल करता हूँ और structural errors खुद ठीक करता हूँ
    • सुधार के बाद AI भी सही दिशा में चलने लगती है, इसलिए अगर IDE और LSP integration बेहतर हो जाए तो यह बहुत ज़्यादा उपयोगी हो सकती है

• vibe coding की आलोचना सही है, लेकिन सच यह भी है कि AI से पहले भी code quality बहुत खराब थी

  • ज़्यादातर code धीमे deploy होता था और उसकी quality भी कमज़ोर होती थी
  • अगर तेज़ deployment से ideas को validate करने की रफ़्तार बढ़ती है, तो कुछ लोग मानते हैं कि कुछ errors स्वीकार किए जा सकते हैं
  • आजकल management अक्सर पूछती है, “इतने छोटे feature में कई महीने क्यों लग रहे हैं?”
  • लेकिन “छोटे feature में इतना समय क्यों लगता है” इसका कारण algorithms नहीं बल्कि infrastructure और collaboration structure हैं
    • AI ऐसे बुनियादी मसले हल नहीं कर सकती
  • maintenance cost और complexity समय के साथ चक्रवृद्धि ब्याज की तरह जमा होती जाती हैं
    • short-term projects में vibe coding ठीक हो सकती है, लेकिन long-term systems के लिए यह अनुपयुक्त है
  • मेरे हिसाब से intentional developers और vibe developers के बीच संतुलन ज़रूरी है
    • AI vibe वाली दिशा को ज़रूरत से ज़्यादा मज़बूत करके सिस्टम का संतुलन बिगाड़ देती है
  • code quality से भी ज़्यादा महत्वपूर्ण है business problem और technical solution की साझा समझ
    • quality कम हो तब भी उसके कारण और trade-offs को साफ़-साफ़ समझना ज़्यादा अहम है
  • लेकिन software न जानने वाला व्यक्ति अगर डेवलपर से कहे कि “तुम गलत कर रहे हो”, तो इसे सकारात्मक मानना मुश्किल है

• “AI code 1.7 गुना ज़्यादा समस्याएँ पैदा करता है” यह बात सिर्फ़ पकड़े गए bugs की संख्या बताती है

  • वास्तव में PR review ठीक से नहीं होता, इसलिए AI code की बहुत-सी समस्याएँ छूट भी जाती हैं
  • कुछ research यह भी कहती है कि code review का focus bugs ढूँढने से ज़्यादा structure को समझने और साझा करने पर होना चाहिए
  • दूसरी ओर, कुछ लोगों का कहना है कि AI code में comments ज़्यादा होते हैं और उसे पढ़ना आसान होता है, इसलिए उसका review उल्टा और अधिक ध्यान से किया जाता है
    • human-written code में “यह क्या है पता नहीं, लेकिन हटाया तो टूट जाएगा” जैसी comments ज़्यादा मिलती हैं

• कुछ समय पहले .NET में IComparable implementation Copilot ने सुझा दी, जिससे मेरे कुछ मिनट बच गए

  • लेकिन उसने variable names को x और y करके उलट दिया, और मैं एक घंटे तक debugging करता रहा
  • अगर मैं खुद लिखता तो ऐसी गलती नहीं होती
  • फिर भी कुल मिलाकर code लगभग वही था जो मैं खुद लिखता

• पहले भी ऐसी ही स्थिति रही है

  • error handling और edge cases को नज़रअंदाज़ करो तो deployment बहुत तेज़ हो सकता है, लेकिन आख़िरकार वह bug bomb बन जाता है
  • AI इसे चरम तक धकेलती हुई लगती है
  • इस पर मज़ाक भी आता है कि “ऐसा है तो फिर Erlang या Elixir पर ही चले जाना चाहिए”

• यह दिलचस्प था कि LLM-आधारित कंपनी कह रही थी कि “AI उतनी बेकार नहीं है जितना लोग सोचते हैं”

  • लेकिन Coderabbit एक LLM code review कंपनी है, इसलिए उसके पास उल्टा यह incentive है कि “AI खराब है, इसलिए AI से review कराओ”
  • मैं भी Copilot को review tool की तरह इस्तेमाल करता हूँ, और AI review लगभग हमेशा सही होती है, इसलिए human review से पहले यह काफ़ी मददगार होती है

• मैं CodeRabbit अक्सर इस्तेमाल करता हूँ, लेकिन अब भी false positives काफ़ी हैं

  • कभी-कभी यह पहले से validated code पर भी कह देता है कि “data validation नहीं है”
  • फिर भी अगर आप इसे बता दें कि “यह गलत है”, तो tool उससे सीखकर उसे स्वीकार कर लेता है

• “1.7 गुना ज़्यादा” और “1.7 गुना बढ़ गया” एक ही बात नहीं हैं

  • लेकिन ऐसे numbers पर बहस आख़िर में बेमानी लड़ाई जैसी लगती है

• Agentic AI coding बस एक tool है; गलत तरीके से इस्तेमाल करोगे तो गलत नतीजे आना स्वाभाविक है

  • सफल उपयोग के उदाहरण के तौर पर Python के justhtml example की सिफारिश की गई
  • लेकिन “इसे इस्तेमाल करना नहीं आता तो तुम अयोग्य हो” जैसी black-and-white सोच समस्या है
    • किसी को AI उपयोगी लगे या न लगे, यह बस अनुभव का अंतर है

• लेख के शीर्षक में “AI code 1.7 गुना ज़्यादा समस्याएँ पैदा करता है” कहना सटीक नहीं है

  • असल में इसमें सिर्फ़ bugs नहीं बल्कि formatting और naming issues तक शामिल हैं
  • bug की संख्या खुद लेख में स्पष्ट रूप से दी ही नहीं गई है