क्या AI coding assistant टूल्स धीरे-धीरे खराब होते जा रहे हैं?

 (spectrum.ieee.org)
10 पॉइंट द्वारा GN⁺ 2026-01-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल के समय में AI coding assistant टूल्स की कुल गुणवत्ता में गिरावट दिख रही है, और काम की गति व नतीजों की शुद्धता पहले की तुलना में कमजोर हुई है
  • नवीनतम large language model (LLM) अब syntax errors कम करते हैं, लेकिन उसके बदले ऐसे silent failure ज़्यादा पैदा करते हैं जिनमें code चलता तो है, पर परिणाम गलत होता है
  • प्रयोगों में GPT-5 अक्सर error के मूल कारण को सामने लाए बिना मान गढ़कर समस्या को ढक देता है, जबकि GPT-4 और Claude के पुराने versions data या code की समस्या को अपेक्षाकृत साफ़ तौर पर उजागर करते हैं
  • यह बदलाव user acceptance को learning signal मानने की प्रक्रिया में data quality धुंधली पड़ने के परिणाम से भी जुड़ा है
  • अगर अल्पकालिक execution success से आगे बढ़कर high-quality data और expert validation में निवेश नहीं किया गया, तो यह जोखिम बढ़ेगा कि model अपनी ही बनाई गलतियों को फिर से सीखता रहे

AI coding assistant टूल्स के performance में गिरावट

  • पिछले कुछ महीनों में AI coding assistant टूल्स की work efficiency और code reliability, दोनों में गिरावट देखी गई है
    • जो काम पहले AI की मदद से 5 घंटे में हो जाता था, वह अब कई मामलों में 7–8 घंटे या उससे अधिक लेने लगा है
    • कुछ users स्थिरता के कारण पिछली पीढ़ी के LLM फिर से चुन रहे हैं
  • AI से बने code को बिना मानवीय हस्तक्षेप चलाने वाले test environment में यह बदलाव बार-बार देखा गया है

नए models में उभरता ‘silent failure’

  • पहले समस्याएँ ज़्यादातर syntax error या स्पष्ट logical error के रूप में होती थीं, जो execution के दौरान तुरंत सामने आ जाती थीं
  • नवीनतम models अब ऊपरी तौर पर सामान्य चलने वाला लेकिन अर्थ के स्तर पर गलत code बनाने की प्रवृत्ति ज़्यादा दिखा रहे हैं
    • safety checks हटा देना
    • केवल output format मिलाने के लिए नकली values बनाना
  • ऐसी छिपी हुई गलतियाँ देर से पकड़ी जाती हैं और आगे के चरणों में अधिक लागत व भ्रम पैदा करती हैं
  • यह आधुनिक programming languages के उस सिद्धांत से सीधे टकराता है कि वे तेज़ी से और स्पष्ट रूप से fail करें

साधारण tests में दिखा अंतर

  • एक Python code error, जो मौजूद ही नहीं होने वाले column को refer करता था, ChatGPT के कई versions को दिया गया
    • GPT-4: ज़्यादातर जवाबों में error के कारण की ओर इशारा किया गया या debugging के लिए प्रेरित किया गया
    • GPT-4.1: dataframe columns print करके समस्या की पुष्टि करने की दिशा में मार्गदर्शन दिया गया
    • GPT-5: वास्तविक index का उपयोग करके calculation कर डाली, code execution सफल होने का आभास दिया, लेकिन परिणाम अर्थहीन values निकले
  • Claude models में भी इसी तरह का रुझान देखा गया
    • पुराने versions समस्या पहचानने पर केंद्रित थे
    • नए versions error को नज़रअंदाज़ करते हैं या उसे bypass करने वाले समाधान सुझाते हैं

training तरीकों और गुणवत्ता गिरावट का संबंध

  • शुरुआती models मुख्यतः बड़ी मात्रा में मौजूद code पर train किए गए थे; उनमें errors ज़रूर थे, लेकिन वे समस्या को खुद नहीं छिपाते थे
  • बाद में IDE integration के साथ user behavior (code acceptance, execution success आदि) को learning signal के रूप में इस्तेमाल किया जाने लगा
  • नए users बढ़ने के साथ ‘बस चल जाए तो code अच्छा है’ जैसे signals जमा होने लगे, और models ने इन्हें सीखना शुरू किया
    • नतीजतन safety checks हटाना, fake data बनाना जैसे गलत patterns मज़बूत हुए
  • जैसे-जैसे automated coding features बढ़ते हैं, मानवीय validation घटती है, और model बार-बार गलत training दोहराने लगता है

