Software engineering शायद अब आजीवन करियर नहीं रह गया है

 (seangoedecke.com)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI का उपयोग करने से उस काम को करने के लिए सीखने की मात्रा कम हो जाती है, यह स्पष्ट है, लेकिन यह AI को ठुकराने का कारण नहीं बनता
  • भले ही AI लंबे समय में इंजीनियर की क्षमता को कमजोर कर दे, अगर अल्पकालिक उत्पादकता लाभ पर्याप्त हैं, तो इसका उपयोग लगभग अपरिहार्य है
  • जैसे construction workers शारीरिक बोझ के बावजूद भारी सामान उठाते हैं, वैसे ही पेशे की मूलभूत मांगों का पालन करना पड़ता है
  • आप hand-coding पर अड़े रह सकते हैं, लेकिन जैसे power tools को ठुकराने वाले बढ़ई के लिए काम नहीं होता, वैसे ही AI को ठुकराने वाले इंजीनियर के प्रतिस्पर्धा में पीछे छूटने की संभावना अधिक है, खासकर उन इंजीनियरों के मुकाबले जिन्होंने AI को अपना लिया है
  • software engineers भी professional athletes की तरह सीमित करियर अवधि वाली पहली पीढ़ी बन सकते हैं, इसलिए उस संभावना के अनुसार योजना बनाना ज़रूरी है

AI का उपयोग और software engineers के करियर की अवधि

  • इस बात के ठोस प्रमाण नहीं हैं कि AI लोगों की समग्र बुद्धिमत्ता को घटा देता है, लेकिन AI से कोई काम कराने पर उस खास काम को करने के बारे में आप कम सीखते हैं, यह स्पष्ट है
  • कुछ software engineers के यह मानने के पीछे कि काम में AI का उपयोग नहीं करना चाहिए, तर्क लगभग यह है
    • AI का उपयोग करने से काम करते हुए कम सीखने को मिलता है
    • समय के साथ तकनीकी क्षमता क्षीण हो जाती है और आप कम प्रभावी इंजीनियर बन जाते हैं
    • इसलिए निष्कर्ष निकलता है कि काम में AI का उपयोग नहीं करना चाहिए
  • लेकिन दूसरी premise निश्चित नहीं है
    • assembly language से C पर जाने के दौरान programmers कुछ मायनों में कम प्रभावी हुए, और कुछ मायनों में अधिक प्रभावी
    • हाथ से code लिखने के तरीके से AI के साथ काम करने के तरीके की ओर बदलाव इससे भी बड़ा परिवर्तन हो सकता है, इसलिए नतीजे को लेकर पक्की बात कहना मुश्किल है
  • मान लें कि AI का उपयोग लंबे समय में इंजीनियरों को कम प्रभावी बना दे, तब भी केवल इसी आधार पर यह निष्कर्ष नहीं निकलता कि AI का उपयोग नहीं करना चाहिए
  • लगभग 2024 तक software engineering सीखने का सबसे अच्छा तरीका था खुद software engineering करना
    • coding के शौक को ऊँची आय वाले करियर में बदला जा सकता था, और जो लोग इस काम से प्यार करते थे वे समय के साथ और बेहतर होते जाते थे
    • यह software engineering का अपरिवर्तनीय स्वभाव कम और एक fortunate accident अधिक था

