- आधुनिक तकनीकी सिस्टम इतने जटिल हो चुके हैं कि कोई एक व्यक्ति पूरे सिस्टम को समझ नहीं सकता
- software development और AI के उपयोग में वृद्धि के साथ, ऐसे मामलों में बढ़ोतरी हो रही है जहाँ developers अंदरूनी mechanisms को समझे बिना ही सिस्टम बना रहे हैं
- Simon Wardley ने समझ के बिना सिस्टम बनाने के जोखिम पर, Adam Jacob ने AI के development तरीकों को बदलने पर, और Bruce Perens ने यह कि जटिलता पहले ही सीमा पार कर चुकी है, इस पर जोर दिया
- Louis Bucciarelli ने टेलीफोन सिस्टम के उदाहरण से दिखाया कि तकनीक कई परतों में उलझी होती है, इसलिए कोई भी उसकी पूर्ण समझ तक नहीं पहुँच सकता
- लेख इस बात पर जोर देता है कि AI इस जटिलता को और बढ़ाता है, लेकिन वास्तव में इंसान बहुत पहले से ही आंशिक समझ के साथ तकनीक का उपयोग करते आए हैं
तकनीकी जटिलता और समझ की सीमा
- Twitter के पतन के बाद LinkedIn पर तकनीकी समझ और जटिलता को लेकर सक्रिय चर्चा हुई
- Simon Wardley, Adam Jacob, और Bruce Perens की पोस्टों को परस्पर जुड़े विषयों के रूप में प्रस्तुत किया गया
- Wardley ने बुनियादी सिद्धांतों को जाने बिना सिस्टम बनाने के जोखिम के बारे में चेतावनी दी
- “Magic” शब्द का इस्तेमाल उन frameworks की आलोचना के लिए किया गया जो अंदरूनी कामकाज को छिपाते हैं, और Ruby on Rails को एक प्रमुख उदाहरण के रूप में लिया गया
- Jacob ने बताया कि AI software development के तरीके को मूल रूप से बदल रहा है
- AI दक्षता बढ़ाता है, लेकिन इसकी प्रवृत्ति developers को underlying structure समझे बिना काम करने की ओर ले जाती है
- Perens ने कहा कि Wardley जिस स्थिति को लेकर चिंतित थे, वह पहले ही वास्तविकता बन चुकी है
- आधुनिक CPU और operating system की जटिलता के कारण, कई developers उनके वास्तविक working principles को गलत समझते हैं
Louis Bucciarelli का ‘टेलीफोन’ उदाहरण
- Bucciarelli ने 1994 की अपनी पुस्तक Designing Engineers में तकनीकी साक्षरता की सीमाओं पर चर्चा की
- अधिकांश लोग टेलीफोन के काम करने के सिद्धांत को भौतिक स्तर पर समझा नहीं सकते
- communication network के routing, signal processing, satellite transmission, corporate operations, और regulatory structure जैसे बहु-स्तरीय तत्व आपस में जुड़े होते हैं
- वे इस निष्कर्ष पर पहुँचे कि “कोई भी पूरी तरह नहीं जानता कि उसका अपना टेलीफोन कैसे काम करता है”
- यह इस बात का प्रतीक है कि जटिल तकनीकी सिस्टम मानव की पूर्ण समझ से परे होते हैं
तकनीकी इंटरव्यू और ‘ज्ञान की सीमा’
- लेखक ने Netflix में काम करने के समय Brendan Gregg के साथ हुई बातचीत को याद किया
- Gregg ने कहा कि इंटरव्यू में वे उम्मीदवारों की ज्ञान की सीमा और उस पर उनकी प्रतिक्रिया का आकलन करते थे
- वे इस आधार पर इंटरव्यू लेते थे कि “कोई भी पूरे सिस्टम को पूरी तरह नहीं समझता”
- यह दृष्टिकोण दिखाता है कि जो नहीं पता उसे स्वीकार करने का रवैया तकनीकी क्षमता जितना ही महत्वपूर्ण है
जटिलता का स्वभाव और AI का प्रभाव
- Wardley, Jacob, Perens, और Bucciarelli के विचार अलग-अलग स्तरों पर जटिलता की अनिवार्यता को उजागर करते हैं
- Wardley: समझ के बिना निर्माण का जोखिम
- Jacob: AI से आई दक्षता और दूरी
- Perens: पहले से मौजूद जटिलता की वास्तविकता
- Bucciarelli: पूरे सिस्टम को समझ पाना असंभव
- लेख मानता है कि AI इस समस्या को और गंभीर बनाएगा, लेकिन साथ ही यह भी याद दिलाता है कि आंशिक समझ के साथ तकनीक से निपटना मानव की बहुत पुरानी वास्तविकता रही है
पाठक चर्चा का सार
- टिप्पणियों में यह चिंता प्रमुख रही कि AI सीखने और समझ को कमजोर कर रहा है
- कुछ लोगों ने कहा कि “LLM जब code लिखने लगता है, तो समझ की श्रृंखला टूट जाती है”
- Wardley ने समझाया कि “पहले समझ एक पदानुक्रमित chain के भीतर बनी रहती थी, लेकिन LLM उस chain को हटा देता है”
- अन्य पाठकों ने यह तर्क दिया कि “AI के फायदे जोखिमों से बड़े हैं” ऐसा मान लेना जल्दबाज़ी होगी
- कुल मिलाकर, AI युग में तकनीकी समझ का क्षय और सीखने में टूटन मुख्य चर्चा बिंदु के रूप में उभरे
1 टिप्पणियां
Hacker News की राय
आजकल programming में जो बात परेशान करती है, वह है कि ‘middle-layer development’ बढ़ रहा है, जहाँ लोग ऊपर की परत (product का purpose) भी नहीं जानते और नीचे की परत (implementation कैसे काम करती है) भी नहीं
पहले business न भी पता हो, तब भी code का मतलब समझ में आता था, लेकिन अब ऐसा माहौल है कि code कैसे काम करता है, यह भी न पता हो तो चलता है
Claude का इस्तेमाल करते-करते लगता है कि मेरी situational awareness धीरे-धीरे कम हो रही है। Test pass हो जाएँ और button दब जाए तो काम खत्म — ऐसी development culture में मुझे लगता है कि अब न मेरे लिए कुछ सीखने को बचा है, न योगदान देने को
खासकर बड़ी कंपनियों में transparency कम होती है। Deadline पूरी करने के लिए overtime किया, और बाद में पता चला कि schedule तो मेरे अलावा सबको बताए बिना आगे बढ़ा दिया गया था
अगर मुझे सिर्फ एक साधारण tool की तरह treat किया जाएगा, तो मैं वही भूमिका निभाऊँगा। लेकिन अगर सच में ownership चाहिए, तो decision-making table पर सीट भी चाहिए
पहले repetitive setup work में समय बर्बाद होता था, लेकिन अब मैं सिर्फ core features पर ध्यान दे पाता हूँ। इसकी वजह से दिमाग में पूरे structure को बेहतर तरीके से बनाए रख सकता हूँ
जैसे IDE में कुछ lines select करके आवाज़ से कहा जाए, “इस हिस्से को ऐसे बदल दो,” और वह तुरंत reflect हो जाए
अगर speed पर्याप्त तेज़ हो, तो mouse + voice control एक शानदार accessibility tool भी बन सकता है
मुझे लगता है LLM उल्टा इस complexity को कम भी कर सकता है। मुझे उचित abstraction पसंद है, लेकिन अंदर क्या है यह बिल्कुल न जानना पसंद नहीं
यह लेख उस phenomenon के बारे में है जिसमें लोग अंदरूनी चीज़ें जाने बिना abstraction का इस्तेमाल करते हैं
लेकिन यह विकास की एक स्वाभाविक प्रक्रिया है। किसी ने वह abstraction design किया और उसे ऊपर की परत के लोग इस्तेमाल कर सकें, ऐसा बनाया
“मुझे Wi-Fi driver नहीं पता, इसलिए code भी समझना ज़रूरी नहीं” — यह तर्क सही नहीं है
पहले लोग ‘ज़रूरी complexity’ को सीधे संभालते हुए अपनी सोचने की क्षमता विकसित करते थे, लेकिन अब कई बार वे सिर्फ pipe की भूमिका तक सीमित रह जाते हैं
समाधान यह है कि general-purpose language के बजाय abstraction को DSL(डोमेन-विशिष्ट भाषा) में wrap किया जाए। SaaS के मामले में API-first से ज़्यादा DSL-first approach बेहतर लगती है
मुझे नहीं लगता AI उससे भी बदतर है। असली बात यह है कि जिन abstractions पर आप टिके हैं, उन्हें समझना ज़रूरी है
Dependency tree वास्तव में सबसे बड़ी समस्या पैदा करता है
सिर्फ Node.js projects को ही देख लें, उनमें सैकड़ों dependent packages होते हैं। ज़्यादातर मामलों में अंदर की details न जानना ठीक है, लेकिन जब interfaces बार-बार टूटते हैं तो यह खतरनाक हो जाता है
कई teams EOL(समर्थन समाप्ति) या vulnerabilities को track ही नहीं करतीं। हक़ीक़त यह है कि कई बार यह भी नहीं पता होता: “क्या यह अभी भी maintain हो रहा है?”
लेकिन AI से पहले भी version conflicts की वजह से बहुत से projects dependency hell में फँसे हुए थे
लोगों को सब कुछ जानने की ज़रूरत नहीं, लेकिन बुनियाद खो देने वाली अज्ञानता खतरनाक है, ऐसा मुझे लगता है
खाना पकाने का उदाहरण लें: गेहूँ उगाना ज़रूरी नहीं, लेकिन अगर अंडा तलना भी न आता हो तो समस्या है
अगर कंपनियाँ हर खाना standardize करके पकाकर दें, तो सवाल यह है कि वह प्रगति होगी या गिरावट
अगर कभी robots पूरी तरह food production को replace कर दें, तो cooking methods न जानना शायद मायने नहीं रखेगा
क्या dependency से बचने के लिए materials science तक जानना ज़रूरी है?
CPU instructions और cache जैसी lower layers दशकों से अच्छी तरह verified और documented हैं
दूसरी ओर LLM द्वारा बना code उतना भरोसेमंद नहीं है, और हो सकता है कि कल ही उसे refactor करना पड़े
मुझे lower-layer details न भी पता हों, फिर भी मैं यह समझता हूँ कि मेरा code कैसे काम करता है
नीचे की परत को न जानना और अपने जिम्मेदारी के दायरे को न जानना — ये दोनों पूरी तरह अलग बातें हैं
अब असली ख़तरा यह है कि ऐसे code fragments बन रहे हैं जिन्हें कोई नहीं समझता
मैं इस बात से सहमत नहीं कि AI स्थिति को और बदतर बना रहा है
उल्टा, LLM ने लगभग हर तरह का ज्ञान सीखा हुआ है, इसलिए “telephone कैसे काम करता है?” जैसे सवालों का व्यवस्थित तरीके से explanation दे सकता है
इंसानों की सीमा यह है कि वे कई बार यह भी नहीं जानते कि उन्हें क्या नहीं पता, लेकिन LLM भाषा में व्यक्त लगभग हर ज्ञान-क्षेत्र को छू लेता है
बेशक reasoning या code generation में उसकी कमज़ोरियाँ हैं, लेकिन knowledge integration की क्षमता इंसानों से बेहतर है
वह असली documentation की जगह नहीं ले सकता। हाँ, इंसानों की तरह “क्या खोजकर देखना चाहिए” यह बताने में वह बहुत उपयोगी है
अच्छा design वही है जो पूरे सिस्टम को जाने बिना भी सिस्टम को चलने दे
समस्या AI द्वारा बनाए गए systems नहीं हैं, बल्कि यह है कि हम अभी तक उनके failure modes और limits को अच्छी तरह नहीं समझते
आखिरकार, इंसान और AI को कैसे समन्वित करके ज़रूरी systems बनाए जाएँ — यही organizational design capability असली कुंजी है
मैं computer के अंदरूनी हिस्सों को पूरी तरह नहीं जानता, लेकिन practical script automation से समस्याएँ हल कर लेता हूँ
x86 assembly पढ़े बिना भी Python से infrastructure manage किया जा सकता है
लेकिन मेरा मानना है कि अनुभवी developers की जिम्मेदारी है कि वे यह ज्ञान share करें। मैं भी कभी न कभी यह भूमिका निभाना चाहता हूँ
जिज्ञासा मत खोइए, और senior developers से सक्रिय रूप से बातचीत कीजिए
लेकिन foundational understanding के महत्व को जितना भी ज़ोर देकर कहो, उसे नज़रअंदाज़ कर दिया जाता है — यही बात खलती है
“जब URL दर्ज करते हैं तो क्या होता है?” जैसे सवाल का मैं सचमुच जवाब दे सकता हूँ
मैंने अमेरिकी नौसेना में submarine reactor technician के रूप में काम किया है, जहाँ electronics theory से लेकर system troubleshooting तक सीखा
बाद में IT में आने के बाद भी, उसी रवैये से documentation और experiments के सहारे आख़िर तक गहराई में जाता रहा
इस आदत की वजह से problem solving में बेतरतीब ज्ञान के connections बहुत मददगार साबित होते हैं
VMEbus wiki document भी देखने लायक है
बस, मैं जो नहीं जानता उसे सहन नहीं कर पाता, इसलिए शायद मैं थोड़ा अपवाद हूँ