AI: त्वरित होती अयोग्यता
(slater.dev)- software engineering में LLM पर अत्यधिक निर्भरता अयोग्यता को तेज़ी से बढ़ावा देती है
- LLM में ऐसी सीमाएँ हैं कि वे critical thinking और समस्या-समाधान क्षमता की जगह नहीं ले सकते
- LLM के उपयोग के साथ गलत output, input त्रुटियाँ, code quality में गिरावट, developer क्षमता में कमी, रचना के आनंद का खोना जैसी कई जोखिम जुड़ी हैं
- LLM program theory और program entropy जैसी मूलभूत विकास क्षमताएँ प्रदान नहीं कर सकते
- लंबी अवधि में तकनीकी कौशल और गहरी सोचने की क्षमता पहले से कहीं अधिक महत्वपूर्ण हैं
परिचय
2022 के अंत में AI और LLM को व्यापक जन-ध्यान मिलने के बाद, इस पर बहुत सी चर्चा जारी रही
एक अनुभवी software engineer के रूप में, लेखक LLM में देखी गई दो प्रमुख समस्याओं पर बात करता है
"LLM मेरा दोस्त है" वाला दृष्टिकोण
जो engineer LLM को सर्वोत्तम tool मानते हैं, वे speed को सर्वोच्च मूल्य बना लेते हैं
LLM से बहुत सा code तेज़ी से बनाया जा सकता है, लेकिन इसमें दीर्घकालिक जोखिम छिपे होते हैं
LLM उपयोग के जोखिम
- गलत output का जोखिम: LLM स्पष्ट रूप से गलत code (compile न होने वाला) और सूक्ष्म त्रुटियों वाला code (जैसे logic bug) बना सकता है
- जिन लोगों में मूल्यांकन क्षमता नहीं है, वे source code मांगते समय अनुपयुक्त उत्तर पाने की अधिक संभावना रखते हैं
- गलत input का जोखिम: LLM त्रुटिपूर्ण मान्यताओं या संदर्भ-विहीन prompt की आलोचना नहीं करता
- वह सही प्रश्न की पहचान नहीं कर पाता और XY समस्या (मूल कारण पहचानने में विफलता) के प्रति भी संवेदनशील नहीं होता
- भविष्य की विकास गति में कमी: LLM अपनाने से technical debt तेज़ी से बढ़ता है और अंदरूनी तौर पर अव्यवस्थित तथा maintain करना कठिन codebase बन जाता है
- उपयोगकर्ता के अपरिपक्व होने का जोखिम: समस्या-समाधान और सोच-विकास के अवसर समाप्त होने से developer प्रतिभा की क्षमता-क्षीणता तेज़ हो जाती है
- senior developer को अधिक गहरे समस्या-समाधान का अनुभव नहीं मिलता, और junior developer तो कौशल बना ही नहीं पाता
- रचना के आनंद का खोना: LLM-आधारित code लेखन flow state और सृजन की खुशी छीन लेता है, और AI द्वारा लिखे code को पढ़ना व बदलना अक्सर कष्टदायक होता है
"क्या AI की वजह से मैं अपनी नौकरी खो दूँगा?" वाली चिंता
ऐसा होने की संभावना बहुत कम है
दो ऐसी विकास क्षमताएँ हैं जिन्हें LLM प्रतिस्थापित नहीं कर सकते: program theory और program entropy
Program theory
- Peter Naur के अनुसार, “programming design theory बनाने की गतिविधि है”
- source code वास्तविक उत्पाद नहीं है; सामूहिक समझ (theory) अधिक महत्वपूर्ण है
- यदि समान कौशल वाली दो teams को एक ही समस्या दी जाए और केवल code सौंपा जाए, तो जिस team ने उसे स्वयं बनाया है वह feature जोड़ने में कहीं अधिक प्रभावी होगी
- अपरिचित codebase में productivity कम रहती है, लेकिन जैसे-जैसे आंतरिक design theory की समझ बढ़ती है, productivity भी बढ़ती जाती है
LLM और program theory
- LLM के पास केवल context के भीतर की memory होती है, इसलिए वे वास्तविक program theory या गहरे design को आत्मसात नहीं कर सकते
- वास्तव में coding का असली सार (design और theory का निर्माण) केवल मनुष्य ही अर्जित करता है
Program entropy
- Fred Brooks ने complexity (entropy) को programming की मूलभूत कठिनाई कहा था
- program maintenance complexity बढ़ाती है, और सर्वोत्तम execution भी अंततः system को अपरिवर्तनीय पुरानापन की ओर धकेल देता है
LLM और program entropy
- LLM केवल text स्तर पर token prediction करते हैं; ideas, design blueprints, और requirements के स्तर पर semantic thinking नहीं कर सकते
- लंबे संवाद या बड़े code chunks को संभालते हुए वे बार-बार अनावश्यक या विचित्र बदलाव करते हैं, जिससे complexity और बढ़ती है
- complexity को कम करना या उसका प्रतिरोध करना केवल मनुष्य ही कर सकता है
निष्कर्ष
दो अग्रदूतों की अंतर्दृष्टि के आधार पर software design और complexity के सार को फिर से रेखांकित किया गया है
यदि आप उम्मीद करते हैं कि AI आपकी development career को बेहतर बनाएगा, तो सावधान रहें कि इससे उल्टा अयोग्यता तेज़ हो सकती है
समृद्ध अनुभव और पक्के कौशल वाले developer के रूप में, यह समझना चाहिए कि LLM मानव engineer का स्थान नहीं ले सकते
AI अपनाने का व्यावसायिक आकर्षण लागत घटाना है, लेकिन व्यवहार में यह नए जोखिम पैदा करता है, और अत्यधिक उपयोग करने पर लंबी अवधि की अतिरिक्त लागत और संगठनात्मक जोखिम जमा होते जाते हैं
तकनीकी कौशल और गहरी सोच की क्षमता का महत्व लंबी अवधि में नहीं बदलता; AI को tool की तरह उपयोग करें और उन मूलभूत क्षमताओं में निवेश जारी रखें जो 2019 में भी महत्वपूर्ण थीं
अगला लेख पूर्वावलोकन
आगे की post में प्रत्येक जोखिम के लिए ठोस समाधान पर चर्चा की जाएगी
संदर्भ
- Leading Question: https://en.wikipedia.org/wiki/Leading_question
- The XY Problem: https://en.wikipedia.org/wiki/XY_problem
- ThoughtWorks Technology Radar Volume 32: https://thoughtworks.com/content/dam/…
- Coding as Craft: Going Back to the Old Gym: https://cekrem.github.io/posts/…
- Thoughts on Thinking: https://dcurt.is/thinking
- The Hidden Cost of AI Coding: https://terriblesoftware.org/2025/04/23/the-hidden-cost-of-ai-coding/
- "I wonder if I'll become redundant": https://reddit.com/r/ExperiencedDevs/…
- Programming as Theory Building: https://pablo.rauzy.name/dev/naur1985programming.pdf
- Grug on Complexity: https://grugbrain.dev/#grug-on-complexity
- Gartner Hype Cycle: https://en.wikipedia.org/wiki/Gartner_hype_cycle
1 टिप्पणियां
Hacker News की राय
software engineer से हमेशा ऐसे software बनाने की अपेक्षा होती है जो predictable हो और tests पास करे, और tooling भी कहीं ज़्यादा विकसित है
दूसरी ओर, machine learning engineer के लिए probabilistic model के साथ काम करना रोज़मर्रा की बात है, और testing भी अक्सर किसी खास output के बजाय metrics-केंद्रित evaluation पर आधारित होती है
इसलिए वे इस बात के ज़्यादा अभ्यस्त हैं कि AI हमेशा भरोसेमंद नहीं होता
coding assistant को भी इसी सोच के साथ लिया जाता है कि अगर वह 80% सही जवाब दे, तो बाकी 20% मैं पकड़ लूंगा
Amazon में काम करते समय, जिन समस्याओं के लिए कोई classical approach नहीं थी, वहाँ ML-आधारित solution बहुत उपयोगी था
लेकिन एक startup में, basic filtering या mapping की समझ के बिना सिर्फ learning-based approach पर अड़े रहने से, रुके हुए aircraft की attitude estimation में बार-बार बेतुके नतीजे आए
ML और SW engineer के बीच यह gap साफ़ दिखता है, और अच्छा होता अगर hiring process में इसे बेहतर तरीके से सामने लाया जा सके
ऐसे product बेचने वाली company में जहाँ accuracy और correctness बहुत महत्वपूर्ण हैं, ML टीम 80~90% को पर्याप्त मानती है, और इस पर architect की नाराज़गी देखी गई
pandemic में 1% fatality rate की चर्चाओं की तरह, यह याद रखना चाहिए कि छोटा percentage भी बड़ा असर डाल सकता है
यह लेख AI और software engineering के meta सवाल पर केंद्रित है, यानी program entropy का management
entropy management software product बनाने का बहुत बड़ा हिस्सा है, और AI कभी भविष्य में इसे आसान बना सकता है, लेकिन अभी तो कई बार entropy को और खराब कर देता है
MLE को SWE के बड़े perspective से देखते हुए, robust pipeline बनाना, model integration, deployment आदि का पूरा समझना ज़रूरी है
लेकिन ज़्यादातर pure MLE majors में SWE नज़रिया कम होता है, और अक्सर computer systems की instinct के बिना सिर्फ ML समझा जाता है
सचमुच full-stack बनने के लिए low-level systems, architecture, deployment और MLE सब समझना ज़रूरी है
लेकिन market hiring ज़्यादातर SWE या MLE PhD ही खोजती है; जो यह सब जानता/जानती है, उसके लिए बेहतर reward की इच्छा स्वाभाविक है
जैसे race condition को redesign करना, DB calls के p99 का अनुमान लगाना, A/B tests आदि
30 साल के अनुभव वाले senior developer के रूप में, AI-generated code पढ़ने की ज़रूरत का मतलब है कि development code review-केंद्रित flow की ओर जा रहा है
इससे individual developer को भी team-level accountability और code पढ़ने के अनुभव से सीखने में मदद मिलती है
साथ ही, LLM का सही उपयोग करने के लिए problem की hierarchical structure को समझना अनिवार्य है
sections के हिसाब से विस्तार से design करके implement करना, स्वाभाविक रूप से interfaces और boundaries को define करने में मदद करता है
LLM वह catalyst है जो junior को senior बनने की गति बढ़ाता है और experienced developers की learning को महसूस करने में मदद करता है
AI developers को replace नहीं करेगा, बल्कि अंततः एक tool की तरह घुल-मिल जाएगा
LLM-generated code monotonous हो सकता है, लेकिन वह भी learning opportunity है
LLM-generated code से कई नए idioms/library calls आदि के बारे में पता चलता है
जितने senior होंगे, उतने बेहतर prompts दे पाएँगे, इसलिए LLM और ज़्यादा शक्तिशाली catalyst बनता है
big tech, mid tech, small tech—सब जगह layoffs जारी हैं
तर्क यह है कि AI singularity से ज़्यादा ऐसी ही व्यावहारिक बदलावों के करीब है
lecture/assignment/class के वे तरीके जो पहले स्वाभाविक लगते थे, LLM आने के बाद दुनिया भर में तेज़ी से बदल रहे हैं
SpaceX न होता तो कई चीज़ें वास्तव में संभव नहीं होतीं
अंत में banks ने ही Bitcoin-आधारित financial products बेचने शुरू कर दिए
3D printing को existing manufacturing replacement नहीं माना जाता, और वह ज़्यादातर prototype/mockup/PoC तक सीमित है
जो code बिना समझे स्वीकार किया जाता है, उसकी maintenance बाद में बहुत महँगी पड़ती है, यानी technical debt
यह मानो free speed का भ्रम हो, जबकि असल में करीब 40% annual interest rate से technical debt जमा हो रहा हो
AI typing को automate कर सकता है, लेकिन सोचना इंसान को ही करना होगा
कुछ लोगों के अनुसार, tdd और microservices जैसी चीज़ें जो पारंपरिक development में अनावश्यक लगती थीं, LLM युग में और अधिक मूल्यवान हो सकती हैं
prompt की छोटी-सी ambiguity भी परिणाम को पूरी तरह पटरी से उतार सकती है, और जब तक यह पता चलता है, तब तक संभालना मुश्किल हो जाता है
मानवीय भाषा की ambiguity की वजह से ही अंततः स्पष्ट formal languages पैदा हुईं
व्यक्तिगत रूप से AI tooling इस्तेमाल करते हुए लगा कि skill तेज़ी से गिर रही है; कई बार समय और ऊर्जा उल्टा ज़्यादा खर्च हुई
AI उपयोगी है, लेकिन एक पक्ष वह है जहाँ complex problems में छोटी गलतियाँ जमा होती जाती हैं, और दूसरा पक्ष managers/non-technical लोग हैं जो सिर्फ result देखकर 'role replacement' की बात करते हैं
[विस्तृत अनुभव: पिछली टिप्पणी]
जैसे calculator ने लोगों की mental math कमज़ोर की, वैसे ही AI writing, communication, problem-solving क्षमता को भी कम कर सकता है
इसलिए छोटे और स्पष्ट tasks, या StackOverflow पर मिलने वाली समस्याओं तक ही LLM इस्तेमाल करने का तरीका अपनाया गया
जवाब को absolute truth नहीं, बल्कि guide की तरह लें
पूरे blueprint को समझने की मानव क्षमता ही entropy के खिलाफ़ मुख्य रक्षा है
इससे topic/context को और साफ़ किया जा सकता है
उम्मीद है यह छोटा टिप दूसरों के भी काम आएगा
उदाहरण: पुराना Coke vs Pepsi युद्ध
अगर LLM से design intent के संदर्भ में पूछा जाए, जैसे 'simplified code दो', तो उससे अच्छा second opinion मिल सकता है
अगर पूछा ही न जाए तो जवाब मिलेगा ही नहीं, और default settings भी हमारी ही पसंद हैं, इसलिए इसे underlying technology के स्वभाव से जोड़ना सही नहीं लगता
वास्तविक दुनिया में कोई भी व्यक्ति किसी बहुत बड़े program को पूरी तरह दिमाग में नहीं रख सकता; tools और languages अधिकतर partial understanding पर ही विकसित हुए हैं
LLM भी उसी सीमा को साझा करता है, इसलिए इस ढाँचे में इंसान और LLM दोनों की सीमाएँ कुछ हद तक मिलती-जुलती हैं
अफ़सोस यह है कि LLM के लिए उस direction पर 'ऐसा क्यों कर रहे हो?' जैसा सवाल पूछना कठिन है
इसमें कुछ सच्चाई है, लेकिन ज़्यादातर लोग पहले से ही direction में अच्छे नहीं थे, और maps की वजह से A→B जाने की औसत क्षमता शायद बढ़ी है
जो थोड़े लोग पहले से कुशल थे, उनके लिए भी technology उनकी क्षमता को replace करने के बजाय assist करती है
AI भी बड़े पैमाने पर ऐसा ही बदलाव लाएगा; कुछ skills घटेंगी और कुछ नुकसान होंगे, लेकिन काफ़ी लाभ भी मिलेंगे
maps लगभग हमेशा expected value देते हैं, लेकिन LLM एक ही prompt पर अलग परिणाम दे सकता है, इसलिए उस पर भरोसा करना मुश्किल है
जैसे maps पर अंधा भरोसा करके लोग झील में जा गिरते हैं, वैसे ही LLM पर अंधा भरोसा और बड़ा नुकसान करा सकता है
खुलकर भटकने और ज़रूरत पर route पकड़ लेने की सुविधा से अनुभव और बढ़ जाता है
AI कई बार उस आम इंसान से भी बदतर है जिसने उस क्षेत्र में बस कुछ दिन ही काम किया हो
हाल के LLM स्पष्ट रूप से conceptual level पर काम कर सकते हैं, जैसे concept translation/application
यह भी दावा है कि वे ऐसे concepts को समझते हैं जिन्हें इंसान ने व्यक्तिगत रूप से अनुभव न किया हो
उदाहरण: 'dog' के आसपास उससे जुड़े शब्द इकट्ठे होते हैं
लेकिन combinations, intention, counterfactual logic आदि को model नहीं कर पाता
training data से मिलते-जुलते सवालों में यह काफ़ी अच्छा चलता है
software engineering जैसे क्षेत्रों में, जहाँ conceptualization अच्छी तरह defined है, यह उपयोगी हो सकता है
आख़िरकार जो लोग मेहनत से काम नहीं करते, वे AI के साथ भी नहीं बदलेंगे; सीखने वाले लोग ही AI के साथ बढ़ेंगे
अगर AI काम बेहतर कर दे, तो वही उन्हें replace करने का justification बन सकता है
FSD (self-driving) भी experts की तुलना में नहीं, बल्कि आम drivers की तुलना में कहीं बेहतर है
forum, mailing list, multi-blog format आदि पर विचार चल रहा है
अस्थायी mailing list
कुछ communities में ऐसे सफल उदाहरण पहले से हैं