AI कोडिंग से पैदा होने वाली लागत

 (tomwojcik.com)
27 पॉइंट द्वारा GN⁺ 2026-03-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डेवलपर्स द्वारा AI कोडिंग टूल्स का व्यापक उपयोग करने से उत्पादकता बढ़ी है, लेकिन इसके साथ अदृश्य संज्ञानात्मक और संगठनात्मक लागतें भी पैदा हो रही हैं
  • शुरुआती Copilot·Cursor जैसे सहायक टूल्स से आगे बढ़कर, हाल में यह स्वायत्त एजेंटों तक विकसित हो गया है, जहाँ संरचना ऐसी बन रही है कि इंसान AI की मदद करता है
  • लेकिन पूरी तरह सौंपकर उपयोग करने से cognitive debt और debugging क्षमता में गिरावट आती है, जिससे डेवलपर की समस्या-समाधान क्षमता और कोड समझ कमजोर होती है
  • AI द्वारा लिखे गए कोड को केवल रिव्यू करने वाली संरचना senior डेवलपर तैयार करने की राह के टूटने और रचनात्मक immersion (flow) के नुकसान की ओर ले जाती है, जिससे संगठन की तकनीकी क्षमता लंबे समय में क्षीण होती है
  • AI का उपयोग आवश्यक है, लेकिन ‘उचित उपयोग सीमा’ को स्वयं तय करना और उसे इस तरह समायोजित करना ज़रूरी है कि इंसानी समझ और सीखने की प्रक्रिया बनी रहे

AI कोडिंग अपनाने का विकास

  • 2022~2023 में आए Copilot·Cursor जैसे टूल्स कोडबेस को इंडेक्स करके संदर्भ-आधारित autocomplete और chat सुविधाएँ देते थे
    • Google सर्च या StackOverflow खोज की ज़रूरत कम हो गई, और AI-embedded IDE वातावरण फैलने लगा
  • इसके बाद आए agent-आधारित workflow ने मानव-सहायता से आगे बढ़कर AI-नेतृत्व वाले development की दिशा ले ली
    • लेकिन एजेंट्स में loop, hallucination, dependency errors जैसी वजहों से भरोसेमंदी की समस्याएँ पैदा हुईं
  • Opus 4.5 के बाद automation का स्तर बढ़ा, और कुछ कंपनियों में ऐसे उदाहरण भी दिखे जहाँ डेवलपर खुद सीधे कोड नहीं लिखते
    • उदाहरण: Spotify के सह-CEO ने कहा कि इंजीनियर Slack में Claude को निर्देश देकर feature बदलने से लेकर deployment तक कर रहे हैं

संज्ञानात्मक ऋण और कौशल का क्षरण

  • Manfred Spitzer के ‘Digital Dementia’ और Margaret-Anne Storey के ‘Cognitive Debt’ विचारों का उल्लेख किया गया है
    • यदि दोहराव वाले विचार-कार्य AI को सौंप दिए जाएँ, तो मस्तिष्क के रास्ते कमजोर होते हैं और कोड समझने की क्षमता घटती है
  • Shen·Tamkin(2026) अध्ययन: 52 डेवलपर्स में AI-सहायता समूह ने conceptual understanding, debugging, और code reading में 17% कम स्कोर किया
    • खासकर debugging क्षमता में गिरावट अधिक स्पष्ट थी, और सिर्फ 1 घंटे के निष्क्रिय AI उपयोग से भी मापी जा सकने वाली कौशल-क्षति देखी गई
  • जब AI चुनौतीपूर्ण काम अपने ऊपर ले लेता है, तो ‘वास्तविक flow’ नहीं बल्कि ‘dark flow’ जैसी स्थिति बनती है, जहाँ सीखने के बजाय निर्भरता बढ़ती है