आगे की ज़रूरी दिशा

  • AI coding assistant टूल्स अब भी developer productivity और accessibility को काफ़ी बढ़ाने वाले tools हैं
  • लेकिन execution success-केंद्रित training लंबी अवधि में code quality को नुकसान पहुँचाती है
  • experts द्वारा labeled high-quality data और ज़िम्मेदार retraining process अनिवार्य हैं
  • नहीं तो model के गलत output → गलत training → और खराब output वाले चक्र में फँसने की आशंका बढ़ेगी

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-10
Hacker News की राय

  • यह दिलचस्प है कि AI के उत्साही लोग अपनी productivity बढ़ने की बात करते समय व्यक्तिपरक अनुभव पर निर्भर करते हैं, लेकिन विरोधी राय से अत्यधिक proof burden मांगते हैं

    • मैंने पहले LinkedIn पर एक पोस्ट देखी थी जिसमें कहा गया था कि “AI से काम की रफ़्तार 10 गुना बढ़ गई”
      लेखक ने वास्तव में live streaming demo का ऐलान किया था, लेकिन नतीजतन वह एक साधारण extension task भी एक घंटे में पूरा नहीं कर पाया
      मुझे लगा, अगर मैं खुद हाथ से करता तो भी लगभग उतना ही समय लगता
      इसलिए मैंने कमेंट में पूछा, “10 गुना सुधार कहाँ है?”, तो उसने “वह बस एक छोटी-सी गलती थी” या “AI जवाब दे रही थी तब मैं दूसरा काम कर सकता था” जैसी बातों से इनकार किया
      सच कहूँ तो शुरू में मैं संदेह में था, लेकिन चाहता था कि मेरा संदेह ग़लत निकले। लेकिन ऐसा नहीं हुआ
    • ऐसे दावों का खंडन करना असंभव है। वे “secret workflow” है या “तुम इसे ठीक से इस्तेमाल नहीं कर रहे” जैसी बातों से बच निकलते हैं
      आखिरकार productivity बढ़ने के दावे का proof burden पूरी तरह दावा करने वाले पर ही होता है
    • मैं पेशेवर programmer नहीं हूँ, लेकिन मुझे लगता है कि AI को दोहराए जाने वाले काम हटाने के tool की तरह इस्तेमाल करने से बड़ी दक्षता मिल सकती है
      मुझे नहीं लगता कि AI मौलिक सोच कर सकती है। लेकिन tab autocomplete फ़ीचर loop, error handling, documentation जैसी चीज़ों में बहुत समय बचा देता है
      समस्या हल करने की गति वही रहती है, लेकिन implementation चरण में यह निश्चित रूप से तेज़ हो जाता है
      यानी, अगर “10 गुना सुधार” है, तो वह समस्या-समाधान में नहीं बल्कि typing speed में 10 गुना सुधार है
    • मेरे मामले में पिछले कुछ महीनों में AI काफ़ी बेहतर हुई है। planning mode में काम को छोटे हिस्सों में बाँटकर execution–verification–testing–review–deployment दोहराती है
      C# आधारित 10 लाख lines वाले project में भी quality घटे बिना productivity काफ़ी बढ़ी है
      आलोचकों से मैं कहना चाहूँगा, “खुद करके दिखाइए।” यह कोई secret technique नहीं, बस tool को संभालना सीखने में समय लगा है
    • एक साल से ज़्यादा समय से मैं ऐसे “मैं AI से 10 गुना तेज़ हो गया” वाले पोस्ट देखता आ रहा हूँ
      लेकिन फिर वे अपने बनाए शानदार नतीजे दिखाने के बजाय मुझे मनाने की कोशिश क्यों करते हैं?
      क्या कहीं reward या incentive तो नहीं है, ऐसा शक होता है

  • समस्या यह नहीं कि AI ख़राब हो गई है, बल्कि results की reproducibility कमज़ोर है
    ride-hailing या delivery app की तरह LLM ecosystem भी अंततः price increase structure की ओर जाएगा। अभी तो यह सिर्फ़ investment funding की वजह से subsidized state में है

    • taxi fare की एक निचली सीमा fuel cost वगैरह से तय होती है, लेकिन inference cost लगातार घट रही है
      अभी subsidy की वजह से सस्ता है, लेकिन जल्द ही subsidy के बिना भी सस्ता होने की संभावना ज़्यादा है
      हाँ, latest SOTA model इस्तेमाल करना महँगा हो सकता है। लेकिन वह अलग value का सवाल है
    • अगर आप model को खुद local में run करके देखें, तो समझ आएगा कि “यह subsidy की वजह से है” वाली बात ग़लत है
      10–20 हज़ार डॉलर में ऐसी machine बनाई जा सकती है जो पूरे दिन token generate करे, और बड़े operator economies of scale से इसे और कुशलता से चलाते हैं
    • कुछ model अब भी बुनियादी factual error करते हैं। उदाहरण के लिए iOS 26 मौजूद होने के बावजूद वे जवाब देते हैं, “आपका मतलब iOS 16 होगा?”
      ऐसे हिस्सों पर अब भी भरोसा करना मुश्किल है
    • इसलिए मैं अभी subsidy era ख़त्म होने से पहले जितना हो सके उतना बनाकर रखना चाहता हूँ। बाद में cost बढ़ेगी
    • मुझे लगता है कि अभी की कम कीमतें टिकाऊ नहीं, बल्कि एक transitional state हैं
      जब investment funding रुक जाएगी, तो आख़िरकार कीमतें बढ़ेंगी, और competition गायब होने के बाद ही असली cost structure सामने आएगा

  • कुछ users के अनुसार “AI ख़राब हो गई” वाला test ही अजीब है
    उदाहरण के लिए, अगर ऐसे code में जो मौजूद ही नहीं होने वाले column को refer करता है, आप कहें “बिना comment के सिर्फ़ completed code दो”, तो AI मजबूरन ग़लत code दे सकती है

    • ऐसे impossible prompt को जस का तस मान लेना उलटा गिरावट है
      एक सक्षम developer को कहना चाहिए, “यह ग़लत request है।” यह test sycophantism दिखाने वाला वैध प्रयोग है
    • वास्तविक development में ऐसी स्थिति अक्सर आती है। AI हो या इंसान, जब data format अपेक्षा से अलग हो तो बताना चाहिए
      बस चुपचाप ग़लत result दे देना ख़तरनाक है
    • ऐसे मामलों में यह feedback ठुकराने वाली AI लगती है, जैसे कोई “अक्षम developer” हो
    • असल में ज़्यादातर coding agents कह सकते हैं, “index_value column नहीं है, इसलिए df.index इस्तेमाल करना चाहिए”
      ऐसी गलती GPT-2 स्तर की hallucination के ज़्यादा क़रीब है

  • मुझे AI development assistant tools पसंद हैं, लेकिन यह हमेशा absolute gain है या नहीं, इस पर यक़ीन नहीं
    पहले मैं lunch time कम करने के लिए Huel पीता था, लेकिन अंत में मैंने break की value ही खो दी
    AI के साथ भी, अगर यह details मिस कर दे तो उलटा वापस जाकर ठीक करने का समय लग जाता है

    • सबसे मुश्किल काम है AI को ठीक-ठीक बताना कि आप क्या चाहते हैं
      इसलिए मैं project का पूरा context और constraints रखने वाली 15k token की Markdown file बनाकर हर बार prompt में डालता हूँ
      यह एक तरह का “world model” document है
    • मैंने Huel और AI दोनों इस्तेमाल किए हैं, और सच में अनुभव बहुत मिलता-जुलता था
    • productivity बढ़ने का तर्क आखिरकार expectations के recalibration से neutralize हो जाता है
      जितना समय बचता है, उतना ही ज़्यादा काम आप करने लगते हैं, और self-efficacy तथा problem-solving ability कमज़ोर पड़ती है
      यह भूल जाना आसान है कि ऐसी “inefficiency” दरअसल ज्ञान और insight पाने की प्रक्रिया थी
      AI की productivity boost, वास्तविक operating cost से तुलना करें तो शायद बढ़ा-चढ़ाकर आँकी गई हो
    • एक comment को यह पूरी चर्चा हल्के-फुल्के विज्ञापन जैसी लगी

  • IEEE से तकनीकी paper की उम्मीद थी, लेकिन यह लेख opinion piece स्तर का निकला, यह थोड़ा निराशाजनक था

    • सच तो यह है कि AI की तारीफ़ करने वाले लेख भी ज़्यादातर बिना आधार के अनुभवजन्य किस्से ही होते हैं। खुद इस्तेमाल करने से पहले पता नहीं चलता
    • यह IEEE Spectrum magazine की हल्की सामग्री है
    • ieee.org domain देखकर मैंने भी कठोर शोध लेख की उम्मीद की थी
    • उदाहरण सिर्फ़ OpenAI model तक सीमित हैं, लेकिन title पूरे model जगत पर generalize करता है
      मैं इस बात से सहमत हूँ कि GPT-5 problem solving पर ही केंद्रित रहता है और big picture नहीं देख पाता, लेकिन दूसरे model अब भी अच्छा काम करते हैं
    • यह भी कहा जाता है कि Ilya के जाने के बाद OpenAI कोई नया training run सफलतापूर्वक नहीं कर पाया
      मैं व्यक्तिगत रूप से Gemini-3-flash और एक custom Copilot replacement extension इस्तेमाल करता हूँ, और वह कहीं ज़्यादा उपयोगी तथा personalized development experience देता है

  • हाल में मैंने Cursor को grep, cd, ls को मानो infinite loop की तरह दोहराते देखा
    लगता है उसने बहुत ज़्यादा “vibe coder” users को target करते हुए features ठूँस दिए हैं। उलटा हल्का version ज़्यादा संभालने लायक था

  • “execution failure” ज़रूरी नहीं कि बुरा संकेत हो
    कभी-कभी वही सबसे क़रीबी सही जवाब होता है, या bug ढूँढने का सुराग बन सकता है
    लेकिन execution के लिए validation logic हटाना या meaning बदल देना सबसे ख़राब नतीजा है

  • मुझे जिज्ञासा है कि जब LLM इंटरनेट की सारी जानकारी ख़त्म कर चुकी होगी, तब क्या होगा
    अगर Stack Overflow या open source code गायब हो जाए, तो क्या आख़िरकार वह खुद को ही सीखते-सीखते collapse (model collapse) नहीं कर जाएगी?

    • Model collapse वास्तव में शोध किया गया concept है
      लेकिन कुछ शोधकर्ता मानते हैं कि वास्तविक पैमाने के data में इसका जोखिम बहुत बड़ा नहीं है
      हाल के NVIDIA Nemotron 3 Nano model का 33% हिस्सा synthetic data पर train किया गया है
    • AlphaZero की तरह AI खुद project generate और maintain करने वाली दिशा में भी बढ़ सकती है
      maintainability जैसी value function को शामिल करके simulation चलाया जा सकता है
    • लेकिन अगर AI द्वारा बनाए गए hallucinated data पर फिर से training हो, तो quality धीरे-धीरे गिर सकती है
      अगर AI खुद अपनी गलती पहचान न सके, तो self-collapse की संभावना हो सकती है
    • आख़िरकार शायद sharing का युग ख़त्म होगा, और चीज़ें बंद, छोटे पैमाने के collaboration में बदल जाएँगी
      “sharing is caring” वाला इंटरनेट शायद गायब हो जाए
    • संभवतः आगे चलकर training सिर्फ़ LLM आने से पहले के internet snapshot पर होगी, और अतिरिक्त data को मानव curate करेंगे

  • AI ख़राब नहीं हुई है, बल्कि बेहतर हुई है, बस इस्तेमाल का तरीका बदल गया है
    सही scaffolding होने पर काफ़ी बेहतर परिणाम मिल सकते हैं
    सिर्फ़ साधारण test से “AI बेवकूफ़ है” निष्कर्ष निकालना ग़लत है

    • इस पर एक प्रतिक्रिया थी, “तो आख़िरकार बात वही हुई कि ‘तुम इसे ग़लत इस्तेमाल कर रहे हो’?”
    • लेकिन यह राय भी है कि scaffolding की ज़रूरत होना ही समस्या है
      उदाहरण के लिए, अगर आप “December sales” पूछें, तो ज़्यादातर model साल की शर्त के बिना हर December का total जोड़ देते हैं
      ऐसी logical error वास्तविक काम में समस्या पैदा करती है
    • clean code और clear communication करने वाले developer LLM को बेहतर ढंग से संभालते हैं
      लगता है कि technical vocabulary और अभिव्यक्ति की क्षमता performance को प्रभावित करती है
    • ऐसे लेख एक तरह के “Look Ma, I made the AI fail!” वाले content जैसे लगते हैं
    • लेकिन “तुम्हें scaffolding आनी चाहिए” वाली बात आम users के लिए आख़िरकार एक barrier बन जाती है, यह बात भी उठी

  • मैंने भी model की महीना-दर-महीना quality variation महसूस की है
    लगता है कि वह पहले अच्छी तरह कर लेने वाली error handling या variable naming conventions जैसी चीज़ें भूल गई है
    कभी-कभी बातचीत लंबी होने पर quality गिरती जाती है। शायद prompt length का एक optimum point होता है

    • GitHub Copilot docs (लिंक) के अनुसार,
      नया काम नए thread से शुरू करना और अनावश्यक requests हटाना बेहतर है
    • आखिरकार पूरी conversation एक ही query होती है, इसलिए जैसे-जैसे यह लंबी होती है, AI की context को सही तरह समझने की क्षमता पर निर्भरता बढ़ती जाती है