AI को सोच की जगह नहीं लेनी चाहिए, बल्कि उसे ऊंचा उठाना चाहिए
(koshyjohn.com)- विश्वसनीय दिखने वाले आउटपुट जितनी तेजी से बनाए जाते हैं, उतना ही समझ के बिना दोहराने की आदत आसान हो जाती है, और अगर निर्णय क्षमता विकसित करने का अभ्यास छोड़ दिया जाए तो दीर्घकालिक क्षमता कमजोर पड़ती है
- परिचित पैटर्न में मदद बड़ी होती है, लेकिन अनजानी समस्याओं, अस्पष्ट शर्तों, अधूरी जानकारी और टकराती हुई सीमाओं में ऊपरी नकल जल्दी टूट जाती है और असली कौशल सामने आ जाता है
- मजबूत इंजीनियर boilerplate, summary, test scaffolding, और research acceleration जैसे यांत्रिक काम सौंप देते हैं, लेकिन समस्या की परिभाषा, review, चुनाव और त्याग की जिम्मेदारी खुद रखते हैं
- software engineering की सबसे बड़ी वैल्यू code production से ज्यादा निर्णय क्षमता में होती है; छिपी हुई सीमाओं को देखना, गलत समस्या को पहचानना, और अस्पष्ट बहस को trade-off में बदलना अधिक महत्वपूर्ण हो जाता है
- खासकर करियर की शुरुआत और संगठन संचालन में वास्तविक समझ को बचाए रखने के मानदंड ज्यादा महत्वपूर्ण होते हैं; क्या delegate करना है और क्या खुद संभालना है, इसे जितना बेहतर अलग किया जाए, AI उतना ही इंसानी मूल्य बढ़ाने वाला टूल बनता है
जब सोच को outsource किया जाता है, तब पैदा होने वाले failure modes
- A.I. code generation, meeting summary, concept explanation, design draft लिखना, और status update तैयार करना जैसे काम तेजी से कर सकता है, लेकिन यह समझ के बिना बस भरोसेमंद दिखने वाले नतीजे देने की आदत भी आसानी से बना सकता है
- अगर मशीन के दिए जवाब को अपनी समझ की तरह दोहराया जाए, तो क्षमता बनाए बिना केवल कुशल दिखने की अवस्था की नकल की जाती है
- generated output जितना अधिक अपनी समझ की जगह लेने लगेगा, उतना ही निर्णय क्षमता विकसित करने का अभ्यास छूटेगा, और दीर्घकालिक क्षमता की जगह अल्पकालिक बाहरी प्रभाव ले लेगा
- अनजानी समस्या, अस्पष्ट शर्त, अधूरी जानकारी, या टकराती सीमाओं जैसी वे स्थितियां जो template से हल नहीं होतीं, उनमें ऊपरी नकल जल्दी बिखर जाती है
-
परीक्षा में उत्तर नकल करने वाली उपमा
- उत्तर नकल करके अच्छे अंक बनाए जा सकते हैं, लेकिन जैसे ही स्थिति वास्तविक समझ मांगती है, खाली बुनियाद उजागर हो जाती है
- खुद काम करते हुए बनने वाली सहज समझ न हो तो अनजान समस्याओं पर reasoning करना या शर्तों के बदलाव के मुताबिक ढलना कठिन हो जाता है
- A.I. के दिए जवाब को बार-बार उठाकर इस्तेमाल करने से केवल कुशलता का बाहरी रूप उधार मिलता है, असली कौशल नहीं बनता
-
calculator वाली उपमा
- calculator समय बचाने वाला अच्छा टूल है, लेकिन अगर number sense के बिना उस पर निर्भर हो जाएं, तो यह जांचना मुश्किल हो जाता है कि नतीजा सही लग भी रहा है या नहीं
- बुनियाद वाला इंजीनियर A.I. output की समीक्षा कर सकता है, गलती छांट सकता है, और उसे सुधार या खारिज कर सकता है
- बुनियाद के बिना इंजीनियर A.I. का उपयोग नहीं करता, बल्कि A.I. के पीछे घिसटने लगता है, और जहां accuracy तथा नतीजों की जिम्मेदारी अहम हो, वहां यह और खतरनाक हो जाता है
-
self-driving car वाली उपमा
- self-driving थकान कम करती है और रोजमर्रा की स्थितियां संभाल लेती है, लेकिन अगर ड्राइविंग समझने से पहले उस पर निर्भर हो जाएं, तो आप सिर्फ नियंत्रण अधिकार वाले यात्री के ज्यादा करीब हो जाते हैं
- कम दृश्यता, जटिल सड़कें, अप्रत्याशित वाहन, system failure, और अचानक खतरे जैसी non-standard स्थितियों में असली कौशल सामने आता है
- A.I. भी सामान्य पैटर्न और परिचित संरचनाओं में मजबूत है, लेकिन engineering लगातार requirements change, सूक्ष्म bugs, अस्पष्ट ownership, competing architecture goals, partial data, organizational friction, और ऐसे trade-offs से भरी रहती है जिनका कोई perfect answer नहीं होता
बेहतरीन इंजीनियर A.I. का उपयोग कैसे करते हैं
- बेहतरीन इंजीनियर A.I. कम नहीं, बल्कि और अधिक सक्रिय रूप से इस्तेमाल करते हैं, लेकिन सोचने का काम उसे नहीं सौंपते
- boilerplate लिखना, document summary, test scaffolding बनाना, refactoring suggestions, failure possibilities खोजना, research acceleration, और दोहराए जाने वाले काम को compress करना जैसे यांत्रिक काम वे खुशी से सौंप देते हैं
- लेकिन वे अधिक पैने सवाल बनाते हैं, सामने आई request नहीं बल्कि वास्तविक समस्या को परिभाषित करते हैं, और चमकदार लेकिन खोखले वाक्यों से ज्यादा स्पष्टता और संक्षिप्तता को प्राथमिकता देते हैं
- वे सिर्फ system के भीतर मौजूद ज्ञान को फिर से जोड़ने तक सीमित नहीं रहते, बल्कि नया high-value knowledge पैदा करते हैं
- इस तरह बचाए गए समय को वे फिर से उच्च-स्तरीय सोच और निर्णय में निवेश करते हैं
मूल्य का वास्तविक स्रोत
- लंबे समय तक software engineering को code production के बराबर माना गया, लेकिन सबसे ऊंची वैल्यू वहां नहीं है
- अगर सिर्फ syntactically सही code बनाना ही मूल काम होता, तो A.I. सीधे इस पेशे का बड़ा हिस्सा बदल देता, लेकिन असली केंद्र निर्णय क्षमता है
- मूल्यवान इंजीनियर outage होने से पहले छिपी हुई सीमाएं देख लेते हैं, पहचान लेते हैं कि टीम गलत समस्या हल कर रही है, अस्पष्ट बहस को साफ trade-off में बदल देते हैं, missing abstraction ढूंढते हैं, और code नहीं बल्कि वास्तविक दुनिया को debug करते हैं
- A.I. ऐसे कामों में सहायता कर सकता है, लेकिन उन्हें अपने ऊपर नहीं ले सकता
- आगे चलकर ज्यादा मूल्य बनाने वाले इंजीनियर वे होंगे जो A.I. को अधिक उपयोगी बनाने वाली design principles, domain understanding, patterns, context, और decision-making frameworks तैयार करते हैं
- इस माहौल में इंजीनियर A.I. से replace होने के बजाय raw output के ऊपर वाले स्तर पर काम करते हुए ज्यादा leverage हासिल करते हैं
करियर की शुरुआत में इंजीनियरों के लिए बड़ा खतरा
- यह समस्या खासतौर पर करियर की शुरुआत में अधिक महत्वपूर्ण है
- शुरुआती कुछ साल वे होते हैं जब debugging instinct, system intuition, precision, taste, skeptical review, problem decomposition, और यह समझाने की क्षमता कि कुछ काम क्यों करता है, जैसी मूलभूत क्षमताएं बनती हैं
- ये क्षमताएं friction, trial and error, failure fixing, root cause tracing, और वास्तविकता से टकराकर सीखने के अनुभव से बनती हैं
- अगर सीखने की प्रक्रिया में A.I. सारी कठिनाइयां हटा दे, तो अल्पकालिक efficiency तो मिल सकती है, लेकिन कौशल को धार देने वाला चरण छूट जाता है
- एक-दो quarter तक सब efficient लग सकता है, लेकिन भविष्य को संभालने वाली क्षमता चुपचाप खो सकती है
- support systems चीजों को काम करता हुआ दिखा सकते हैं, लेकिन वास्तविक क्षमता अपने आप नहीं बना सकते
निर्णय क्षमता के लिए कोई shortcut नहीं है
- सिर्फ generated explanation पढ़ लेने से, बिना खुद काम किए, कौशल सीधे दिमाग में transfer नहीं हो जाता
- लंबे समय तक reasoning को outsource करके अंत में मजबूत reasoning हासिल कर लेने का कोई रास्ता नहीं है
- यांत्रिक काम outsource करना, research की रफ्तार बढ़ाना, और दोहराए जाने वाले काम को compress करना संभव भी है और वांछनीय भी
- लेकिन कौशल निर्माण की प्रक्रिया को छोड़कर भी वह कौशल हासिल हो जाएगा, ऐसा नहीं होता
- A.I. के सबसे भोले उपयोग की मूल गलती यह है कि हम सोचते हैं कि समय बच रहा है, जबकि वास्तव में कमजोर निर्णय क्षमता, सतही समझ, और कम अनुकूलनशीलता का बिल बस आगे खिसकाया जा रहा होता है
विभाजन रेखा और संगठन स्तर पर इसके निहितार्थ
- अगर A.I. समझ को तेजी से गहरा करे, अधिक गहराई से सोचने में मदद करे, और उच्च स्तर पर काम करने दे, तो इंसानी मूल्य बढ़ता है
- अगर A.I. समझ से बचने, कठिनाई से बचने, और reasoning की जिम्मेदारी से बचने में मदद करे, तो इंसानी मूल्य घटता है
- एक रास्ता compound interest की तरह बढ़ता है, और दूसरा भीतर से खाली करते हुए आसानी से अप्रासंगिक हो जाने वाली स्थिति की ओर ले जाता है
- भविष्य उन इंजीनियरों के पक्ष में है जो सिर्फ A.I. का इस्तेमाल नहीं करते, बल्कि क्या delegate करना है और क्या खुद own करना है यह सटीक रूप से तय करते हैं, और बचाया गया समय बेहतर सोच में बदलते हैं
संगठनात्मक स्वास्थ्य पर इसका प्रभाव और बड़ा क्यों है
- engineering management भी उसी सीमा पर खड़ा होता है जहां समझ को तेज करने वाले उपयोग और समझ की नकल करने वाले उपयोग में फर्क करना जरूरी है
- मजबूत leadership को चमकदार output और वास्तविक निर्णय क्षमता में भेद कर पाना चाहिए; अगर सिर्फ speed, fluency, और presentation skill को पुरस्कृत किया जाएगा, तो technical depth के संकेत छूट जाएंगे
- अगर कम समझ और ज्यादा fluency वाला काम फैलने लगे, तो सिर्फ व्यक्तिगत output quality नहीं गिरती, बल्कि संगठन का knowledge environment ही कमजोर हो जाता है
- review कमजोर हो जाते हैं
- design discussions उथली हो जाती हैं
- documents ज्यादा polished लेकिन कम उपयोगी हो जाते हैं
- और समय के साथ संगठन अपनी जरूरत की स्पष्टता और technical judgment पैदा करने की क्षमता खो देता है
- इसलिए असली बात A.I. tools को अपनाने से ज्यादा उन परिस्थितियों को बचाए रखना है जिनमें वास्तविक सोच, सीखना, और craftsmanship जिंदा रहें
- hiring चरण से ही बाहरी fluency नहीं बल्कि वास्तविक समझ पहचानने के तरीके चाहिए
- interviews को polished answers से ज्यादा reasoning process परखना चाहिए
- evaluation को output volume से ज्यादा स्पष्टता, गहराई, sound judgment, और लंबे समय तक चलने वाले technical contribution को पुरस्कृत करना चाहिए
- 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 की कीमत मैं नहीं चुकाने वाला हूँ