कोड रिव्यू का विरोधाभास और senior स्तर का पतन

  • जब AI कोड लिखता है और इंसान केवल उसका रिव्यू करता है, तो रिव्यू क्षमता के स्रोत के ही गायब हो जाने का विरोधाभास पैदा होता है
    • AI पर पूरी तरह निर्भर डेवलपर्स तेजी से काम तो करते हैं, लेकिन उनके मूल्यांकन स्कोर सबसे नीचे आते हैं
  • Storey का सुझाव है: “deployment से पहले AI-जनित बदलावों को इंसान पूरी तरह समझे”
  • AI शुरुआती डेवलपर्स को senior-स्तर का output देता है, लेकिन यह अक्सर समझ के बिना की गई नकल भर होता है
    • senior डेवलपर्स खुद कोड न लिखने से गहराई खो देते हैं, और junior डेवलपर्स trial and error से न गुजरने के कारण विकसित नहीं हो पाते
    • नतीजतन senior डेवलपर तैयार करने की pipeline टूट जाती है

प्रबंधन की गलतफहमी और संगठनात्मक दुष्प्रभाव

  • Microsoft, Anthropic, Google जैसी कंपनियों के प्रबंधन ने अनुमान लगाया कि AI कुछ ही महीनों में इंजीनियर्स की जगह ले लेगा
    • Google ने 2024 के अंत में रिपोर्ट किया कि नए कोड का 50% AI-जनित है
  • लेकिन ऐसे आँकड़े अक्सर AI बिक्री और शेयर कीमत बढ़ाने के उद्देश्य से बढ़ा-चढ़ाकर पेश किए जाते हैं, और सामान्य संगठनों पर लागू नहीं होते
  • कुछ कंपनियाँ AI उपयोग मात्रा को KPI के रूप में मापकर डेवलपर्स पर थोप रही हैं
    • Reddit का उदाहरण: डेवलपर्स ने बेमतलब prompts देकर AI उपयोग आँकड़े बढ़ाए
    • नतीजतन Goodhart's law लागू होती है, और उत्पादकता बढ़ने के बजाय सिर्फ औपचारिक अनुपालन बचता है

मानवीय लागत और रचनात्मकता का नुकसान

  • कोड लिखना डूबकर काम करने और सृजन की खुशी देता है, लेकिन AI कोड का रिव्यू करना मानसिक थकान पैदा करता है
    • जब सृजन का dopamine reward खत्म होता है, तो burnout तेज़ी से बढ़ता है
    • development quality assurance (QA) में सिमट जाता है, और रचनात्मक संतोष खत्म हो जाता है
  • इसे उस स्थिति से तुलना की गई है जहाँ AI सारी कला करता है और इंसान केवल ‘कपड़े तह करने’ जैसा काम करता रह जाता है

AI उपयोग की उचित सीमा

  • AI एक शक्तिशाली टूल है, लेकिन ज़्यादा या कम उपयोग अपने-आप में अच्छा नहीं होता
    • Shen·Tamkin अध्ययन के अनुसार 6 तरह के AI interaction patterns में,
      • ‘पूरी तरह सौंप देना, क्रमिक निर्भरता, debugging का ठेका’ सीखने में बाधा डालते हैं
      • ‘explanation माँगना, concept संबंधी सवाल, स्वतंत्र coding के बाद verification’ सीखने को बनाए रखते हैं
  • मुख्य बात संज्ञानात्मक भागीदारी को बनाए रखना है; सिर्फ उपयोग करना या न करना नहीं, बल्कि कैसे उपयोग किया जा रहा है यह अधिक महत्वपूर्ण है
  • AI बिल्कुल न इस्तेमाल करने पर search, boilerplate, और exploration efficiency का नुकसान होता है,
    जबकि अत्यधिक उपयोग से समझ, senior विकास, bug detection, और immersion को क्षति पहुँचती है

शांत क्षय

  • मेट्रिक्स में PR की संख्या, features की संख्या, cycle time बेहतर दिख सकते हैं,
    लेकिन भीतरी तकनीकी क्षमता, एकाग्रता, और समस्या-समाधान शक्ति धीरे-धीरे कमजोर होती जाती है
  • डेवलपर्स ऐसे ‘butter robot’ बन जाते हैं जो AI द्वारा बनाई गई संरचना को समझे बिना सिर्फ approval क्लिक करते हैं
  • Simon Willison ने भी कहा कि अपने प्रोजेक्ट में AI द्वारा बनाए गए features की समीक्षा न करने के कारण
    “अब वे उसकी आंतरिक कार्यप्रणाली को पहले जितनी स्पष्टता से नहीं समझते”
  • अंततः टूल नहीं, इंसान क्षीण होता है, और यह बदलाव न तो ठीक से मापा जाता है, न प्रबंधित
  • AI पर निर्भरता लत की तरह बढ़ सकती है, और शांत लेकिन वास्तविक तकनीकी गिरावट का जोखिम पैदा करती है

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

