- डेवलपर्स द्वारा 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 पर निर्भरता लत की तरह बढ़ सकती है, और शांत लेकिन वास्तविक तकनीकी गिरावट का जोखिम पैदा करती है
अभी कोई टिप्पणी नहीं है.