अल्पकालिक उत्पादकता और दीर्घकालिक क्षमता के बीच टकराव

  • अगर AI का उपयोग लंबे समय में नौकरी से जुड़ी क्षमता या सामान्य reasoning ability को नुकसान पहुँचाता भी है, तब भी अगर अल्पकालिक लाभ पर्याप्त हों, तो इंजीनियरों को AI का उपयोग करना पड़ सकता है
  • construction workers को प्रभावी ढंग से काम करने के लिए भारी सामान उठाना पड़ता है, लेकिन ऐसे काम लंबे समय में पीठ और जोड़ों को घिसते हैं, जिससे समय के साथ वे कम प्रभावी worker बन सकते हैं
    • construction workers यह नहीं कहते कि "भारी चीजें न उठाना ही अच्छा construction worker होना है", बल्कि कहते हैं, "कोई विकल्प नहीं, यही काम है"
  • construction site पर भारी सामान से बचने के लिए crane, wheelbarrow, forklift जैसी तकनीकें होती हैं
    • software engineers के लिए भी मानसिक रूप से गहराई से जुड़ने की तकनीकें चाहिए हो सकती हैं, लेकिन संभव है कि वैसी समान approach अभी तक मिली न हो
  • अगर AI सचमुच लोगों को कम बुद्धिमान बना देता है, तो आप हाथ से code लिखना जारी रख सकते हैं
    • लेकिन जैसे power tools को ठुकराने वाले बढ़ई के लिए लगभग कोई काम नहीं होता, उसी तरह केवल hand-coding करके वेतन पाना मुश्किल हो सकता है
    • अगर models पर्याप्त अच्छे हो जाएँ, तो आप उन इंजीनियरों से प्रतिस्पर्धा में हार सकते हैं जो दीर्घकालिक संज्ञानात्मक क्षमता को अल्पकालिक ऊँची कमाई वाले करियर के बदले बदलने को तैयार हैं
  • labor unions सैद्धांतिक रूप से इस प्रक्रिया को धीमा कर सकती हैं
    • अन्य industries में उन्होंने employers को bottom की ओर होने वाली race को धीमा करने पर मजबूर किया है
    • लेकिन tech jobs में वेतन ऊँचा है, और दुनिया में कहीं से भी काम किया जा सकता है, इसलिए replacement labor उपलब्ध है; इसी वजह से tech unions को लेकर निराशावाद है
  • professional athletes का करियर आमतौर पर अधिकतम लगभग 15 साल का होता है, और mid-30s तक बहुत पैसा कमाने का मौका मिलता है, लेकिन उसके बाद शरीर साथ नहीं देता
    • आज अक्सर दिखने वाला दुखद चरित्र वह professional athlete है जो मानता है कि "यह शो हमेशा चलता रहेगा" और retirement के बाद की तैयारी नहीं करता
    • software engineers भी उसी स्थिति में खड़ी पहली पीढ़ी हो सकते हैं, और अगर ऐसा है तो उसी के अनुसार योजना बनाना समझदारी होगी

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News टिप्पणियाँ

  • मैं यह बातचीत हफ्ते में कई बार करता हूँ: “AI डेवलपर्स को अप्रासंगिक बना देगा” — क्यों? “क्योंकि LLM कोड लिख सकते हैं।”
    लेकिन असल में, जिन कामों से मैं रोज़ी कमाता हूँ उनमें कोड लिखना पहले 2~5% था, अब उससे भी कम है; बाकी काम चीज़ों को समझकर समाधान गढ़ने की क्षमता लागू करने का है।
    जो डेवलपर्स अब भी मानते हैं कि उनका काम सिर्फ कोड टाइप करना है, उनके पास भविष्य में नौकरी न बचे; और जो बिज़नेस वाले यह मानकर डेवलपरों के बिना काम चलाना चाहते हैं कि LLM डेवलपर्स की जगह ले लेंगे, उन्हें आखिरकार प्राकृतिक चयन ही संभाल लेगा।

    • 2000 के आसपास अपनी शुरुआती नौकरियों में से एक में मेरी जोड़ी एक ऐसे वरिष्ठ सॉफ्टवेयर इंजीनियर के साथ लगी थी जो 1970 के शुरुआती दशक से काम कर रहे थे, और मैं उनसे सीखने को लेकर बहुत उत्साहित था।
      चौथे दिन के आसपास उन्होंने कहा, “मैं तुम्हें वह चीज़ सिखाऊँगा जिसने मेरे करियर में सबसे ज़्यादा मदद की,” और बोले, “पंच कार्ड्स पर हमेशा नंबर लिखो, ताकि गिर जाएँ तो आसानी से फिर क्रम में लगा सको।”
      पंच कार्ड का दौर खत्म हुए बहुत समय हो चुका था, इसलिए मैं निराश हुआ। फिर उन्होंने जोड़ा, “मैंने यह नहीं कहा था कि यह तुम्हारे काम आएगा; मैंने कहा था कि इसने मेरी मदद की थी। सॉफ्टवेयर हमेशा बदलता है।” आजकल मैं उनकी वह बात अक्सर याद करता हूँ।
    • यह जवाब कुछ ज़्यादा ही चमकदार है। मेरा ज़्यादातर समय वास्तव में कोडिंग में जाता है, और उसमें टाइप करना, फिर से टाइप करना, और फिर से टाइप करना शामिल है।
      इसमें वह समय भी शामिल है जब कम-डॉक्यूमेंटेड API के हिसाब से दोबारा लिखे गए कोड को चलाने के लिए दीवार पर सिर मारना पड़ता है।
      मूल टिप्पणी सॉफ्टवेयर इंजीनियरिंग को गणित जैसी शुद्ध और महान गतिविधि की तरह दिखाती है, लेकिन असल में यह ड्रिलिंग मजदूर के ज़्यादा करीब है, जो योजना लेकर आया था लेकिन ज़मीन की हकीकत अलग निकली, और अब तंग समयसीमा में ड्रिल स्ट्रिंग फिट करने के लिए बड़े हथौड़े से धातु पीट रहा है।
    • कुछ लोग ऐसे हैं जिनके लिए “कोड लिखना 2~5%” है, लेकिन कुछ के लिए यह 6~50% भी है।
      “चीज़ों को समझकर समाधान बनाना” भी वही क्षेत्र है जिस पर AI निशाना साध रहा है।
      हो सकता है कि आप बस इतने भाग्यशाली हों कि ऐसे माहौल में हों जहाँ योगदान को पहचाना जाता है, या ऐसे उद्योग/डोमेन में हों जो ट्रेनिंग डेटा में कम हैं, या ऐसी समस्या-क्षेत्र में हों जो AI के लिए अभी बहुत जटिल है।
      जो लोग Jira टिकट निपटाते हैं और CRUD वेबऐप बनाते हैं, उनकी आजीविका के बार-बार गायब होने, या उसी या कम वेतन पर ज़्यादा आउटपुट माँगे जाने और AI से बराबरी करने को मजबूर होने की संभावना ज़्यादा है।
    • “प्राकृतिक चयन इसे संभाल लेगा” — यह वाक्य मुझे पसंद आया। AI सॉफ्टवेयर और उससे आगे की दुनिया को कैसे बदलेगा, इस पर भविष्यवाणियाँ बहुत हैं; लेकिन अब मैं जानना चाहता हूँ कि बातें कब रुकेंगी और नतीजों का प्रदर्शन कब शुरू होगा।
      अगर यह काम करता है, तो करेगा; तरीका फैल जाएगा, जल्दी ही सबकी पहुँच में होगा, और प्रगति जारी रहेगी।
      अगर यह काम नहीं करता, तो यह वास्तविक नतीजों की अनुपस्थिति से दिखेगा। सिर्फ “मैं देख रहा हूँ” कहना काफी नहीं है। यह ऐसी हकीकत होनी चाहिए जिसे हर कोई देख और इस्तेमाल कर सके, और जिससे बचा या इनकार न किया जा सके।
    • सिद्धांत रूप में मैं सहमत हूँ, लेकिन 2~5% का अनुमान बेहद कम लगता है। अगर कोई कहे कि अधिकांश डेवलपर्स अपना 25%, शायद 40% तक समय कोड पर खर्च करते हैं, तो यह विश्वसनीय लगता है; लेकिन सिर्फ 2% खर्च करने वाले लोग बहुत दुर्लभ हैं।
      शायद किसी विशाल कंपनी में CTO के सलाहकार जैसे बहुत ऊँचे स्तर के स्टाफ के लिए यह संभव हो, लेकिन वह पहले से ही बहुत असाधारण स्थिति है।

  • AI को लेकर ध्रुवीकृत प्रतिक्रियाएँ इस पर निर्भर लगती हैं कि आप किस लेंस से देख रहे हैं। जूनियर भूमिकाएँ तेज़ी से गायब हो रही हैं, लेकिन सीनियर भूमिकाओं में अनुभव और निर्णय-क्षमता पहले से कहीं ज़्यादा महत्वपूर्ण हो गई है।
    इसलिए यह सही हो सकता है कि सॉफ्टवेयर इंजीनियरिंग अब बहुत लोगों के लिए जीवनभर का करियर न रहे। यह कुछ वैसा है जैसे एलीट खेल अधिकांश लोगों के लिए वास्तविक करियर विकल्प नहीं होते, फिर भी कुछ लोग इसे पेशा बनाएँगे — और उन्हें बनाना भी चाहिए।

  • मेरा अनुभव बिल्कुल उलटा रहा है। जो बहुत कुशल इंजीनियर नवीनतम टूल्स को सच में इस्तेमाल करना चाहते हैं, वे 40s और 50s में भी पहले से कहीं बेहतर हो गए हैं।
    पारंपरिक प्रोग्रामर्स के समय के साथ कमज़ोर पड़ने का एक कारण, शतरंज की तरह, फोकस और गहरी गणना की क्षमता का कम होना है। उम्रदराज़ शतरंज खिलाड़ी 19 साल के प्रतिभाशाली खिलाड़ी से शतरंज को बहुत बेहतर समझता है, लेकिन वह उसी गति से लंबे समय तक गणना नहीं कर पाता, और अंततः अनुभव शुद्ध गणनात्मक क्षमता से हार जाता है।
    Claude Code और Codex इस गणनात्मक बोझ को कम कर देते हैं, जबकि अनुभव से बनी सारी प्रवृत्तियाँ और 2-सेकंड वाली “इंट्यूशन” जस की तस रहती हैं।
    अब खेल सिर्फ बराबरी का नहीं रहा; उल्टा अनुचित हो गया है। जो सीनियर पहले 6 लोगों की टीम लीड करता था, अब वह एजेंट्स की टीम लीड करता है, और पहले की तरह कोड रिव्यू करता है। कभी-कभी आसपास के जूनियर्स की तुलना में एजेंट्स की दिशा बदलना आसान लगता है।

    • शुक्र है, सॉफ्टवेयर इंजीनियरों के लिए आर्किटेक्ट ट्रैक होता है, और इसमें अक्सर ऐसी गहरी अंतर्दृष्टि को पुरस्कृत किया जाता है जो विवरणी गणना के तरीके बदलते रहने पर भी बनी रहती है।
      लेकिन एक तात्कालिक और अभी-अनुत्तरित सवाल यह है: क्या बिना प्रैक्टिकल trenches से गुज़रे कोई अच्छा आर्किटेक्ट बन सकता है?
      LLM भी इंट्यूशन जैसी चीज़ करता है, इसलिए फर्क समझना ज़रूरी है। LLM इंटरनेट के सामूहिक अवचेतन के ज़्यादा करीब है, और अच्छे-बुरे अनुभवों से बनने वाली रुचि से स्पष्ट रूप से अलग है।
      आखिर में जो उभरकर आता है वह “अच्छी रुचि” है, और यही लगभग हर तकनीकी क्षेत्र में सीनियर भूमिकाओं के मुख्य काम के केंद्र में है।
    • अगर एक सीनियर अकेला 6 साथियों का काम कर सकता है, तो उन साथियों का क्या होगा?
      कृषि में ट्रैक्टर से बदले गए लोगों ने अपनी नौकरियाँ बरकरार नहीं रखीं। अब क्या अलग है?
    • “जो सीनियर पहले 6 लोगों की टीम लीड करता था, अब एजेंट्स की टीम लीड करता है” — यह तो लेखक की बात की पुष्टि है।
      6 लोगों की टीम अब ज़रूरी नहीं रही, और तर्कतः उसे कंपनी से हटा दिया जाएगा।
      इसलिए सॉफ्टवेयर इंजीनियरिंग कुछ लोगों के लिए करियर बनी रह सकती है, लेकिन कुल संख्या 85% तक घट सकती है।
    • मैं 43 साल का हूँ, और 15 साल के अनुभव के बाद Java/Swing डेवलपर के रूप में बेहद उत्पादक था; मैं टूल्स को बारीकी से जानता था।
      लेकिन वह कंपनी अब मौजूद नहीं है, और आज जिन नए टूल्स का इस्तेमाल करता हूँ, उनमें दक्ष होकर काम करना सीखने में कहीं ज़्यादा समय लग रहा है, क्योंकि मैंने इस नए माहौल के विवरण 10 साल तक नहीं सीखे।
      इसलिए AI सही syntax पता करने और unit test framework के विवरण याद रखने में बहुत समय बचा देता है। लगता है कि 1~3 साल रुकूँ तो मैं बहुत तेज़ हो जाऊँगा और टूल्स को बेहतर समझने लगूँगा।
    • हमें मानवीकरण बंद करना चाहिए। एजेंट्स की टीम जैसी कोई चीज़ नहीं है; यह बस कंप्यूटर पर चलने वाले टूल्स और प्रोसेस हैं।
      वह एक सीनियर इंजीनियर गायब हो जाए तो कुछ नहीं बचेगा। 6 लोगों की टीम होना बेहतर है।

  • यह विचार कि “AI उपयोगकर्ता समय के साथ तकनीकी रूप से कमज़ोर होकर कम प्रभावी इंजीनियर बन जाते हैं” दुख की बात है, लेकिन लंबे समय में शायद मोटे तौर पर सही साबित होगा।
    पेशेवर रूप से देखें तो लोग आम तौर पर दो वर्गों में बँटते हैं: वे जो AI से reasoning को मजबूत करते हैं, और वे जो AI से reasoning को बदल देते हैं। पहले समूह को लेकर मुझे बहुत चिंता नहीं है, लेकिन दूसरे को लेकर है।
    मेरी माँ, जो अमेरिका के एक पब्लिक हाई स्कूल में शिक्षक हैं, शिकायत करती हैं कि छात्र अक्सर “Google AI overview” को अंतिम सत्य का स्रोत मान लेते हैं।
    हो सकता है यह पुराने “Wikipedia को cite नहीं कर सकते” वाली बात जैसा नया रूप हो, लेकिन महामारी के बाद क्लास में आने वाले बच्चों की critical thinking में उन्होंने स्पष्ट गिरावट महसूस की है।
    एक-दो पीढ़ियाँ ऐसी रही हैं जो ऐसे माहौल में बड़ी हुई हैं जहाँ influencers और इंटरनेट के गुमनाम लोग उन्हें बताते रहे हैं कि क्या पसंद करना है, क्या नापसंद करना है, और क्या मानना है। उन्होंने LLM से पहले ही अपनी reasoning outsource कर दी थी, और वे ऐसे सिस्टम के साथ उत्पादक ढंग से काम करने के लिए तैयार नहीं लगते जो संदिग्ध गुणवत्ता के बावजूद उन्हें यह विश्वास दिलाने के लिए डिज़ाइन किए गए हैं कि उन्हें वही मिल रहा है जो वे चाहते हैं।

    • मैं सचमुच ऐसे लोगों के साथ काम करता हूँ जो आउटपुट को ठीक से देखे बिना समाधान जनरेट कर देते हैं। वे ऐप को कुछ बार क्लिक कर लेते हैं या कुछ टेस्ट चला लेते हैं, और अगर नतीजा ठीक लग गया तो deploy कर देते हैं।
      पूरे PR में Claude के निशान दिखते हैं, और यह मान लेना सुरक्षित है कि उन्होंने लगभग कुछ भी संपादित नहीं किया। यही समूह A है।
      दूसरी ओर, कुछ सहकर्मी ऐसे हैं जो समस्या को अंत तक पकड़कर रखते हैं, बदलावों को परखने के लिए harness बनाते हैं, परिणामों को validate करते हैं, कई समाधानों से गुजरकर आदर्श परिणाम को एक में synthesize करते हैं, benchmark करते हैं, polish करते हैं, गहराई से test करते हैं, और PR में युक्तिसंगत validation procedure देते हैं। यही समूह B है।
      ये AI इस्तेमाल करने के दो बिल्कुल अलग तरीके हैं। A अभी तो किसी तरह पास होता दिख सकता है, लेकिन B दिए गए समय में संभव चीज़ों का नया संस्करण है, और यह सॉफ्टवेयर इंजीनियरिंग का एक नया मानक तय करता है जिसे मैंने असाधारण पेशेवर वातावरण के बाहर शायद ही कभी देखा था।
      मुझे लगता है कि A समूह बहुत जल्दी उद्योग से बाहर हो जाएगा। अगर सीखने की इच्छा हो तो LLM आपको हैरान कर देने वाली प्रभावशीलता से काम करने देता है। हो सकता है यही कठोरता डिफॉल्ट बन जाए, और यही एकमात्र तरीका हो जिसमें इंसान loop के अंदर अब भी उपयोगी घटक बना रहे।
    • मेरे आसपास के बहुत से वयस्क भी अब Google AI overview को पूर्ण स्रोत की तरह लेने लगे हैं।
    • इस विषय पर हाल का HN पोस्ट: https://news.ycombinator.com/item?id=47913650

  • किस्सों के आधार पर कहूँ तो ऐसा लगता है कि इस साल की शुरुआत में अमेरिकी सॉफ्टवेयर hiring market में सचमुच कुछ बदल गया। लगता है कि अगले कुछ वर्षों में human capital में ज़्यादा निवेश से बचने के लिए अधिक से अधिक कंपनियाँ wait-and-see strategy अपना रही हैं।
    hiring के जो संकेत पहले ही कमज़ोर थे, वे अब लगभग गायब हो गए लगते हैं। एक पोस्ट डालो और 500 से ज़्यादा LLM-लिखित applications और cover letters आ जाते हैं, और सब एक जैसे दिखते और लगते हैं।
    इस लेख में पेशेवर खिलाड़ियों वाली तुलना कुछ अटपटी लगती है। मांसपेशियों से पैसा कमाने वाले कामों में उम्र से जुड़ी शारीरिक सीमाएँ साफ़ होती हैं, लेकिन law या medicine जैसे knowledge-work क्षेत्रों से तुलना करें तो 40s और 50s में भी बहुत दक्ष और तेज़ practitioners मिलते हैं।

    • यह भी किस्सों पर आधारित है, लेकिन मुझे लगता है कि अमेरिकी कंपनियाँ भारत और दूसरे developing markets में बड़े पैमाने पर hiring कर रही हैं।
      मैं ऐसे लोगों को जानता हूँ जिन्हें पहले कभी Big Tech recruiters से संपर्क नहीं मिला, और अब उन्हें रोज़ संदेश मिल रहे हैं।
      मैंने यह भी सुना है कि इसकी वजह पिछले साल खत्म हुई किसी खास अमेरिकी provision से जुड़ी है, लेकिन मैं इस विषय में अंजान हूँ इसलिए कारण पर कुछ नहीं कह सकता।
    • जमीन पर देखें तो ईमानदारी से नहीं लगता कि AI hiring demand को प्रभावित कर रहा है। ऐसा नहीं है कि leadership ने जो कुछ कल्पना किया, AI ने सब लिख दिया और इंजीनियर्स खाली बैठे हैं।
      बल्कि ऐसा लगता है कि economy या तो गिरने के कगार पर है, या कम से कम roller coaster जैसी है। hiring tax incentives कमज़ोर हैं, zero-interest-rate era बहुत पहले खत्म हो चुका है, और recruiters शोरभरे applications से दबे हुए हैं।
      फिर भी bosses को यह कहना पसंद है कि वजह AI है, क्योंकि इससे ऐसा लगता है कि वे नियंत्रण में हैं।
    • मुझे लगता है कि कंपनियों ने COVID के दौरान overhire किया था, और उस अनुभव के साथ-साथ अनिश्चित बाज़ार के कारण वे वही गलती दोहराना नहीं चाहतीं।

  • AI के संदर्भ में मैं बार-बार यह तर्क पढ़ता हूँ कि “लोगों को बस किसी दूसरी नौकरी के लिए retrain किया जा सकता है,” लेकिन मैंने कभी यह नहीं देखा कि वह नौकरी कौन-सी होगी, या retraining का खर्च कौन देगा।
    मेरे पास न तो इतना पैसा है न समय कि कॉलेज वापस जाकर शून्य से नया करियर शुरू करूँ।

    • तर्क यह है कि “इतिहास में हमेशा ऐसा ही हुआ है।”
      यह सही है, लेकिन सिर्फ तब तक जब तक यह सही न रह जाए।
      इस तरह की सोच कितनी बुरी तरह विफल हो सकती है, इसका क्लासिक उदाहरण Malthusian theory है। यह कि खाद्य उत्पादन रैखिक बढ़ता है और जनसंख्या घातीय, इसलिए आबादी ढह जाएगी — यह मॉल्थस के यह अवलोकन दर्ज करने तक के पूरे इतिहास में सही था।
      “हमने हमेशा दूसरी नौकरियाँ ढूँढ लीं” वाला तर्क यांत्रिक स्तर पर यह नज़रअंदाज़ करता है कि ऐसा इसलिए संभव था क्योंकि मनुष्यों के पास हमेशा automation पर बुद्धिगत बढ़त थी।
      यहाँ तक कि assembly line पर साधारण मानवीय इनपुट भी अंततः इस मानवीय क्षमता पर निर्भर था कि वह सूक्ष्म, लगभग अदृश्य समायोजन कर सके जो रोबोट नहीं कर सकते थे।
      लेकिन अगर AGI के क़रीब कुछ वास्तव में काम करने लगे, तो मानव श्रम के पास automation पर कोई बढ़त नहीं बचेगी; इसलिए यह स्पष्ट नहीं है कि अतीत का “automation ने और मानवीय नौकरियाँ पैदा कीं” वाला तर्क क्यों चलता रहेगा।
    • जैसे चीन को outsourcing से बदले गए skilled industrial workers के लिए वह retraining वास्तव में नहीं हुई, वैसे ही इस बार भी नहीं होगी।
      सरकार बस इतना welfare देगी कि स्थिति संभाली जा सके, और फिर सांस्कृतिक रूप से लोगों को Luddite जैसा बताकर दानवीकृत किया जाएगा।
    • ऐसी नौकरियाँ हैं ही नहीं, और अगर हों भी तो खर्च आपको खुद उठाना होगा। कंपनियाँ तब तक कभी पैसा नहीं देंगी जब तक वे प्रतिस्पर्धा के कारण मजबूर न हों, और वह बहुत ही दुर्लभ है।
    • यही बात उन industries पर भी लागू होती है जिन्हें सॉफ्टवेयर ने नष्ट किया।
    • इस बात की कोई गारंटी नहीं है कि दूसरी अच्छी नौकरियाँ पैदा होंगी। लोग इसे बस मानकर चलते दिखते हैं।
      हाँ, कुछ समय तक ऐसे काम रहेंगे जिनमें मानव शारीरिक श्रम चाहिए, लेकिन वास्तविकता में बहुत-सी physical labor jobs दुनिया के उन हिस्सों में होती हैं जहाँ मजदूरी सस्ती है।
      plumber या waitress जैसी ऐसी नौकरियाँ जिन्हें export नहीं किया जा सकता, उनकी मांग सीमित है। आप मौजूदा white-collar workforce के 50% लोगों को इन नौकरियों में नहीं धकेल सकते और उम्मीद नहीं कर सकते कि वे आसानी से काम पा लेंगे या ठीक-ठाक मजदूरी कमा लेंगे। इतनी मांग है ही नहीं।
      साथ ही, white-collar jobs के खत्म होने के दौरान “low-skill” physical labor jobs भी लगातार automate हो रही हैं। self-checkout retail jobs घटाता है, robotaxis और drone delivery delivery/logistics jobs घटाएँगे, और warehouse robots warehouse jobs घटाएँगे।
      लगता है एक छिपी हुई धारणा यह है कि AI बहुत-सी ऐसी high-paying jobs पैदा करेगा जिनमें human employers की ज़रूरत होगी, और जिन्हें सस्ते में विदेश outsource भी नहीं किया जा सकेगा। आखिर ऐसी कौन-सी high-paying jobs होंगी जो AI से भी सुरक्षित हों और outsourcing से भी? क्या सब लोग high-paid cleaners बन जाएँगे? बात समझ में नहीं आती।
      आजकल construction worker या plumber बनने की सलाह इस मान्यता पर टिकी लगती है कि ऐसे श्रम की मांग असीमित है, जबकि ऐसा नहीं है। भले ही construction workers की मांग अचानक बढ़ जाए, फिर भी लाखों लोगों को construction में समाने लायक equipment, supply chains और infrastructure तैयार करने में सालों लगेंगे।
      सबसे संभावित परिदृश्य यह है कि लोग अपनी नौकरियाँ खो देंगे और घरेलू अर्थव्यवस्था में बची हुई सीमित नौकरियों के लिए अंतहीन downward competition में फँस जाएँगे। बाकी काम outsourcing, robots और AI कर लेंगे।
      बेहतर सलाह यह है कि लोग अभी से इस वास्तविकता की तैयारी शुरू करें। यह नहीं मानना चाहिए कि सरकार आपकी रक्षा करेगी या कर पाएगी। जहाँ संपत्ति का केंद्रीकरण होता है, वहाँ corruption लगभग अनिवार्य होता है, और politicians के भी परिवार होते हैं जिनकी उन्हें देखभाल करनी होती है।
      इसे गंभीरता से लेना चाहिए। भले मैं गलत साबित हो जाऊँ, फिर भी यह मान लेने से कि सब ठीक हो जाएगा और आप किसी नई high-paying नौकरी के लिए retrain कर लेंगे, बदतर स्थिति के लिए तैयार रहना बेहतर है।

  • मेरे माता-पिता दोनों construction workers थे। उन्हें यह पता था कि कोई हमेशा भारी चीज़ें नहीं उठा सकता।
    आख़िरकार उन्होंने चीज़ें उठाना बंद किया और foreman या supervisor बन गए। अगर यह सीखना असुविधाजनक लगे कि अब वह काम दूसरों से कैसे करवाना है जो पहले आप खुद करते थे, तो शरीर पूरी तरह टूट जाता है — और उसका नतीजा भयावह होता है।
    यह एक वास्तविक सच्चाई भी है, और मेरे अपने करियर में delegation को भीतर तक समझने के लिए एक अहम रूपक भी रहा है। इसका AI इस्तेमाल से कुछ संबंध तो है, लेकिन मुझे नहीं लगता कि यह पूरी तरह साफ़-सुथरे ढंग से मेल खाता है।

    • यह भी ध्यान देने लायक है कि उचित सीमा में भारी चीज़ें उठाना इंसान को मज़बूत बनाता है, जबकि AI इस्तेमाल को लेकर मौजूदा परिकल्पना अक्सर ठीक उलटी है।
    • सॉफ्टवेयर डेवलपर्स साधारण प्रोग्रामर से ज़्यादा architects जैसे होते हैं। architects से भारी चीज़ें नहीं उठवाई जातीं; उनसे यह डिज़ाइन करवाया जाता है कि उन भारी चीज़ों का इस्तेमाल कैसे होगा।

  • मैं चाहता हूँ कि समझदार दिखने वाले लोग ऐसे abstract metaphor इस्तेमाल करना बंद करें। असली शब्द determinism है।
    power tools या C जैसी हर abstraction layer ने एक ऐसी deterministic layer जोड़ी जिस पर भरोसा किया जा सकता था; वह हर बार एक जैसा परिणाम देती थी और काम ज़्यादा प्रभावी बनाती थी।
    LLM में आप natural language में programming का वर्णन करते हैं और परिणाम, सबसे अच्छे मामले में भी, अलग-अलग हो सकते हैं। इसलिए agents की ज़रूरत पड़ती है और इसलिए लोग brute force से नतीजे धकेलते हैं।
    मुझे लगता है कि असली moat अब भी यह है कि आप वास्तव में प्रोग्राम कर सकें।

    • लोग यह बात बार-बार कहते हैं, लेकिन मेरे हिसाब से यह गलत दलील है। LLM deterministic नहीं हैं, लेकिन इससे कोई फर्क नहीं पड़ता।
      आप LLM output को सीधे execute नहीं करते; आप LLM से एक बार artifact बनवाते हैं, और फिर उस artifact को deterministic तरीके से execute करते हैं।
      specification एक बार code में बदल जाती है, और specification edit करने पर code अपडेट हो सकता है, लेकिन हर बार पूरा program नए सिरे से नहीं बनता। तो फिर determinism यहाँ इतना महत्वपूर्ण क्यों है?
    • मैं मानता हूँ कि LLM किसी परिभाषा के अनुसार abstraction नहीं हैं। लेकिन जो लोग LLM को एक और abstraction layer कहते हैं, वे सब इसे गलत नहीं समझ रहे। वे उस शब्द को अधिक अमूर्त अर्थ में इस्तेमाल कर रहे हैं।
      उदाहरण के लिए, 5 साल पहले Mark Zuckerberg सॉफ्टवेयर कैसे बनवाता था?
      वह भी मेरी तरह editor खोल सकता था, लेकिन परिस्थितियों ने उसे human resources के रूप में एक अलग interface दिया हुआ था। editor के बजाय वह उन लोगों से interact करता था, और वे लोग software बनाते थे।
      उसके और बने हुए system के बीच यह layer, चाहे deterministic हो या नहीं, एक abstraction ही है।
      आज हमारे पास कुछ साल पहले की तुलना में अधिक चौड़ा अधिकार-क्षेत्र है, जिसके भीतर हम काम delegate कर सकते हैं।
    • क्या बाकी layers सचमुच deterministic हैं? क्या आपको पक्का पता है कि कौन-सा object garbage collected हुआ? क्या आपको पक्का पता है कि इस instruction में कितने cycles लगेंगे?
    • LLM को बहुत-से कामों की जगह लेने के लिए पूर्ण विश्वसनीयता हासिल करने की ज़रूरत नहीं है। उसे सिर्फ किसी खास काम के लिए विश्वसनीयता और लागत के सही संतुलन तक पहुँचना है। और यह काम के अनुसार बदलता है।
    • मैं आपकी बात समझता हूँ, लेकिन “determinism” शब्द भी ठीक नहीं है। LLM मूल रूप से deterministic हैं, क्योंकि वे input text और network parameters के function के रूप में text output करते हैं — यानी एक pure function।
      free will पर आपके दृष्टिकोण के अनुसार इंसानों को भी प्रभावी रूप से deterministic कहा जा सकता है।
      यहाँ जिस विचार को छुआ जा रहा है, वह यह है कि LLM और इंसान opaque functions हैं। उनके व्यवहार को मन के भीतर होने वाले तार्किक चरणों की श्रृंखला में नहीं घटाया जा सकता; ऐसी invariants नहीं हैं जिनसे उनकी जटिलता को कुछ interpret किए जा सकने वाले states में साफ़-साफ़ तोड़ा जा सके; input/output space असंरचित, अस्पष्ट, अपूर्ण रूप से निर्दिष्ट और व्यवहार में लगभग अनंत है।
      इसी वजह से पारंपरिक programs पर लागू होने वाली रणनीतियों और analysis के साथ इनके बारे में reasoning करना या इन्हें synthesize करना लगभग असंभव है।
      आप चुनिंदा तौर पर entropy source डालकर nondeterminism जोड़ सकते हैं, लेकिन यह अनिवार्य नहीं है। अगर LLM providers सभी pseudorandom number generator seeds को fixed value पर सेट कर दें तो शायद बहुत कम लोग नोटिस करेंगे।
      मुझे नहीं लगता कि बहुत-से workflows ऐसे हैं जो एक ही prompt को कई बार देकर output के किसी statistical distribution पर निर्भर हों। उल्टा, चाहें या न चाहें, आपको cached response मिल सकता है।

  • अगर सॉफ्टवेयर इंजीनियरिंग से आपका मतलब text editor में एक-एक अक्षर डालकर कोड लिखना है, तो ऐसे काम के लिए पैसे देने वाले लोगों को ढूँढना कठिन होता जाएगा।
    लेकिन अगर आपका मतलब software बनाना है, तो हम पहले से कहीं ज़्यादा software बना रहे हैं, और software क्या है इसकी परिभाषा भी पहले से कहीं अधिक विविध हो गई है। मुझे लगता है कि यहाँ से कई अलग-अलग careers निकल सकती हैं।

    • हम वही बदलाव झेल रहे हैं जो civil engineers ने calculators आने पर, और electrical engineers ने हाथ से circuit routing करने से CAD tools पर जाने पर झेला था।
      दिलचस्प बात यह है कि software engineering को भी evolve करना होगा। processes और tools को भी पिछले दशकों की तरह evolve करना होगा।
      जब मैंने 2004 में कॉलेज खत्म किया था, तब हमने “software crisis” का दौर, waterfall development process, और नई “iterative methodologies” की शुरुआत पढ़ी थी।
      हमने spaghetti code से Pascal/C की structured programming और फिर object-oriented programming तक का सफर भी पढ़ा था।
      engineering methodologies भी evolve हुई थीं। कुख्यात UML था, formal verification के लिए Z language जैसी formal techniques थीं, और ABC तथा cyclomatic complexity जैसे software complexity measures भी थे।
      आज जब computers ज़्यादातर code लिख सकते हैं, तो मौजूदा languages और software development processes का मूल्य घट रहा है। programming languages इंसानों के लिए बनाई गई थीं; नहीं तो हम assembly में ही लिखते रहते।
      अब हमें वह abstraction बदलनी होगी जिसका इस्तेमाल हम computers को अपना intent बताने और यह verify करने के लिए करते हैं कि अंतिम commands वही करें जो हम चाहते थे।
      मैं इस नई abstraction को लेकर बहुत उत्सुक हूँ। मेरा मानना है कि जब coding के छोटे-छोटे विवरण पूरी तरह automate हो जाएँगे, तब शायद हम software engineering पेशे में और ज़्यादा वास्तविक engineering rigor देखेंगे।
    • मान लीजिए 2020 में दो कंपनियाँ हैं जो एक-दूसरे से प्रतिस्पर्धा करती हैं, और दोनों ने 100 programmers रखे हैं। हम सब जानते हैं कि ये संगठन कैसे चलते हैं। वे हमेशा पीछे रहते हैं, हर feature जोड़ने पर और संभावित features पैदा हो जाते हैं, हम सब उस दुनिया में रहे हैं, और आज भी लगभग वहीं हैं।
      अब मान लीजिए 2026 में दोनों कंपनियाँ निष्कर्ष निकालती हैं कि AI developers को 10x तेज़ बना देता है। मैं यह नहीं कह रहा कि यही वास्तविक संख्या है; बस आसान गोल संख्या ले रहा हूँ।
      Company 1 अपने 90 programmers को निकाल देती है और 10 लोगों से वही काम कराती है।
      Company 2 सारे programmers रखती है, पहले से 10 गुना ज़्यादा काम करती है, और शायद और hiring भी करती है।
      बाज़ार में कौन जीतेगा?
      जवाब हमेशा की तरह “depends” है, लेकिन मुझे लगता है कि Company 1 के जीतने की जगह Company 2 की तुलना में बहुत संकरी है। इसके लिए बाज़ार की बहुत विशेष परिस्थितियों का मेल चाहिए होगा। ऐसा नहीं कि यह बिल्कुल असंभव है, लेकिन अपने आप को अपवाद मानकर दाँव लगाना जोखिम भरा है।
      acceleration के दौरान, जब नई हकीकत अभी स्थापित नहीं हुई होती, Company 1 का जवाब accountants को ऊपर-ऊपर से आकर्षक लग सकता है।
      लेकिन किसी भी market में अगर एक भी company Company 2 वाला रास्ता चुनकर आगे निकलती है, तो ठीक से प्रतिस्पर्धा करने के लिए उद्योग के बाकी हिस्से को भी वही करना पड़ेगा।
      मध्यम और लंबी अवधि में यह संभावना कम लगती है कि एक programmer द्वारा पैदा की जाने वाली और वेतन के रूप में capture की जा सकने वाली value creation घट जाएगी।
    • चिंता यह है कि ऐसा software बनाने का काम क्या इतनी आय देगा कि तेजी से बढ़ती living costs का सामना कर सके।
      अतीत में automation से बनी नौकरियों में आम तौर पर कम वेतन और कम autonomy रही है।
    • भले हम ज़्यादा software बनाएँ, अगर उसका अधिकांश हिस्सा दूसरे software का functional duplicate हो, तो उससे कुछ हल नहीं होगा।
      दूसरे शब्दों में, हर company बार-बार पहिया फिर से बना रही है। सिर्फ इसलिए कि नया software किसी चमकदार नए framework में लिखा गया है, अगर उसमें वास्तव में कुछ नया नहीं है, तो software development को 10x बढ़ाने का कोई मतलब नहीं।
      मेरे हिसाब से हमें ज़्यादातर software को हटाना शुरू करना चाहिए। बुनियाद पर लौटकर देखना चाहिए कि वास्तव में क्या चाहिए, उसे बेहतर बनाना चाहिए, और उसे पूरा करना चाहिए। कम से कम एक बार तो किसी software को खत्म करना चाहिए।
    • अगर software engineer को secretary से, और creating software को typing correspondence से बदल दें, तो बात वैसी ही रहेगी।
      जिस दुनिया में AI software programming और design को हल कर चुका होगा, वहाँ मूल्य उन लोगों के पास जाएगा जिनके पास दूसरे domains की विशेषज्ञता होगी। अब उनके पास 1000 पेशेवर डेवलपर्स की शक्ति होगी, और जिन लोगों की skill सिर्फ इस दोहराए जा सकने वाले तकनीकी कौशल पर टिकी है, उनके पास, बेहतर, तेज़ और सस्ते AI tools के बीच, मूल्य जमा नहीं होगा।

  • अगर मैं कुछ चूक नहीं रहा, तो यहाँ एक स्पष्ट तार्किक समस्या है।
    अगर LLM से productivity पाने के लिए skill atrophy स्वीकार करनी पड़ती है, तो सीमित shelf life वाले developers सिर्फ हम होंगे। अगली पीढ़ी ने तो manual काम करके वे skills बनाई ही नहीं होंगी, इसलिए उनके पास क्षीण होने के लिए वह skill set होगा ही नहीं।
    और मैं प्रस्ताव रखता हूँ कि “LLM का code generation वही है जो compiler का machine code generation” वाली उपमा को सार्वजनिक रूप से प्रतिबंधित कर देना चाहिए। एक ही बहस को बार-बार घसीटना अब थका चुका है।

    • LLM-compiler analogy गलत क्यों है? क्या सिर्फ इसलिए कि LLM output nondeterministic होता है?