पश्चिम चीज़ें बनाना भूल गया था, और अब वह कोड भी भूल रहा है
(techtrenches.dev)- रक्षा-उत्पादन क्षमता का पतन यह दिखाता है कि जब रिटायर हो चुके कुशल कर्मी और गायब हो चुका process knowledge टूट जाता है, तो युद्धकालीन मांग आने पर भी उत्पादन को तेज़ी से फिर शुरू नहीं किया जा सकता
- Stinger, 155mm shells, और Fogbank की बहाली के मामले दिखाते हैं कि cost optimization और single point of failure ने शांतिकाल में efficiency तो बढ़ाई, लेकिन supply chain की breathing room और recovery speed को बहुत कमज़ोर कर दिया
- सॉफ्टवेयर भी सस्ते विकल्पों पर निर्भर होकर talent pipeline को कमज़ोर करने वाले रास्ते पर बढ़ रहा है, और AI अपनाने के बाद junior hiring में कटौती और review bottleneck दोनों साथ में बढ़ रहे हैं
- कौशल सिर्फ पैसे से जल्दी नहीं बनाया जा सकता, और रक्षा उद्योग तथा सॉफ्टवेयर—दोनों में ज्ञान और कौशल का संचय करने के लिए वर्षों का on-the-job experience और review क्षमता चाहिए
- अगर junior इंजीनियर formative mistakes और debugging के दौर से नहीं गुजरते, तो tacit knowledge जमा नहीं होता, जिससे आगे चलकर senior engineers और institutional knowledge की कमी का जोखिम बढ़ता है
रक्षा-उत्पादन क्षमता के पतन और सॉफ्टवेयर workforce में कटौती के बीच समानता
- Raytheon को Stinger उत्पादन फिर शुरू करने के लिए 70 की उम्र के इंजीनियरों को वापस बुलाना पड़ा, और पुराने कागज़ी blueprints तथा गोदाम में पड़े test equipment के आधार पर process को फिर से जीवित करना पड़ा
- Pentagon ने 20 साल तक नए Stinger नहीं खरीदे थे, लेकिन यूक्रेन युद्ध के बाद मांग अचानक बढ़ गई; तब तक production line बंद थी, electronic components और seeker discontinued हो चुके थे, और मई 2022 के orders भी 2026 में ही deliver होने वाले थे
- युद्ध के सिर्फ 10 महीनों में 13 साल के Stinger उत्पादन के बराबर stock खर्च हो गया, और पहले ही गायब हो चुके production knowledge तथा workforce gaps बड़े bottleneck बनकर सामने आए
- यह सिर्फ budget की समस्या नहीं थी; असली बाधा वह संरचना थी जिसमें रिटायर हो चुके skilled workers के बाद replacement workforce तैयार ही नहीं की गई
गोला-बारूद उत्पादन बढ़ाने में विफलता ने supply chain की कमज़ोरी उजागर की
-
10 लाख shells के वादे और वास्तविक उत्पादन क्षमता
- EU ने मार्च 2023 में यूक्रेन को 12 महीनों के भीतर 10 लाख artillery shells देने का वादा किया था, लेकिन यूरोप की वार्षिक उत्पादन क्षमता लगभग 2.3 लाख shells थी, जबकि यूक्रेन रोज़ 5,000~7,000 shells खर्च कर रहा था
- deadline तक यूरोप लगभग आधी supply ही दे पाया, और 9 देशों के 11 मीडिया संस्थानों की जांच में वास्तविक उत्पादन क्षमता EU के आधिकारिक दावों की लगभग एक-तिहाई निकली
- 10 लाख shells का लक्ष्य दिसंबर 2024 तक खिसक गया, यानी मूल वादे से 9 महीने की देरी
-
कई bottlenecks का एक साथ जुड़ा ढांचा
- France ने 2007 में घरेलू propellant production बंद कर दिया था, और वह 17 साल तक रुका रहा
- यूरोप में TNT का प्रमुख उत्पादन सिर्फ Poland में था, और Germany के ammunition stock सिर्फ दो दिनों के लिए पर्याप्त थे
- Denmark की Nammo factory 2020 में बंद हो गई थी, और उसे लगभग शुरुआत से फिर चालू करना पड़ा
- यूरोप का defense industry कम मात्रा वाले महंगे customized products के लिए optimized था; इसे mass production या crisis response को ध्यान में रखकर design नहीं किया गया था
-
अमेरिका में भी इसी तरह की कमज़ोरी
- अमेरिका भी Scranton की एक factory, Iowa की एक explosives-filling facility पर निर्भर था, और 1986 के बाद से घरेलू TNT production बंद था
- अरबों डॉलर लगाने के बाद भी उत्पादन लक्ष्य के आधे तक नहीं पहुंच पाया
cost optimization ने single point of failure बनाए
- 1993 में Pentagon ने defense CEOs को संदेश दिया कि consolidate करो, नहीं तो खत्म हो जाओ, और उसके बाद 51 बड़े defense contractors घटकर 5 रह गए
- tactical missile suppliers 13 से घटकर 3 रह गए, shipbuilders 8 से 2, और workforce 32 लाख से 11 लाख पर आ गई—यानी 65% की गिरावट
- ammunition supply chain के कई हिस्सों में single point of failure बन गए, और 155mm shell bodies का निर्माण California के Coachella की सिर्फ एक company पर केंद्रित हो गया
- propellant charges भी Canada की एक ही facility पर निर्भर हो गए; minimum-cost optimization ने शांतिकाल में efficiency बढ़ाई, लेकिन demand spike के लिए लगभग कोई spare capacity नहीं छोड़ी
जब ज्ञान खो जाता है, तो recovery भी धीमी हो जाती है
-
Fogbank की बहाली में विफलता
- Fogbank एक गोपनीय material है जो nuclear warheads में इस्तेमाल होता है; इसका उत्पादन 1975 से 1989 तक हुआ और फिर facility बंद कर दी गई
- 2000 में life-extension program के लिए इसे फिर बनाने की कोशिश हुई, लेकिन production expertise रखने वाले अधिकांश लोग रिटायर हो चुके थे, मर चुके थे या संस्थान छोड़ चुके थे, और रिकॉर्ड भी लगभग नहीं बचे थे
- GAO से संबंधित विवरण के अनुसार, 6.9 करोड़ डॉलर अतिरिक्त और कई वर्षों की reverse engineering के बाद ही दोबारा producible Fogbank हासिल किया जा सका
-
दस्तावेज़ों में न होने वाला tacit knowledge निर्णायक था
- नए सिरे से बनाया गया Fogbank बहुत ज़्यादा pure था, और बाद में पता चला कि मूल batch में मौजूद अनचाही impurities ही उसके वास्तविक कामकाज के लिए महत्वपूर्ण थीं
- यह जानकारी किसी दस्तावेज़ में नहीं थी; इसे सिर्फ मूल उत्पादन पर काम करने वाले workers जानते थे, जो तब तक रिटायर हो चुके थे
- अपने ही बनाए material को फिर से न बना पाने की वजह यह थी कि ज्ञान सिर्फ लोगों के पास बचा था
सॉफ्टवेयर भी उसी रास्ते पर बढ़ रहा है
-
सस्ता और तेज़ विकल्प talent pipeline को कमज़ोर करता है
- दशकों में बनाई गई क्षमता को सस्ते विकल्प से बदलना, human talent pipeline को कमज़ोर करना, और फिर संकट के समय उसी हटाई गई क्षमता की ज़रूरत पड़ना—यह पैटर्न रक्षा उद्योग और सॉफ्टवेयर दोनों में दिखता है
- रक्षा उद्योग में यह विकल्प peace dividend था, तो सॉफ्टवेयर में AI वही जगह ले रहा है
- पहले से मौजूद talent pipeline collapse और comprehension crisis पहले ही दिख रहे थे, और रक्षा उद्योग के उदाहरण यह भी दिखाते हैं कि इसे फिर से बनाने में कितना लंबा समय लगता है
-
rebuilding में पैसे से ज़्यादा समय लगता है
- बड़े defense production ramp-up में simple systems के लिए 3~5 साल और complex systems के लिए 5~10 साल लगे
- Stinger में order से delivery तक कम-से-कम 30 महीने लगते हैं, Javelin में उत्पादन को दोगुने से भी कम बढ़ाने में 4.5 साल लगे, और 155mm shells में 5 अरब डॉलर लगाने के बाद भी 4 साल से लक्ष्य पूरा नहीं हुआ
- France को भी propellant production फिर शुरू करने में 17 साल लगे, और असली constraint funding नहीं बल्कि ज्ञान और कौशल था
- RAND study के अनुसार submarine design skill का 10% हिस्सा PhD के बाद भी 10 साल के field experience की मांग करता है, और defense skilled trades में apprenticeship के 2~4 साल तथा supervisory capability तक पहुंचने के लिए 5~8 साल चाहिए थे
-
सॉफ्टवेयर की growth curve भी compress नहीं होती
- एक junior developer को stable mid-level बनने में 3~5 साल, senior बनने में 5~8 साल, और principal या architect बनने में 10 साल से ज़्यादा लगते हैं
- यह समय सिर्फ ज़्यादा पैसा खर्च करने से कम नहीं होता, और AI से भी इसे compress करना कठिन दिखता है
AI अपनाने के बाद bottlenecks और कौशल क्षरण
-
production speed से ज़्यादा बड़ा review bottleneck
- METR randomized controlled trial में पाया गया कि skilled developers जब AI coding tools का उपयोग करते हैं, तो वास्तविक open source काम उल्टे 19% अधिक समय लेता है
- शुरू में अनुमान था कि AI 24% तेज़ बनाएगा, लेकिन वास्तविक नतीजे से यह अंतर 43 percentage points निकला
- follow-up experiments में ऐसे developers का हिस्सा भी कम नहीं था जिन्होंने कहा कि अगर AI के बिना काम करना पड़े तो वे भाग नहीं लेंगे, और AI-रहित काम पर लौटने की कल्पना भी आसान नहीं लगती
-
hiring cuts और university enrollment में गिरावट
- Salesforce ने कहा कि वह 2025 में अतिरिक्त software engineers hire नहीं करेगा
- LeadDev survey में 54% engineering leaders ने माना कि AI copilots लंबी अवधि में junior hiring को कम करेंगे
- CRA survey में 62% university computing departments ने इस साल enrollment गिरने की रिपोर्ट दी
-
code review मुख्य constraint बन रहा है
- AI तेज़ी से code generate करता है, लेकिन human review धीमा रहता है, जिससे review bottleneck बनता है
- इसके जवाब में AI को AI के code की समीक्षा करने देने के बजाय pull request templates में change summary, change reason, change type, और before/after screenshots को अनिवार्य किया जा रहा है
- project-specific dedicated reviewers जोड़कर मॉडल से छूट गई चीज़ों को ज़्यादा लोगों की नज़र से पकड़ने की कोशिश भी की जा रही है
आगे किस क्षमता की कमी होगी
-
सिर्फ technical skill अब पर्याप्त नहीं
- अब सिर्फ technical expertise काफी नहीं है; ज़िम्मेदारी लेना, trade-offs समझाना, और मशीन के confidence से दिए गए गलत सुझावों को ठुकरा सकने वाली judgment और leadership भी उतनी ही ज़रूरी हैं
- हाल की hiring में 2,253 applicants में से 2,069 reject हुए और सिर्फ 4 hire किए गए; conversion rate 0.18% था
- इससे यह हकीकत सामने आती है कि technical skill के साथ AI की गलतियों को पहचानने वाली judgment रखने वाला talent बाज़ार में लगभग नहीं है
-
सिर्फ documentation से knowledge transfer पूरा नहीं होता
- Site Books, SDDs, RVS reports, और full coverage वाले boilerplate modules तक का व्यापक documentation किया जा रहा है
- अभी यह इसलिए काम कर रहा है क्योंकि इन documents को पढ़ने वाले लोगों के पास engineering expertise है, लेकिन जब वही expertise खत्म होगी तब यही तरीका काम करेगा या नहीं, यह अनिश्चित है
- 2031 के model performance का अनुमान नहीं लगाया जा सकता, और यह भी तय नहीं कि AI इतना अच्छा हो जाएगा कि समस्याएँ कम पैदा करे
-
संकट बिना चेतावनी आता है, और senior तुरंत नहीं बनते
- जैसे 2022 में यूरोप में full-scale war की उम्मीद बहुत कम लोगों ने की थी, वैसे ही संकट कैलेंडर देखकर नहीं आते
- 5~10 साल बाद ऐसे senior engineers की ज़रूरत होगी जो पूरे system को समझें, रात 2 बजे distributed outage debug कर सकें, और codebase के बाहर की institutional knowledge भी संभाल सकें
- लेकिन ऐसे लोग अभी तैयार नहीं हो रहे; जिन juniors को सीखना चाहिए, वे या तो hire ही नहीं हो रहे, या DoD-funded research के शब्दों में AI-mediated competence जमा कर रहे हैं
- AI को prompt देना भले बना रहे, लेकिन AI कहाँ गलत है यह पकड़ने की क्षमता शायद विकसित ही न हो
कोड का Fogbank बनने का जोखिम
- अगर junior engineers debugging और शुरुआती दौर की गलतियों को छोड़ देते हैं, तो tacit knowledge जमा नहीं होता, और मौजूदा पीढ़ी के इंजीनियरों के रिटायर होने पर यह ज्ञान AI में transfer नहीं होगा
- नतीजतन यह ज्ञान बस गायब हो सकता है, और इसकी संरचना Fogbank वाली घटना से मिलती-जुलती है
- यूक्रेन युद्ध वह क्षण था जब defense optimization की विफलता की वास्तविक कीमत सामने आई, और Stinger, Javelin, Fogbank, तथा 10 लाख shells न बना पाना उसी कीमत को दिखाते हैं
- software engineering भी उसी optimization पर दांव लगा रही है; अगर AI पर्याप्त अच्छा हो गया तो यह दांव सही साबित हो सकता है, लेकिन अगर ऐसा नहीं हुआ, तो वही बिल यहां भी लौट सकता है
1 टिप्पणियां
Hacker News की राय
असली समस्या AI खुद नहीं है
समस्या उस मैनेजमेंट तरीके में है जो तुरंत मुनाफा नहीं बनाता कहकर लोगों और संगठनों से फुर्सत छीन लेता है, और फिर मान लेता है कि बाद में ज़रूरत पड़ने पर भी वह ज्ञान बचा रहेगा
अल्पकालिक लागत कटौती junior hiring कम कर देती है, और skilled engineers के पास सिखाने की गुंजाइश भी खत्म कर देती है, जिससे tacit knowledge transfer टूट जाता है
आखिर में सिर्फ documents और automation बचते हैं, लेकिन documents ज़मीनी अनुभव नहीं होते और automation निर्णय क्षमता की जगह नहीं ले सकता
जब वास्तव में system संभाल चुके लोग हट जाते हैं, तो tacit knowledge संगठन से गायब हो जाती है और productivity भी आखिरकार गिरती है
अभी AI भी इसी pattern में बेचा जा रहा है, और कई क्षेत्रों में जो चीज़ चाहिए वह productivity improvement से ज़्यादा headcount reduction के करीब लगती है
यह उसी सोच जैसा लगता है जिसमें GE ने quarterly results और shareholder returns को maximize करते-करते अपनी long-term capability खोखली कर दी थी
असली engineering से दूर बैठे decision-makers मानते हैं कि tools, process, और documents से tacit knowledge को replace किया जा सकता है, लेकिन ऐसा नहीं है
लोगों और learning pipeline को हटा देंगे तो वह ज्ञान संगठन में नहीं टिकता, बस गायब हो जाता है
experimentation, repair, या shock absorb करने के लिए कोई slack नहीं छोड़ा जाता, और आजकल टूटे हुए systems में से 90% शायद इसलिए टूटते हैं क्योंकि उनमें short-term shocks झेलने की गुंजाइश ही नहीं होती
startup projects में शुरुआत से ही कुछ न कुछ लगातार बनाना पड़ता है, इसलिए और features बनाना ही value बन जाता है, लेकिन Visa, Salesforce, LinkedIn जैसी कंपनियों के पास अक्सर पहले से ही products, features, और resources पर्याप्त होते हैं
ऐसी कंपनियाँ अक्सर write more software नाम के हथौड़े के लिए ज़बरदस्ती कील ढूंढती हुई लगती हैं
wishlist और A/B testing systems बहुत दिखते हैं, लेकिन अगर सच में और software बनाने से पैसे कमाने के मौके इतने साफ़ होते, तो शायद वे पहले ही कर लिए गए होते
असली growth और नई demand अक्सर इन जगहों के बाहर से आती है, और वे कंपनियाँ जिनके पास software बनाने या खरीदने की क्षमता कम है, वही कभी-कभी मौका पकड़ सकती हैं
और यहाँ मुख्य बात fungibility है
human capital कोई ऐसी चीज़ नहीं है जिसे आसानी से repackaging कर दें; वह एक जीवित चीज़ है, और talent व skill pipeline एक बार टूट जाए तो सचमुच गायब हो सकती है
AI coding का खतरा भी यही है कि यह मौजूदा human capital को बस खींचकर इस्तेमाल करता है, लेकिन future के लिए नया human capital तैयार नहीं करता
जिन systems का knowledge मेरे पास है, उसका बड़ा हिस्सा documentation में डाला जा सकता है, और सैद्धांतिक रूप से सिर्फ उन documents के आधार पर कोई नया व्यक्ति handover ले सकता है
लेकिन समस्या यह है कि जितना documentation चाहिए, उसकी मात्रा बेहिसाब है
छोटे system के लिए भी ठसाठस भरे हुए A4 के दसियों हज़ार पन्ने वास्तविक अनुमान लगते हैं
नए owner को उस भारी documentation का लगभग सब कुछ रटने जैसी समझ बनानी पड़ेगी, और कंपनियाँ न तो ऐसे documents लिखने की लागत देना चाहती हैं, न नए लोगों की learning cost
मेरे अनुभव में इसलिए यह नहीं होता; ऐसा नहीं कि सिद्धांत रूप में यह बिल्कुल असंभव है
हम धीरे-धीरे दूसरे लोगों से बात करने की वजहें खत्म कर रहे हैं
जैसे ही आप AI से सवाल पूछते हैं, एक मानवीय interaction कम हो जाता है जो पहले किसी सहकर्मी से होता
यह सिर्फ coding की समस्या नहीं है; जेब में हमेशा ChatGPT होने से कौन-कौन से social interactions replace हो रहे हैं, इस पर सोचना पड़ता है
इंसान मूलतः सामाजिक प्राणी है, लेकिन हम socialization को जितना हो सके optimize करके हटाते जा रहे हैं
मैं भी इस trend से बाहर नहीं हूँ, क्योंकि पहले की तरह restaurant में फोन करने के बजाय Doordash prefer करता हूँ
आदर्श दुनिया में companies को short-to-medium-term profit optimize करना चाहिए, governments को long-term benefit, और individuals को पूरे जीवनकाल का संतुलन
अगर companies slack घटाकर सब कुछ कसा हुआ चलाएँ, तो governments को regulation के ज़रिए वह गुंजाइश और talent inflow बनाए रखना चाहिए ताकि national capability बची रहे
लेकिन पश्चिम में लगता है कि lobby groups और MBA लोग companies को नियंत्रित कर रहे हैं, और governments को भी सिर्फ पैसे optimize करने की दिशा में खींच रहे हैं
मैं रोज़ coding assistant के बिना code इसलिए लिखता हूँ क्योंकि मुझे लगता है कि ऐसा करने से हाथ से करने की संवेदना बनी रहती है, छोटी-छोटी चीज़ों तक
AI का इस्तेमाल न करने का सबसे बड़ा कारण यह है कि screen के सामने बैठा हूँ तो जहाँ तक हो सके किसी भी चीज़ पर निर्भर नहीं होना चाहता
हाँ, documents, books, Stack Overflow जैसी चीज़ें अलग हैं
अपने आसपास मैं अक्सर ऐसे लोगों को देखता हूँ जो मामूली रोज़मर्रा के कामों तक के लिए AI पर टिके रहते हैं, और यह काफ़ी डरावना लगता है क्योंकि इसका मतलब है कि सोचने की मेहनत बहुत कम हो रही है
उस mental effort को छोड़ देना कोई छोटी बात नहीं है
मुझे तो लगता है कि वह छोड़ते ही मैं एक dependent zombie बन जाऊँगा, और मेरे हिसाब से knowledge लगभग रोज़ होने वाले trial and error से ही आता है
technology ने हमेशा दिखाया है कि वह इंसानों को धकेल और नियंत्रित कर सकती है, और AI dependence मुझे उसका अंतिम रूप लगती है, जहाँ कंपनियाँ इंसान की सबसे नाज़ुक क्षमता यानी सोचने और जिज्ञासु होने की शक्ति तक में घुसपैठ कर रही हैं
ज़्यादातर समय confusion और frustration में बीता, और करीब 7 घंटे जूझने के बाद काम पूरा हुआ
लेकिन वह कठिनाई खुद इतनी चौंकाने वाली थी कि मुझे चिंता होने लगी कि कहीं इस्तेमाल न करने से मेरा दिमाग थोड़ा सड़ तो नहीं गया
फिर याद आया कि नए problems हल करना पहले भी हमेशा ऐसा ही कठिन होता था
पहली बार दिखने वाली समस्या से भिड़ने का अनुभव मूल रूप से इतना ही कठिन होता है, बस मैं उस एहसास का अभ्यस्त नहीं रहा था
अगर आप कठिनाई के आदी हो जाएँ तो वह सामान्य लगती है, और अगर बिना कठिनाई की स्थिति के आदी हो जाएँ तो दोबारा उससे सामना होने पर वह overwhelming और अजीब लगती है
इसलिए मुझे लगता है कि असुविधा और कठिनाई झेलने की क्षमता एक ऐसी muscle है जिसे बचाकर रखना चाहिए
यह वास्तविक समस्या बस तब बनती थी जब नई नौकरी में grammar checker या autocomplete के बिना platform पर interview code लिखना होता था, इसलिए मैं पहले से ऐसे environment में practice करता था
practical काम में syntax autocomplete पर निर्भरता कभी बड़ी समस्या नहीं बनी, और असल बात language के core concepts और runtime की समझ थी
जैसे Node.js का event loop कैसे काम करता है, asynchronous और event-based programs कैसे लिखे जाते हैं — यह ज़्यादा महत्वपूर्ण था
पिछले 6 महीनों में deploy किए गए code में शायद ही कुछ ऐसा होगा जिसकी एक भी line मैंने खुद पढ़ी हो
लेकिन उस तरह काम करना कहीं ज़्यादा थकाऊ है
हाथ से code लिखते समय problem solving एक puzzle जैसा होता था, और हल होने पर satisfaction loop और dopamine reward मिलता था
अब दिन का ज़्यादातर हिस्सा puzzle solver नहीं बल्कि QA staff जैसा महसूस होता है, और यह बहुत draining है
AI अगर कठिन problem हल भी कर दे, तब भी LLM slot machine से मिलने वाली satisfaction, खुद हल करने से कहीं कम है
बाकी दो दिन coding assistant नहीं लेता, और काम खत्म होने के बाद सिर्फ review करवाता हूँ
मुझे लगता है यह तरीका mental health के लिए भी अच्छा है और skill की धार भी बनाए रखता है
चाहे किसी language में काफ़ी अच्छा रहा हूँ, उसके mechanical हिस्से जल्दी धुंधले पड़ जाते हैं
इसलिए LLM-assisted work मुझे अपने दिमाग पर bleach उड़ेलने जैसा लगता है
मैं खुद महसूस कर सकता हूँ कि जितना ज़्यादा इस्तेमाल करूँगा, मेरे लिए उतना बुरा होगा
चीज़ों को structure करना और problem solving अब भी ठीक है, लेकिन असली nuts and bolts बहुत जल्दी उड़ जाते हैं
यह पंक्ति कि पैसा constraint नहीं था, knowledge constraint था विडंबनापूर्ण लगती है
वजह यह है कि लेख खुद इतना AI द्वारा लिखा हुआ-सा लगता है कि पढ़ना मुश्किल हो जाता है
flow अजीब है, झटकों में टूटता है, और LLM के खास तरह के तकिया-कलाम भरे पड़े हैं
writing ability भी आखिरकार एक ऐसी skill है जो क्षीण हो सकती है
language fluency के लिए AI इस्तेमाल करना समझ आता है, लेकिन generated writing से तो मुझे AI translation बेहतर लगती है
अगर लेखक को खुद लिखने जितनी परवाह भी नहीं थी, तो मुझे उसे पढ़ने की वजह भी कम दिखती है
मेरे लिए code और prose मूल रूप से इतने अलग नहीं हैं
दोनों keywords, grammar, syntax, और अर्थपूर्ण combinations से बने होते हैं
अगर AI के बनाए वाक्य बेमानी या पढ़ने में मुश्किल हैं, तो उसी logic से AI-generated code भी पढ़ने में मुश्किल और भरोसे के लायक़ नहीं होना चाहिए
यह double standard अब थोड़ा बंद होना चाहिए
बल्कि HN पर जो AI बकवास लोग अक्सर अच्छा कहकर आगे बढ़ा देते हैं, उससे यह कहीं बेहतर था
इसलिए जिन बातों को लोग LLM की खास शैली समझते हैं, उनमें से कुछ वास्तव में ऐसी भी हो सकती हैं जो इंसानों ने पहले लिखीं और अब वही शैली इंसानों के हाथों दोहराई जा रही है
web search के ऊपर आने वाले AI-generated लेख मैं रोज़ कई देखता हूँ और तुरंत skip कर देता हूँ, लेकिन यह लेख उस category से काफ़ी अलग लगा
यह मानना मुश्किल लगता है कि कंपनियाँ developers के experience level का सही अंदाज़ा लगा पाती हैं
junior, mid, senior, lead जैसी categories बाहरी लेबल भर हैं; असल में यह कई dimensions पर फैला continuum है और trendy technologies से आसानी से distort हो जाता है
सख़्ती से कहें तो किसी company में employed हुए बिना भी कोई senior-level developer बन सकता है
अंततः मुख्य चीज़ है खुद सीखने और बनाने की इच्छा, और उसमें लगाया गया समय
आजकल कंपनियों को असल में developer skill से ज़्यादा यह चाहिए लगता है कि किसी ने टूटे हुए organizational structure और कमज़ोर communication या budget structure को किसी तरह bypass करके काम निकाला हो
पता नहीं इसे senior होना कहें या सिर्फ politics में माहिर होना
जब software fail होता है और भ्रम टूटता है, तब यह pattern खास तौर पर साफ़ दिखता है
एक वे जो समस्या मिलने पर जो ज़रूरी हो वह खुद सीख लेते हैं, जो नहीं जानते उसमें गहराई तक जाते हैं, meaningful results बार-बार देते हैं, ज़रूरी लोगों से बात करते हैं, progress share करते हैं, टीम में मदद लेते-देते हैं, और जो कमी दिखे उसे पहले से भरने की कोशिश करते हैं
बाकी बस बाकी हैं
career के शुरुआती कुछ सालों में आम तौर पर साफ़ हो जाता है कि कौन किस category में है, और दूसरी category के लोगों को पहली category में बदलना लगभग असंभव होता है
इसलिए 30 साल का senior भी दूसरी category का हो सकता है, और अभी graduate हुआ व्यक्ति भी पहली category का
हाँ, कुछ लोग politics, interpersonal skill, या bluffing में इतने अच्छे होते हैं कि management की नज़र में पहली category जैसे दिखते हैं, जबकि वास्तव में दूसरी category के होते हैं
लेकिन तब बात software बनाने की क्षमता की नहीं रह जाती
और पहली category में होने पर भी व्यक्ति undervalued रह सकता है या promotion न पा सकता है, इसलिए असली career success से इसका correlation बहुत बड़ा नहीं है
आप खुद पर कोई भी label लगा सकते हैं, लेकिन वह थोड़ा अजीब ही है
freelancers का मूल्यांकन portfolio से, academic computer scientists का papers से, और OSS contributors का उनकी contributions और impact से होता है
हर मामले में बात आखिरकार learning और building में लगाए गए effort पर ही लौटती है
लेकिन employment से अलग होकर भी expertise सिर्फ उन चीज़ों से तय नहीं होती जो books से सीखी जा सकें
stakeholder management या किसी solution को प्रस्तुत करना जैसी चीज़ें सिर्फ पढ़कर नहीं सीखी जातीं; उन्हें practice और feedback चाहिए
senior engineer सिर्फ अच्छा code लिखने वाला नहीं होता, बल्कि SDLC के पूरे दायरे में खुद योगदान दे सके और दूसरों की भी मदद कर सके — और ऐसी क्षमता amateur projects की तुलना में professional environment में कहीं आसानी से विकसित होती है
इसमें आम तौर पर social और organizational skills चाहिए होते हैं, और पसंद आए या नहीं, दुनिया अक्सर ऐसे ही चलती है
साथ ही मैं चाहता हूँ कि ऐसी चीज़ों को जितना हो सके न जानूँ
किसी और के हिसाब से अपना दिमाग उधेड़कर ढालना नहीं चाहता, और इस तरह की समस्याओं के बीच काम करना शुद्ध पीड़ा जैसा है
यह कुछ वैसा है जैसे पूछना कि बिना employed हुए कोई surgeon senior surgeon बन सकता है क्या
कई साल तक इसे वास्तविक पेशे की तरह किए बिना senior बनना मुश्किल है, और इस field में तो experience ही लगभग सब कुछ है
books से ज़रूरी समझ भीतर तक नहीं उतरती, और इंसान सिर्फ पढ़ने या देखने से चीज़ें पर्याप्त रूप से internalize नहीं करता
खुद करके देखना पड़ता है, तभी असली सीख मिलती है
facts और techniques books से सीखी जा सकती हैं, लेकिन सिर्फ Michelin restaurant पर किताब पढ़ लेने से कोई Michelin Chef नहीं बन जाता
AI code generators troll जैसे लगते हैं
वे आत्मविश्वास से भरी, plausible लेकिन आंशिक रूप से ग़लत बातें उगलते हैं, और आखिरकार इंसान को उनकी गलतियाँ पकड़नी पड़ती हैं
इसमें न मज़ा है, न flow
मुझे दूसरों की गलतियाँ ठीक करना पसंद है, और खासकर LLM को हराने का एहसास अच्छा लगता है
पारंपरिक deep focus की तुलना में मैं LLM पर लगातार नज़र रखते हुए और ज़्यादा देर तक केंद्रित रह पाया
उसमें logic नहीं, सिर्फ pattern repetition है, और समझ नहीं आता कि इतने smart engineers उसमें फँस कैसे जाते हैं
यह थोड़ा विडंबनापूर्ण है कि यह लेख खुद भी काफ़ी साफ़ तौर पर AI की मदद से लिखा हुआ लगता है
मैं AI assistance की आलोचना नहीं कर रहा, लेकिन लेख के theme के साथ रखकर देखें तो सोचने लायक बात बनती है
लोग शायद सोचते हैं कि वे लेखन को "polish" कर रहे हैं, लेकिन असल में संभव है कि बिना ऐसा किए लेख ज़्यादा पढ़ने लायक होता
जो चीज़ आजकल खास तौर पर खटकती है, वह है comma की जगह बार-बार full stop ठूँसने वाली sentence style
My people lived the other side of this equation. Not the factory floor. The receiving end.शायद उसका मकसद weight देना होता है, लेकिन जब बिना ज़रूरत हर जगह ऐसा किया जाए तो लगता है जैसे किसी action movie trailer की lines पढ़ रहे हों
नैतिक रूप से AI use अपने-आप में समस्या नहीं है, लेकिन LLM writing style इतनी खटक रही थी कि आगे पढ़ना मुश्किल था
ऊपर से लोग इसका इस्तेमाल text में बेवजह length और filler जोड़ने के लिए करने लगे हैं, तो अब ऐसे लेखों के कई पन्ने पार करने पड़ते हैं
और इससे भी बुरी बात यह है कि यह पहचानने का आसान तरीका नहीं बचा कि लेख कम-से-कम किसी इंसानी नई insight पर आधारित है, या सिर्फ write me something about X prompt से पूरा generate हुआ है
मौजूदा स्तर पर, अगर वह दूसरा मामला हो तो यह मान लेना ग़लत नहीं होगा कि पढ़ने लायक़ value लगभग नहीं है
मुझे यह वैसा लगता है जैसे समलैंगिकता की निंदा करने वाला पादरी किसी male prostitute के साथ बिस्तर में पकड़ा जाए
उसने cocaine ली थी या नहीं, वह वैकल्पिक विवरण है, लेकिन aftertaste कड़वा ही रहता है
इस text में वैसे आम और घिसे-पिटे AI tell बहुत नहीं हैं, और जहाँ तक मुझे दिखता है, LLM जैसी लगने वाली मुख्य चीज़ छोटी और assertive sentence structure है
लेकिन ऐसी शैली तो Hemingway के बाद अंग्रेज़ी लेखन में काफ़ी प्रतिष्ठित भी रही है
मुझे लगता है पहले AI नहीं, बल्कि पूर्वी यूरोप की remote contract development teams को सस्ता विकल्प माना जाता था
शुरुआत से ही पर्याप्त लोग थे ही नहीं
और यहाँ 15 degrees east of longitude के इस पार भी आख़िर में सबको निकाल दिया गया
असली योजना शायद बस इतनी थी कि AI से जुड़ी चीज़ों को छोड़कर बाकी सब में कुल मिलाकर कम किया जाए; लगता है सब बस देख रहे थे कि layoffs पहले कौन शुरू करता है
मैंने 6 महीने तक part-time काम किया, और decision-makers ने साफ़ कहा कि long term में उन्हें यह बेहतर लगता है
layoffs से बेहतर तो था, लेकिन ऐसी ज़िंदगी लगातार नहीं चल सकती थी
मैं मितव्ययी हूँ, पर इतना भी नहीं
वे सचमुच पैसे खर्च नहीं करना चाहते, और खासकर Americans और health insurance पर तो बिल्कुल नहीं
यह अजीब लगता है कि अमेरिकी कंपनियाँ अमेरिकियों को jobs से बाहर धकेलने वाली तेज़ रफ़्तार राह पर हैं और फिर भी इसके सामने बहुत कम रोक-टोक है
एक European होने के नाते मैंने पूर्वी यूरोप के developers भी ज़रूर देखे, लेकिन जिन सभी companies के साथ मैंने काम किया, उनमें वे हर जगह नहीं थे
दूसरी तरफ Indian workforce हमेशा थी
quality के मामले में वही पुरानी कहानी रहती थी; मैं उसे विस्तार से नहीं खोलूँगा, लेकिन जो लोग इसे स्वीकार करने को तैयार हैं, वे समझ जाएंगे कि मैं किस ओर इशारा कर रहा हूँ
80 के दशक के अंत में पहली बार सुनी हुई Formal verification in software की class से लेकर 2000 के शुरुआती वर्षों में छोड़ने से पहले freshmen को पढ़ाई गई Programming in Java class तक, मुझे लगा कि academic rigor किसी खड़ी चट्टान से गिर गया और उसकी जगह job alignment ने ले ली
पहले जो पढ़ाया जाता था वह सोचने का तरीका सिखाने के करीब था, बाद में वह अच्छी तनख़्वाह वाली नौकरी पाने का तरीका बन गया
वजह यह थी कि कंपनियाँ नए employees को train करना अब और नहीं चाहती थीं
trainees की salary और उन्हें सिखाने वालों की लागत — दोनों में पैसा लगता है, इसलिए उन्होंने वह खर्च degree requirements के रूप में universities, students, और governments पर डाल दिया
अगर नौकरी की शर्त के रूप में training cost employee से भरने को कहा जाए तो लोग उसे scam जैसा कहेंगे, लेकिन degree mill system को लोग बहुत आसानी से स्वीकार कर लेते हैं — यह अजीब है
इंसान परफेक्ट नहीं हैं
रूस के invasion से कुछ दिन पहले जब मैं Ukraine गया था, तब Kyiv में travel और hotels काफ़ी सस्ते थे, और जब स्थानीय लोगों से invasion की संभावना पूछी तो सबने कहा नहीं होगा
उनका जवाब यह था कि Russia हमेशा आक्रामक बातें करता है, लेकिन वास्तव में ऐसा नहीं करेगा
तैयारी पर्याप्त नहीं थी, और नतीजा यह हुआ कि कुछ ही दिनों में 20% territory चली गई
Austria लौटने के बाद भी मेरे मन में यह बात अटकी रही कि जिन लोगों से मैं मिला था, उनमें से कुछ शायद मर चुके हों
उसके बाद Dubai और Saudi Arabia में entrepreneur और engineer के रूप में काम करते हुए मैंने पूछा कि अगर drones infrastructure पर हमला करें तो क्या होगा; Russia के युद्ध और Iran के पहले हमले को देखकर तो ऐसे हमले साफ़ तौर पर foreseeable थे
लेकिन फिर वही जवाब मिला: नहीं होगा
ठीक से तैयारी न होने की वजह से सैकड़ों अरब डॉलर का नुकसान हुआ, जबकि मेरा मानना है कि कुछ सालों तक सिर्फ सैकड़ों मिलियन डॉलर खर्च कर दिए जाते, तो इसे रोका जा सकता था
अंततः समस्या AI नहीं, इंसान हैं
अगर तैयारी न होती, तो अब तक Kyiv में रूस का कोई spokesperson बैठा होता
पहले 2 हफ्ते टिक जाना ही long war में बदलने की कुंजी था, और Donbas का युद्ध पहले से 8 साल से चल रहा था
यह कहना मुश्किल है कि Ukrainians को यह भ्रम था कि सामने वाला Russia नहीं है
बाद में पता चलता है कि उनके किसी दोस्त को वह contract चाहिए था, और वे यह डर बेच रहे थे कि दुश्मन घुस आया तो तुम्हारा परिवार तुरंत मर जाएगा
आपने बस ऐसे दो मामले चुने जहाँ किसी ने कहा था कभी नहीं होगा, और फिर वह हो गया
लेकिन उन अनगिनत मामलों का क्या जहाँ यही कहा गया और सचमुच कुछ नहीं हुआ?
अगर मैं lottery खरीदने वाले लाखों लोगों से कहूँ कि "तुम नहीं जीतोगे", तो लगभग हर किसी के लिए वह सही prediction होगा
एक व्यक्ति के जीत जाने से मेरा prediction ग़लत नहीं हो जाता; वह सिर्फ reporting bias भी हो सकता है
किसी को पक्का यक़ीन नहीं था कि Putin इतनी दूर तक जाएगा, लेकिन Ukraine की सेना contingency के लिए defense lines, stockpiles, और defensive tactics तैयार करने में बहुत व्यस्त थी
जैसे-जैसे समय बीत रहा है, Peter Naur का programming as theory building और महत्वपूर्ण लगता जा रहा है
लिंक: https://gwern.net/doc/cs/algorithm/1985-naur.pdf
यह ज़ोरदार तरीके से recommend करने लायक़ पढ़ाई है