1 टिप्पणियां

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

  • मुझे अब भी खुद कोड लिखने और उसके स्ट्रक्चर को दिमाग में बनाने की प्रक्रिया अपने काम की सबसे बड़ी खुशियों में से एक लगती है
    बार-बार होने वाला या झुंझलाहट भरा refactoring भी मेरे लिए एक अर्थपूर्ण प्रक्रिया है
    यही कठिन पल अगली बार बेहतर तरीका खोजने की सीख देते हैं
    कभी न कभी यह रुझान वापस आएगा, यही उम्मीद बची हुई है

    • पूरी तरह सहमत हूँ। ऐसा सोचने वाले लोग शायद ज़्यादा नहीं दिखते, लेकिन आप अकेले नहीं हैं
      मुझे विश्वास है कि एक दिन खुद चुनने और निर्णय लेने की क्षमता बचाए रखने वालों की अहमियत फिर पहचानी जाएगी
    • जब लोग कहते हैं, “AI सारे tests लिख देता है, कितना आसान है,” तो मुझे हँसी आती है
      अगर किसी कोड का test लिखना मुश्किल है, तो abstraction या interface बदलने की ज़रूरत है
      test कोड का पहला reuse होता है, इसलिए अगर test में असुविधा है, तो असली उपयोग में भी होगी
    • मैंने भी पाया कि खुद कोड लिखने से debugging बहुत आसान हो जाती है
      जो कोड मैंने लिखा हो, उसमें समस्या कहाँ आ सकती है, इसका नक्शा दिमाग में जल्दी बन जाता है
      LLM चाहे जितने logs दे दे, वह इस intuition की जगह नहीं ले सकता
    • मैं भी Copilot का इस्तेमाल मुख्यतः frontend JavaScript काम में करता हूँ
      लेकिन मुझे चिंता है कि कहीं इससे frontend ecosystem को बेहतर बनाने की प्रेरणा ही खत्म न हो जाए
    • मैं भी coding को उसके अपने रूप में प्यार करता हूँ
      लोग जिन कामों को LLM पर छोड़ना चाहते हैं, उन्हें भी खुद करना मुझे अच्छा लगता है
      कंपनियों को यह छोटी-छोटी खुशियाँ धीरे-धीरे छीनते देख दुख होता है

  • पिछले 1 साल में मैंने Claude Code का बहुत इस्तेमाल किया है, और हाल में साथ काम करने वालों के बीच AI को लेकर भावनाओं में बदलाव महसूस किया है
    AI के ज़रूरत से ज़्यादा इस्तेमाल से पैदा होने वाली छिपी हुई लागत पर मैंने लिखा भी है, और कई स्रोतों से डेटा इकट्ठा किया
    अभी साफ़ डेटा नहीं है, लेकिन लगता है बहुत से डेवलपर्स यही महसूस कर रहे हैं

    • दिलचस्प लगा। “AGI तक पहुँचने की timeline” में Xeno’s Arrow का visual representation काफ़ी असरदार था
      लेकिन “software तो सिर्फ़ एक tool है” वाली बात मुझे हमेशा अजीब लगती है
      जब कोई tool सोचने का काम भी अपने ऊपर लेने लगे, तो क्या उसे अब भी “tool” कहा जा सकता है?
      “prompt addiction” जैसा ईमानदार शब्द अच्छा लगा। लेकिन behavioral addiction के पहलू को भी खंगालना चाहिए
    • लेख की हर बात से सहमत हूँ। खासकर speed और efficiency की लत वाली बात असली समस्या है
      सब कुछ तेज़ और control में लगता है, लेकिन धीरे-धीरे control हाथ से निकलता जाता है
      असली मुश्किल यह तय करना है कि “इसे कितनी sustainable speed पर इस्तेमाल किया जाए”
    • “creation का dopamine hit” वाला वाक्य बहुत असरदार था
      मैंने भी इसी विषय पर एक blog post लिखा था,
      जिसमें यह देखा कि नेता संगठन को sustainable balance खोजने में कैसे मदद कर सकते हैं
    • मैं भी इसी विषय पर लिखने वाला था, लेकिन अभी सिर्फ़ research ही की है
      working memory और reward system का learning और immersion पर क्या असर पड़ता है, इस पर papers देखे
      उदाहरण के लिए Nature paper कहता है कि working memory में dopamine responsiveness होती है
      और Scientific American article के अनुसार हाथ से लिखने पर दिमाग के ज़्यादा हिस्से सक्रिय होते हैं
      आख़िरकार निष्कर्ष यही है कि कम reward वाले, passive tasks में ऐसे cognitive लाभ लगभग नहीं मिलते
      इसलिए मुझे लगता है कि AI इस्तेमाल करने का मानदंड यह होना चाहिए कि “काम कितना कष्टदायक और कम reward वाला है”

  • मैं अब भी खुद कोड लिखता हूँ और उसके नतीजे को पूरी तरह समझता हूँ
    speed बढ़े या न बढ़े, उससे फ़र्क नहीं पड़ता। ज़रूरी यह है कि यह कोड मेरा है, यह ownership का एहसास है
    पहले भी outsourcing कर सकता था, लेकिन तब मैं सिर्फ़ कोड पढ़ने वाला इंसान बनकर रह जाता

    • अगर speed और efficiency इतनी ही महत्वपूर्ण होती, तो डेवलपर्स को शोर भरे open office में क्यों ठूँस दिया जाता?
    • सच कहूँ तो atrophy की चिंता करने की ज़रूरत नहीं है। सिर्फ़ वही क्षमता घटती है जिसकी अब ज़रूरत नहीं रही
    • क्या कंपनियाँ सच में ऐसे tools का इस्तेमाल मजबूरन करवा रही हैं?
      मैं और मेरे आसपास ज़्यादातर डेवलपर्स ऐसा दबाव महसूस कर रहे हैं
    • IT की दुनिया में हमेशा तेज़ बदलाव और adaptation रहा है। ऐसा हठ ज़्यादा समय तक नहीं टिकेगा
    • मुझे भी लगता है कि शायद गिरावट न आए
      keyboard इस्तेमाल करने से लिखावट नहीं भूलते, और कॉफी खरीदकर पीने से कॉफी बनाना नहीं भूलते

  • 80 के दशक की शुरुआत में मैंने LSI-11 assembly से coding सीखी थी और सारे octal opcodes याद कर लिए थे
    लेकिन FORTRAN 83 सीखने के बाद productivity 10 गुना बढ़ गई, और उस समय की स्किल्स कम हो गईं तो भी मुझे ज़रा भी अफ़सोस नहीं हुआ
    एक दिन C++ या Java जैसी भाषाएँ भी शायद ग़ैर-ज़रूरी हो चुकी स्किल्स बन जाएँगी

    • लेकिन मुझे लगता है कि यह गलत तुलना है
      opcodes के साथ काम करते हुए जो logical thinking बनी, उसी ने बाद में दूसरी भाषाएँ सीखना आसान बनाया
      ऐसी formal language के साथ सोचने की प्रक्रिया, LLM prompt लिखने की तुलना में कहीं ज़्यादा cognitive depth रखती है
    • सारी programming languages सटीक computation expression languages थीं,
      जबकि AI के साथ सहयोग करना अस्पष्ट natural language में इरादा समझाने जैसा है
      जब तक आप English में pseudocode नहीं लिख रहे, precision कम हो जाती है
    • अभी यह सिर्फ़ स्किल बदलने की बात नहीं, बल्कि logic से intuition(vibe) की ओर शिफ्ट है
      और इस बार साथ में खुद के replace हो जाने का डर भी जुड़ा है
    • जब LLM कोड लिखता है, तो वह भूमिका programmer से ज़्यादा PM जैसी लगती है

  • अगर AI को इस्तेमाल करने के तीन सही patterns का पालन किया जाए, तो productivity और learning दोनों मिल सकते हैं
    लेकिन anti-patterns अपनाने पर tool dependency, anxiety, debugging skill में गिरावट और instant reward की लत लग सकती है
    आख़िर में cognitive decline का vicious cycle बन जाता है

  • हाल ही में मैं एक AI-केंद्रित कंपनी में शामिल हुआ हूँ, जहाँ manual coding लगभग मना-सी है
    मैंने Claude से API docs पढ़वाकर wrapper बनवाया, और नतीजा पूरी तरह सही था
    लेकिन मैं खुद API की feel या structure बिल्कुल नहीं समझ पाया
    इस तरह “बहुत कुछ कर सकने, लेकिन कुछ भी न जानने” की स्थिति बेचैन और खाली महसूस होती है
    reflexive memory बनती ही नहीं। इसलिए इस लेख की बातों से गहरी सहमति है

  • मैं कई AI द्वारा लिखे गए side projects पर काम कर रहा हूँ

    1. survival game जल्दी बन गया, लेकिन उससे कोई लगाव नहीं है
    2. MacOS के लिए web app चल तो रही है, लेकिन UI quality कमज़ोर है, इसलिए उसे खुद सुधारने वाला हूँ
    3. utility library में मैंने खुद कोड नहीं लिखा, फिर भी अजीब-सा गर्व महसूस होता है
      लेकिन यह एक अजीब भावना है—“अच्छा तो लगता है, पर पूरा यक़ीन नहीं”
      निष्कर्ष यही है कि AI के साथ बनाते समय भी अपनी छाप छोड़नी पड़ती है, तभी उपलब्धि महसूस होती है

  • मुझे coding शुरू किए सिर्फ़ 8 महीने हुए हैं, और AI की वजह से ही सीखा है
    लेकिन जब Claude कोड लिख देता है, तो मैं उसका सिर्फ़ 70% समझ पाता हूँ, बाकी यूँ ही छोड़ देता हूँ
    यह speed नशे जैसी है, लेकिन पूरे structure को दिमाग में बनाए रखने की क्षमता कम हो रही है
    फिर भी AI के बिना मैं आज जो बना पाया हूँ, वह नहीं बना पाता, इसलिए इस trade-off को मानता हूँ

    • समस्या यह है कि AI अकुशल आदतें भी सिखा सकता है
      जैसे बेवजह fallback code बहुत डाल देता है
      अगर अनुभव न हो, तो पता ही नहीं चलता कि यह ग़लत है
    • model सीखता नहीं है। retraining धीमी है, और इंसान उससे कहीं तेज़ी से आगे बढ़ता है
      अभी के LLM का स्तर लगभग intern से junior developer के बीच का है
    • model से architecture report लिखवाकर उससे खुद explain करवाना अच्छा तरीका हो सकता है
      bottleneck model नहीं, बल्कि हमारी verification की क्षमता है
    • Claude Code में “learning mode” भी है, जो कोड में “TODO(human)” छोड़ते हुए समझाता है

  • सिर्फ़ boilerplate automation के लिए क्या सच में LLM की ज़रूरत है, इस पर संदेह है
    क्या यह काम पुराने metaprogramming या scripts से नहीं हो सकता?
    और सिद्धांत के तौर पर AI को न अपनाना भी शायद एक तरह का संतोष देने वाला विकल्प हो सकता है

    • दूसरे डेवलपर्स के साथ काम करते हुए मैंने महसूस किया कि कई लोग tool proficiency की कमी के कारण धीमे पड़ जाते हैं
      mouse और keyboard का इस्तेमाल, file navigation, commands खोजना—इन बुनियादी चीज़ों में ही कमजोरी होती है
      इसलिए “चलो LLM से पूछ लेते हैं” वाला लालच बढ़ता है
      लेकिन असली समाधान है tool proficiency बढ़ाना और template engines सीखना

  • AI की वजह से स्किल में गिरावट आ सकती है,
    लेकिन अगर वह ऐसा क्षेत्र है जिस पर मैं खुद ध्यान नहीं देना चाहता, तो मुझे यह ठीक लगता है
    जैसे compiler की अंदरूनी optimization तक जानना हर बार ज़रूरी नहीं

    • लेकिन domain boundaries को साफ़-साफ़ बाँटना आसान नहीं है
      systems के बीच interaction समझने के लिए कुछ हद तक compiler के काम करने का सिद्धांत भी समझना पड़ता है
    • मुझे Mitchell Hashimoto का तरीका काफ़ी तर्कसंगत लगता है
      जिन हिस्सों की चिंता नहीं करनी, उन्हें LLM पर छोड़ दो,
      और सच में महत्वपूर्ण समस्याओं पर अपना mental bandwidth लगाओ