AI को सोच की जगह नहीं लेनी चाहिए, बल्कि उसे ऊँचा उठाना चाहिए
(koshyjohn.com)- विश्वसनीय दिखने वाले आउटपुट जितनी तेजी से बनते हैं, समझ के बिना दोहराव उतना आसान हो जाता है, और अगर निर्णय क्षमता विकसित करने का अभ्यास छोड़ दिया जाए तो दीर्घकालिक क्षमता कमजोर हो जाती है
- परिचित पैटर्न में यह बहुत मददगार है, लेकिन अनजानी समस्याओं, अस्पष्ट शर्तों, अधूरी जानकारी और टकराती बाधाओं में ऊपरी नकल आसानी से टूट जाती है और असली कौशल सामने आ जाता है
- मजबूत इंजीनियर boilerplate, summary, test scaffolding, research acceleration जैसे यांत्रिक काम सौंप देते हैं, लेकिन समस्या की परिभाषा, review, चयन और त्याग की जिम्मेदारी खुद रखते हैं
- software engineering का सबसे बड़ा मूल्य code production से ज्यादा judgment में है; छिपी हुई बाधाओं को देखना, गलत समस्या को पहचानना और अस्पष्ट बहस को trade-off में बदलना अब और भी महत्वपूर्ण हो गया है
- खासकर करियर की शुरुआत और संगठन संचालन में वास्तविक समझ को बचाए रखने के मानदंड ज्यादा महत्वपूर्ण हैं; क्या delegate करना है और क्या खुद करना है, यह जितना साफ होगा, AI उतना ही इंसानी मूल्य बढ़ाने वाला tool बनेगा
सोच को outsource करने पर पैदा होने वाले failure modes
- A.I. code generation, meeting summary, concept explanation, design draft, status update writing जैसे काम तेजी से कर देता है, लेकिन समझ के बिना सिर्फ विश्वसनीय दिखने वाले नतीजे देने की आदत भी आसानी से बना सकता है
- अगर मशीन के जवाब को अपनी समझ की तरह दोहराया जाए, तो क्षमता बनाए बिना ही कुशल दिखने की स्थिति की नकल होने लगती है
- जितना ज्यादा generated output अपनी समझ की जगह लेता है, उतना ही निर्णय क्षमता विकसित करने का अभ्यास छूटता है, और दीर्घकालिक क्षमता की अदला-बदली अल्पकालिक बाहरी प्रभाव से होने लगती है
- अनजान समस्याएँ, अस्पष्ट शर्तें, अधूरी जानकारी और टकराती बाधाएँ जैसे template से न सुलझने वाले हालात में ऊपरी नकल जल्दी टूट जाती है
-
परीक्षा में उत्तर नकल करने की उपमा
- उत्तर नकल करके अच्छे अंक लाए जा सकते हैं, लेकिन जैसे ही वास्तविक समझ की ज़रूरत वाली स्थिति आती है, खाली बुनियाद सामने आ जाती है
- खुद काम करके बनने वाली intuition न हो, तो अनजान समस्या पर reasoning करना या शर्तें बदलने पर ढलना मुश्किल हो जाता है
- A.I. के दिए जवाब बार-बार इस्तेमाल करने से सिर्फ दक्षता का बाहरी रूप उधार मिलता है, असली दक्षता नहीं बनती
-
calculator की उपमा
- calculator समय बचाने वाला अच्छा tool है, लेकिन number sense के बिना उस पर निर्भरता बढ़ जाए तो यह जाँचना मुश्किल हो जाता है कि परिणाम सही लग भी रहा है या नहीं
- मजबूत आधार वाला इंजीनियर A.I. output को review कर सकता है, errors को छाँट सकता है, और उसे ठीक या discard कर सकता है
- कमजोर आधार वाला इंजीनियर A.I. का इस्तेमाल नहीं करता, बल्कि A.I. के सहारे बहने लगता है, और जहाँ accuracy व परिणाम की जिम्मेदारी महत्वपूर्ण हो, वहाँ यह और खतरनाक हो जाता है
-
self-driving car की उपमा
- self-driving थकान कम कर सकती है और रोज़मर्रा की स्थितियाँ संभाल सकती है, लेकिन ड्राइविंग समझने से पहले उस पर निर्भर हो जाएँ तो आप control अधिकार वाले यात्री भर रह जाते हैं
- कम दृश्यता, जटिल सड़कें, अनिश्चित दूसरे वाहन, system failure और अचानक खतरे जैसी non-standard स्थितियों में असली कौशल सामने आता है
- A.I. भी सामान्य पैटर्न और परिचित संरचनाओं में मजबूत है, लेकिन engineering लगातार requirements change, subtle bugs, अस्पष्ट ownership, competing architecture goals, partial data, organizational friction और perfect answer के बिना trade-off जैसी चीज़ों से template के बाहर निकलती रहती है
बेहतरीन इंजीनियर A.I. का उपयोग कैसे करते हैं
- बेहतरीन इंजीनियर A.I. का कम नहीं, बल्कि और अधिक सक्रिय रूप से इस्तेमाल करते हैं, लेकिन सोचने की प्रक्रिया खुद नहीं सौंपते
- boilerplate writing, document summary, test scaffolding generation, refactoring suggestions, failure possibility exploration, research acceleration और repetitive work compression जैसे यांत्रिक काम वे खुशी से सौंप देते हैं
- लेकिन वे और तेज़ प्रश्न बनाते हैं, सामने के request नहीं बल्कि असल समस्या को define करते हैं, और सिर्फ polished वाक्यों की बजाय स्पष्टता और संक्षिप्तता को प्राथमिकता देते हैं
- वे system के भीतर मौजूद ज्ञान को केवल recombine नहीं करते, बल्कि नया high-value knowledge पैदा करते हैं
- इस तरह बचाया गया समय वे फिर से ऊँचे स्तर की सोच और judgment में निवेश करते हैं
मूल्य का असली स्रोत
- लंबे समय तक software engineering को code production के बराबर माना गया, लेकिन सबसे ऊँचा मूल्य वहाँ नहीं है
- अगर सिर्फ syntactically सही code बनाना ही मुख्य बात होती, तो A.I. सीधे job के बड़े हिस्से को replace कर देता; लेकिन असली केंद्र judgment है
- मूल्यवान इंजीनियर outage होने से पहले hidden constraints देख लेते हैं, पहचान लेते हैं कि team गलत समस्या हल कर रही है, अस्पष्ट बहस को साफ trade-off में बदलते हैं, missing abstraction ढूँढते हैं, और code नहीं बल्कि reality को debug करते हैं
- A.I. ऐसे कामों में सहायता कर सकता है, लेकिन उनकी जिम्मेदारी खुद नहीं उठा सकता
- आगे चलकर अधिक मूल्य पैदा करने वाले इंजीनियर वे होंगे जो A.I. को ज्यादा उपयोगी बनाने वाले design principles, domain understanding, patterns, context और decision-making frameworks तैयार करेंगे
- इस माहौल में इंजीनियर A.I. से replace होने के बजाय raw output के ऊपर वाले स्तर पर काम करेंगे और ज्यादा leverage पाएँगे
करियर की शुरुआत में इंजीनियरों के लिए अधिक बड़ा जोखिम
- यह समस्या खासकर करियर की शुरुआत में और महत्वपूर्ण हो जाती है
- शुरुआती कुछ साल मूलभूत क्षमताएँ बनाने का समय होते हैं, जैसे debugging sense, system intuition, precision, taste, skeptical review, problem decomposition और यह समझाने की क्षमता कि कुछ काम क्यों करता है
- ये क्षमताएँ friction, trial and error, failure correction, root cause tracing और reality से टकराकर टूटने वाले अनुभवों से बनती हैं
- अगर सीखने की प्रक्रिया में A.I. हर कठिनाई हटा दे, तो अल्पकालिक efficiency तो मिल सकती है, लेकिन क्षमता को धार देने वाला चरण छूट जाता है
- एक-दो quarter तक सब efficient दिख सकता है, लेकिन भविष्य को संभालने वाली क्षमता चुपचाप छूट सकती है
- support system को functional जैसा दिखाया जा सकता है, लेकिन वह वास्तविक क्षमता आपके लिए पैदा नहीं कर सकता
judgment के लिए कोई shortcut नहीं
- सिर्फ generated explanations पढ़ लेने से, बिना खुद काम किए, दक्षता अपने आप दिमाग में transfer नहीं होती
- लंबे समय तक reasoning outsource करके अंत में मजबूत reasoning ability पा लेने का कोई रास्ता नहीं है
- यांत्रिक काम outsource करना, research की speed बढ़ाना और repetitive work compress करना संभव भी है और वांछनीय भी
- लेकिन कौशल निर्माण की प्रक्रिया को छोड़कर भी उस कौशल का मालिक बन जाना संभव नहीं है
- AI के सबसे भोले उपयोग की केंद्रीय गलती यह है कि हम सोचते हैं कि समय बच रहा है, जबकि वास्तव में हम कमजोर judgment, सतही समझ और कम adaptability का बिल भविष्य के लिए टाल रहे होते हैं
विभाजन रेखा और संगठन स्तर के निहितार्थ
- अगर A.I. समझ को तेजी से गहरा करे, ज्यादा गहराई से सोचने में मदद करे और ऊँचे स्तर पर काम करने दे, तो इंसानी मूल्य बढ़ता है
- अगर A.I. समझ से बचने, कठिनाई से बचने और reasoning की जिम्मेदारी से बचने में मदद करे, तो इंसानी मूल्य घटता है
- एक रास्ता चक्रवृद्धि की तरह बढ़ता है, दूसरा भीतर से खाली करता हुआ आसानी से अप्रासंगिक हो जाने वाली स्थिति की ओर ले जाता है
- भविष्य उन इंजीनियरों के पक्ष में होगा जो सिर्फ A.I. का उपयोग नहीं करते, बल्कि क्या delegate करना है और क्या खुद own करना है यह सटीक समझते हैं, और समय की बचत को बेहतर सोच में बदलते हैं
संगठन के स्वास्थ्य पर इसका असर और बड़ा क्यों है
- engineering management भी उसी सीमा पर खड़ा होता है जहाँ समझ को तेज करने वाले उपयोग और समझ की नकल करने वाले उपयोग में फर्क करना पड़ता है
- मजबूत leadership को polished output और वास्तविक judgment में अंतर कर पाना चाहिए; अगर सिर्फ speed, fluency और presentation को reward किया जाएगा, तो technical depth के signals छूट जाएँगे
- अगर कम समझ और ज्यादा fluency वाला काम फैलने लगे, तो सिर्फ व्यक्तिगत output quality नहीं गिरती, संगठन का knowledge environment ही कमजोर पड़ता है
- review और कमजोर हो जाते हैं
- design discussions और सतही हो जाती हैं
- documents और polished तो हो जाते हैं, लेकिन कम उपयोगी बनते हैं
- समय के साथ संगठन अपनी ही निर्भर स्पष्टता और technical judgment पैदा करने की क्षमता खोने लगता है
- इसलिए मुख्य बात सिर्फ A.I. tools अपनाना नहीं, बल्कि वे परिस्थितियाँ बचाए रखना है जिनमें वास्तविक सोच, सीखना और craftsmanship जीवित रह सके
- hiring stage से ही polished fluency नहीं, बल्कि वास्तविक समझ पहचानने के तरीके चाहिए
- interview को polished answer से ज्यादा reasoning process की जाँच करनी चाहिए
- evaluation को output volume से ज्यादा स्पष्टता, गहराई, sound judgment और लंबे समय तक टिकने वाले technical contribution को reward करना चाहिए
- इसका team design और culture पर भी बड़ा असर पड़ता है
- मजबूत इंजीनियरों का समय उन लोगों के विश्वसनीय लेकिन सतही काम को जरूरत से ज्यादा साफ-सुथरा करने में नहीं जाना चाहिए जिन्होंने अपनी सोच outsource कर दी है
- अगर इसे रोका नहीं गया, तो high performers बाकी सबके लिए amplifier बनकर खर्च होते रहेंगे, और नतीजा अक्सर हताशा, मानकों में गिरावट और attrition में निकलता है
- A.I. युग में संगठन की गुणवत्ता अंततः इस बात पर ज्यादा निर्भर करेगी कि leadership लगातार leverage और dependency, acceleration और imitation, वास्तविक क्षमता और प्रभावशाली दिखने वाले output के बीच फर्क कर पाती है या नहीं
1 टिप्पणियां
Hacker News की राय
इस तर्क को बार-बार पढ़ने पर लगता है कि अभिव्यक्ति की नफ़ासत लगातार बेहतर होती जा रही है, लेकिन अभी भी यह सूक्ति के स्तर तक नहीं पहुँची है
"the medium is the message", "you ship your org chart", "9 mothers can't make a baby in a month" जैसी कुछ पंक्तियों में बहुत से लोगों को छू लेने वाला वाक्य बनने के लिए, अर्थ को तराशने का काम वर्षों से लेकर दशकों तक लेता है
और हम अभी यह भी नहीं जानते कि अर्थ-निर्माण को RL से कैसे संभालें, इसलिए AI यह काम हमारे बदले नहीं कर सकता
मूल रूप से "9 women can't make a baby in one month" सही है
खुद करके सीखना। यह एक पंक्ति सूक्ति के ज़्यादा करीब लगती है
Intelligence amplification, not artificial intelligence अच्छा लगता है
इसे छोटा करें तो IA, not AI बनता है, और स्पैनिश में ले जाएँ तो "AI, no IA" हो जाता है, इसलिए और भी मज़ेदार लगता है
रुचि और निर्णय-क्षमता AI पैदा करके नहीं दे सकता
अगर 100 अमेरिकियों से इस सूक्ति का अर्थ पूछा जाए, तो शायद ही कोई McLuhan के मूल आशय को ठीक से पकड़ पाए
मुझे लगता है कि AI को मोटे तौर पर दो तरीकों से इस्तेमाल किया जा सकता है
एक, वह तरीका जिसमें मैं ऐसा कोड लिखने में मदद लेता हूँ जिसे मैं अपना मानता हूँ और समझता हूँ; दूसरा, वह जिसमें AI को abstraction layer की तरह इस्तेमाल कर कोड लिखने और maintenance की ज़िम्मेदारी दे दी जाती है
दूसरा तरीका prototype, example, reference जैसी चीज़ों के लिए ठीक है, जहाँ उम्र छोटी होती है और code quality या मेरी समझ बहुत महत्वपूर्ण नहीं होती
समस्या तब पैदा होती है जब असल में पहले तरह के काम में दूसरे तरीके का इस्तेमाल करके खुद को और दूसरों को धोखा दिया जाता है
यह तेज़ और आसान दिख सकता है, लेकिन अंत में ऐसा होता है जैसे codebase को गिरवी रख दिया हो, और वहीं से क्षमता का सिकुड़ना भी शुरू होता है
features लगातार ship होते रहते हैं और ऊपर से सब ठीक दिखता है, लेकिन जैसे ही कुछ फटता है, तब पता चलता है कि model से दोबारा पूछे बिना आप अपना ही code debug नहीं कर सकते
बहुत से engineers ऐसे भी हैं जो आधुनिक IDE, memory management वाली भाषाएँ, GitHub या package manager की libraries के बिना काम नहीं कर सकते
इसलिए AI पर निर्भरता मुझे कोई बहुत मूलभूत रूप से अलग चीज़ नहीं लगती
Engineer शब्द का अर्थ भी बदल सकता है, और वास्तव में सिर्फ Webflow या WordPress इस्तेमाल करने वाले "web developer" पहले से मौजूद हैं
सख्त परिभाषा से देखें तो Software Engineering के लोगों में वास्तविक licensed engineer लगभग नहीं के बराबर हैं, और कुछ देशों में इसके लिए qualification और title दोनों होते हैं
career की शुरुआत में समय काफी हो तो शायद लगभग कुछ भी किया जा सकता था, लेकिन अब बहुत-सी चीज़ें ऐसी हैं जिन्हें कर सकते हैं, फिर भी मज़ेदार नहीं लगने के कारण नहीं करते
हमें नहीं पता कि AI की लागत Slack subscription जैसी होगी, टीम के एक सदस्य जितनी होगी, या फिर service ही गायब हो जाएगी और AI access वाला व्यक्ति अलग से रखना पड़ेगा
इसलिए AI पर निर्भर होना, किसी ऐसे IDE पर निर्भर होने जैसा नहीं है जो local या open source tool हो सकता है
लगभग 10 साल का अनुभव रखने वाला व्यक्ति code के flow और logic को समझता है, इसलिए AI इस्तेमाल करके भी code बना सकता है और अपना तरीका बेहतर कर सकता है
इसके उलट, शुरुआती लोग flow या logic नहीं समझते और अक्सर बस copy-paste करने लगते हैं, इसलिए नहीं लगता कि AI उन्हें सोचने की ज़्यादा जगह देगा
AI का मौजूदा इस्तेमाल पिछले 20 साल की programming से भी ज़्यादा थकाने वाला लगता है
समस्या डालना, सुझावों का मूल्यांकन करना, उनमें सही दिशा चुनना, अजीब सुझावों को हटाना, फिर उन्हें निखारकर लगभग सही स्थिति तक लाना—यह पूरी प्रक्रिया ख़ास तौर पर थका देती है
उसके बाद coding को 1 से 5 घंटे चलाकर, वह कभी-कभी ऐसा नतीजा दे देती है जिसे मैं खुद करता तो कम-से-कम 2 से 3 हफ़्ते लगते
लेकिन इस तरह लगभग 5 घंटे planning-केंद्रित काम करने पर मैं पूरी तरह चूर हो जाता हूँ, और यह शुद्ध programming की थकान से अलग है
कुछ सीखने जैसा लगता तो है, लेकिन ईमानदारी से कहूँ तो यह manager का काम ज़्यादा लगता है
LLM के साथ धीरे-धीरे समस्या परिभाषित करके कोई plausible समाधान ढूँढने के लिए लगातार focus state बनाए रखना पड़ता है, इसलिए पहले जैसा deep flow आसानी से नहीं बनता
output के पहाड़ को लगातार प्रोसेस करते हुए बार-बार उसका सार निकालना पड़ता है, और भले वह अधिकतर अच्छा हो, उसमें हमेशा कहीं न कहीं हल्की-सी चूक होती है, जो काफ़ी खलती है
LLM की ख़ास अजीब errors और reasoning defects की वजह से लगातार ऊँची सतर्कता भी रखनी पड़ती है, और उसकी गैर-मानवीय communication style को समझना अपने-आप में थका देता है
लेकिन यह भी लगता है कि pacing या procrastination शायद इंसानों के लिए एक तरह का pressure release valve भी हो सकता है
शुरुआत से ही ठीक से सोच न पाने वाले engineers बहुत हैं, और AI इस तथ्य को बदल नहीं सकता
यही Software Engineering के बहुत बिगड़ने की एक वजह है, और AI शायद इसका समाधान नहीं करेगा, बस और बड़े भ्रम को थोड़ी देर के लिए टाल देगा
जो लोग कॉलेज में cheating करके निकल गए, उन्हें भी पकड़े बिना बचने के लिए आखिरकार critical thinking की ज़रूरत पड़ी होगी
लोग सुनना पसंद न करें, लेकिन cheating अच्छे से करना भी काफ़ी सोचने-समझने की माँग करता है
जो लोग किसी भी स्तर पर AI को सोचने का काम सौंप देते हैं, वे शायद पहले से ही उसे मूल्यवान नहीं मानते थे
"use it or lose it" जैसी कहावत की तरह, इसे समर्थन देने वाले शोध बढ़ते जा रहे हैं, फिर भी software development में LLM का इस्तेमाल ठीक है और हमारी असली कीमत सोचने की क्षमता में है—ऐसी बातें लिखी जाती रहती हैं
किसी और काम में पूरी तरह डूबे होने के बाद अचानक समाधान सूझ जाना, इस काम की सुंदरता में से एक है
अब AI उन विचारों को तेज़ी से action में बदलने वाला tool बन गया है
पहले अक्सर ऐसा होता था कि किसी सुराग को पकड़ने से पहले ही flow टूट जाता था, लेकिन अब फ़ोन से कुछ ही मिनटों में उस विचार को कम-से-कम आंशिक रूप से वास्तविक बना सकता हूँ और फिर अपने पुराने काम पर लौट सकता हूँ
खास बात यह है कि नज़र थोड़ी देर हटाने पर idea खो जाने की चिंता नहीं करनी पड़ती
मैं अभी numba को फिर से बना रहा हूँ, और इसे सिर्फ हाथ से करना अब कल्पना से बाहर लगता है
कुछ साल पहले जब कोशिश की थी, तो वह बेहद तकलीफ़देह, धीमा और बिखरा हुआ था
कई वर्षों में जमा हुए abstractions के ऊपर छोटी-छोटी चीज़ें अंतहीन रूप से चढ़ी हुई थीं, इसलिए और भी ऐसा था
इस बार मैं LLM का इस्तेमाल करके इसे फिर से कर रहा हूँ, और जो काम मूल रूप से कई हफ़्ते लेता, वह कभी-कभी एक रात में ही पूरा हो जाता है
फिर भी मैं code खुद देखता हूँ, generated C output भी देखता हूँ, और architecture पर नियंत्रण भी बनाए रखता हूँ ताकि आगे चलकर मैं और LLM दोनों इसे आसानी से संभाल सकें
यह मेरे सोचने की जगह ले रहा है या नहीं, यह मैं पक्का नहीं कह सकता
अगर मैं कई महीनों तक इसे हाथ से लिखते और सुधारते हुए टिका रहता, तो शायद compiler या transpiler के बारे में ज़्यादा सीखता, लेकिन तब मैं इसी एक चीज़ में फँसा रहता
इसके बजाय अब मेरे पास Golang में custom filesystem के लिए NFS server support अलग से लिखने का भी समय बचता है
अब मैंने ऐसे systems बना लिए हैं जहाँ agents किसी feature के लिए ज़रूरी पूरे बदलाव ढूँढ लेते हैं, planning चरण में उन्हें बहुत बारीकी से खोल देते हैं, और implementation लगभग पहली बार में सही कर देते हैं
पिछले 1 साल में code को खुद पढ़ने का मेरा काम लगातार कम हुआ है, और मैं अक्सर खुद से पूछता हूँ कि मौजूदा system के बारे में जो सहजता मुझे महसूस होती है, कहीं वह ज़रूरत से ज़्यादा तो नहीं
इतनी ऊँची accuracy और success rate बार-बार देखने के बाद अब मैं सहज रूप से शक भी नहीं करता
मैं लगातार इंतज़ार करता रहता हूँ कि कभी न कभी यह बुरी तरह जलाएगा, लेकिन अजीब बात है कि वह पल आता ही नहीं
हाँ, छोटे omissions और rollbacks हुए हैं, लेकिन पहले भी होते थे
फ़र्क यह है कि पहले code मैंने मेहनत से लिखा होता था, इसलिए उससे रिश्ता कहीं ज़्यादा निजी होता था
अब जब समस्या आती है, तो मैं code को दोष देने के बजाय यह खोदने लगता हूँ कि system खुद सही जवाब तक क्यों नहीं पहुँचा, या implementation से पहले planning में पूरी तस्वीर क्यों नहीं खुली
software में AI का सबसे बड़ा फ़ायदा यह है कि आप code तेज़ी से बना सकते हैं
सबसे बड़ा नुकसान यह है कि यह आपको बहुत ज़्यादा तेज़ी से बनाना चाहने के लिए ललचाता है
इसलिए मैं personal projects में AI का इस्तेमाल नहीं करता
क्योंकि मैं दिमाग़ को तेज़ रखना चाहता हूँ
अगर project खुद AI को शामिल करता हो तो अपवाद हो सकता है, लेकिन उस code को लिखने के लिए भी मैं AI का इस्तेमाल नहीं करता
दूसरी ओर, company के काम की मुझे परवाह नहीं
अगर manager चाहता है कि Claude के साथ पूरी तरह vibe coding की जाए, तो मैं वैसा ही करूँगा, क्योंकि उससे पैदा होने वाले technical debt की कीमत मैं नहीं चुकाने वाला हूँ