AWS CEO: "AI से junior कर्मचारियों को बदलना उन सबसे मूर्खतापूर्ण विचारों में से एक है जो मैंने सुने हैं"

 (theregister.com)
22 पॉइंट द्वारा GN⁺ 2025-08-22 | 11 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS CEO Matt Garman ने कहा कि यह विचार कि AI junior कर्मचारियों की जगह ले सकता है, "मैंने जो बातें सुनी हैं उनमें सबसे मूर्खतापूर्ण बातों में से एक" है
  • उन्होंने जोर दिया कि junior कर्मचारी सबसे कम लागत वाले होते हैं और AI टूल्स अपनाने में सबसे अधिक सक्रिय रहते हैं, इसलिए प्रतिभा विकसित करना और सीखने के अवसर देना अनिवार्य है
  • उन्होंने यह भी कहा कि AI के प्रदर्शन को लिखे गए कोड की मात्रा से मापना एक निरर्थक metric है, और बेवजह ज्यादा कोड की तुलना में कम लेकिन उच्च-गुणवत्ता वाला कोड अधिक महत्वपूर्ण है
  • AWS के भीतर 80% से अधिक डेवलपर्स पहले से AI का उपयोग कर रहे हैं, और इसे unit test, documentation writing, code assistance, agent-based workflow जैसी कई तरह की प्रक्रियाओं में लागू किया जा रहा है
  • Garman का कहना है कि तेजी से बदलते तकनीकी माहौल में लंबे समय के लिए जरूरी चीजें critical thinking, creativity और सीखने की क्षमता हैं, और जिन लोगों में ये क्षमताएँ होंगी वही AI युग में सफल होंगे

junior कर्मचारियों को बदलने की बहस पर रुख

  • Garman ने उन कुछ executives के दावों का कड़ा विरोध किया कि AI से सभी junior कर्मचारियों को बदला जा सकता है
    • उन्होंने जोर देकर कहा कि junior कर्मचारी “सबसे कम लागत वाले होने के साथ-साथ AI के उपयोग में सबसे अधिक सक्रिय” होते हैं
    • उन्होंने कहा, “अगर 10 साल बाद किसी को भी अनुभव हासिल करने का मौका ही नहीं मिलेगा, तो क्या होगा,” और प्रतिभा-निर्माण की जरूरत पर बल दिया
  • उनका तर्क है कि अब भी university graduates को भर्ती करना, उन्हें समस्या सुलझाने के तरीके सिखाना और प्रशिक्षित करना एक अनिवार्य प्रक्रिया है

AI के उपयोग के तरीके और metrics पर आलोचना

  • लिखे गए कोड की मात्रा के आधार पर AI के प्रदर्शन को मापने की प्रथा को उन्होंने “बेकार metric” कहा
    • अनंत मात्रा में कोड बनाया जा सकता है, लेकिन उस कोड की गुणवत्ता खराब हो सकती है
    • उन्होंने कहा, “कई बार कम कोड बेहतर होता है,” और केवल मात्रा-आधारित संकेतकों पर जोर देने की प्रवृत्ति की आलोचना की
  • AWS के आंतरिक डेटा के मुताबिक 80% से अधिक डेवलपर्स पहले से AI का उपयोग कर रहे हैं
    • इसका उपयोग unit test automation, documentation support, कोड के कुछ हिस्से लिखने और agent-based collaboration समेत कई तरीकों से हो रहा है
    • ऐसे AI टूल्स के उपयोग की दर हर हफ्ते बढ़ रही है

AI युग में शिक्षा और करियर पर सलाह

  • Garman ने AI युग में जरूरी क्षमताओं के रूप में critical thinking, creativity और सीखने का रवैया गिनाया
    • किसी खास skill को सीखना नहीं, बल्कि “सीखना कैसे है” यह खुद
    • उन्होंने जोर दिया कि “खुद सोचना, समस्याओं को हिस्सों में बाँटकर हल करना, और नई चीजें सीखने की इच्छा” ही सबसे महत्वपूर्ण है
  • उनका कहना है कि तकनीक इतनी तेजी से बदल रही है कि केवल किसी एक खास skill को सीखना 30 साल के करियर को संभालने के लिए पर्याप्त नहीं है
  • इसलिए शिक्षकों को छात्रों को समस्याओं को विभाजित करके सोचना, तर्क करना और नई चीजें सीखने का रवैया सिखाना चाहिए, और जिन लोगों में ये क्षमताएँ होंगी वे AI युग में आगे बढ़ेंगे

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

11 टिप्पणियां

 
minsuchae 2025-08-23

मुझे लगता है कि इन दोनों पहलुओं पर पर्याप्त गंभीरता से विचार होना चाहिए।

कंपनी चलाने के लिए developers की ज़रूरत होती है, और अभी junior developers के लिए नौकरी पाना कठिन समय लग रहा है।
सार्वजनिक रूप से AI को वजह बताया जा रहा है, लेकिन COVID के दौरान बड़े पैमाने पर भर्ती होने और उसके अनुपात में सफलता न मिलने की तुलना में कंपनियों की कुल labor cost बढ़ गई, इसलिए उस बोझ के कारण भर्ती घटाई जा रही है। ऐसे हालात में जब LLM का उपयोग junior developer से काम करवाने जितनी या उससे अधिक efficiency दिखाने लगा, तो मेरा मानना है कि नौकरी का बाज़ार खुद ही और सिकुड़ गया है.

लेकिन जैसा लेख में भी लिखा है, junior developers होंगे तभी वे अंततः senior developers के रूप में विकसित हो सकेंगे।
अगर junior developer स्तर पर भर्ती ही नहीं होगी, तो senior developers पैदा ही नहीं हो सकते।

फिर भी, मुझे लगता है कि इस प्रक्रिया में काफ़ी संतुलन और समन्वय की ज़रूरत है।
बड़ी कंपनियों में शायद systems बेहतर बने होते हैं, इसलिए असर कम होगा, लेकिन जब junior developer आता है तो उसे कंपनी के मुख्य काम के बजाय कुछ सहायक काम (ऐसा काम जिसमें असफल होने पर भी कंपनी पर बड़ा असर न पड़े) देकर प्रशिक्षण दिया जाता है।

लेकिन senior developer के दृष्टिकोण से, जितना कम system स्थापित होगा, junior developer को मार्गदर्शन देना उतना ही कठिन होगा।

और विडंबना यह है कि LLM का उपयोग करते समय संबंधित ज्ञान ज़्यादा होना फ़ायदेमंद होता है; सिर्फ़ beginner developer होने से वही efficiency नहीं मिलती।
बल्कि सभी development कार्यों को junior कर्मचारियों से पूरी तरह बदल देना संभव नहीं है। बहुत होशियार और प्रतिभाशाली लोग शायद senior developer के बिना भी किसी तरह काम कर लें। लेकिन अगर काम धीरे-धीरे उसी व्यक्ति पर इकट्ठा होने लगे, तो क्या वह उसे संभाल पाएगा?

अर्थात, senior developers और junior developers दोनों की भर्ती होनी चाहिए, और उस प्रक्रिया में productivity तथा कंपनी की labor cost आदि को ध्यान में रखते हुए flexible hiring होनी चाहिए.
 
zxcv123 2025-08-22

जो लोग इस लेख से असहमत हैं, वे बस वही senior हैं जिनका अपना स्तर कम है, इसलिए उन्होंने सिर्फ कमज़ोर junior लोगों के साथ ही काम किया है, lol
AI के दौर में, करियर की परवाह किए बिना, तेज़ दिमाग वाले लोगों के लिए दुनिया बेहद ज़्यादा फायदेमंद है.
अगर कोई होशियार नया कर्मचारी 1~2 साल जमकर मेहनत करे, तो वह आराम से एक सामान्य 10 साल के अनुभवी को पीछे छोड़ सकता है
 
onixboox 2025-08-23

AI के बिना भी, तेज़ दिमाग वाले नए hires अगर 1–2 साल जमकर काम करें, तो आराम से 10 साल के औसत अनुभवी लोगों को पछाड़ देते थे...
 
epdlemflaj 2025-08-22

लगता है कुछ ऐसा कह रहे हैं, “जूनियर सस्ते हैं और AI भी अच्छी तरह इस्तेमाल करते हैं, तो उन्हें क्यों replace करें? चलो senior को replace करते हैं!”
 
rlaaudgjs5638 2025-08-22

ओह, इसे इस तरह भी समझा जा सकता है।
 
ididid393939 2025-08-22

बकवास lol
 
ifmkl 2025-08-22

उफ़...
 
aobamisaki 2025-08-22

कृपया इस तरह की टिप्पणी करने से परहेज़ करें। यह जगह DC Inside नहीं है।
 
dlehals2 2025-08-22

यहाँ DC नहीं है..
 
kht6163 2025-08-22

बकवास अंदाज़
 
GN⁺ 2025-08-22
Hacker News की राय

  • पूरी तरह सहमत हूँ साथ ही, मुझे लगता है कि LLM code को वास्तव में इस्तेमाल करने के लिए सचमुच prompt wizard बनना पड़ता है मैं इसे कभी-कभी सिर्फ debugging या UI को जल्दी sketch करने के लिए इस्तेमाल करता हूँ असली code की बात करें तो, LLM द्वारा लिखा गया code सचमुच spaghetti code होता है, बहुत verbose होता है, performance और security के लिहाज़ से गंभीर जोखिम रखता है, और मैंने जो लगभग हर design pattern दिया है उसे पूरी तरह गलत समझ लेता है

    • Hacker News और Reddit पर AI coding को लेकर skeptical पोस्टें जब भी देखता हूँ, मैं और ज़्यादा हैरान होता जा रहा हूँ लगता है जैसे हम सब पूरी तरह अलग-अलग दुनिया में जी रहे हैं मुझे लगता है tools की विविधता भी इसका एक कारण है मेरा मानना है कि "LLM code का इस्तेमाल" हर व्यक्ति के लिए कुछ अलग मतलब रखता है खास तौर पर कौन-सा LLM इस्तेमाल हो रहा है, उसे कौन-सा context दिया गया है, और कौन-सा IDE इस्तेमाल हो रहा है, इन सबका नतीजों पर बहुत असर पड़ता है agentic coding के आने से पहले मैंने खुद 2 लाख lines का B2B SaaS code लिखा था अब Sonnet 4 Agent mode में मैं रोज़ जो code लिखता हूँ उसका सिर्फ लगभग 20% मैं लिखता हूँ और बाकी 80% VS Code के interactive Sonnet और GitHub Copilot Agents लिखते हैं जितना ज़्यादा मैं Markdown में documentation करता हूँ, यह अनुपात उतना ही बढ़ता जाता है मैं output को बहुत ध्यान से review और test करता हूँ

    • जानना चाहूँगा कि आप कौन-सा tool इस्तेमाल करते हैं मैं aider इस्तेमाल कर रहा हूँ, और coding में कमज़ोर माने जाने वाले gpt-5 जैसे model के साथ भी, मुझे आपका बताया हुआ अनुभव बिल्कुल नहीं हुआ यह वास्तव में "अच्छा" code लिखता है, और मौजूदा code style से भी अच्छी तरह मेल खाता है prompt लिखना सचमुच बहुत महत्वपूर्ण है, और मौजूदा codebase में अगर implementation hints खास तौर पर दे सकें, तो success rate साफ़ तौर पर बढ़ जाता है यह वह हिस्सा है जो codebase को अच्छी तरह जानने वाला senior आसानी से कर सकता है, लेकिन junior के लिए मुश्किल हो सकता है मुझे लगता है कि हर पहलू को साफ़-साफ़ देखना चाहिए अभी भी कई बार aider से चलाने की तुलना में खुद करना थोड़ा-सा तेज़ पड़ता है, लेकिन अंतर बड़ा नहीं है और यह लगातार बेहतर हो रहा है LLM junior developer के कुछ कामों की जगह ले सकता है, लेकिन पूरी तरह replace नहीं कर सकता क्योंकि junior meetings में भी जाता है, discussions भी lead करता है, और अंततः senior बनने का growth path भी रखता है लेकिन management को शायद इन बातों में दिलचस्पी न हो

    • AI बड़ी मात्रा की जानकारी को धुंधले तरीके से खोजने के लिए शानदार tool है आजकल मैं Kagi के Assistant को सामान्य search से पहले ज़्यादा इस्तेमाल करने लगा हूँ यह मुझे वह शब्द बता देता है जो मुझे नहीं सूझ रहा होता, और फिर मैं उस शब्द से pages खंगालकर आखिरकार वही ढूँढ लेता हूँ जो चाहिए लेकिन vibe coding में मुझे इससे कोई खास लगातार value नहीं मिली one-off कामों में यह बेहतरीन है उदाहरण के लिए, matplotlib chart बनाते समय, अगर मैं इसे बता दूँ कि क्या चाहिए और data schema दिखा दूँ, तो यह 90% तक सही कर देता है shell script भी आसानी से बना देता है हाल में मैंने इसे EXIF information के आधार पर RAW photos को folders में organize करने वाला एक छोटा CLI tool बनाने को कहा था, और इस तरह के कामों में मैं इससे बहुत संतुष्ट हूँ लेकिन जैसे ही थोड़ा ज़्यादा complex कुछ कहो, यह बहुत-सा बेकार काम करने लगता है project में पहले से मौजूद models को फिर से बना देता है, असंबंधित changes कर देता है, या न होने वाले API functions गढ़कर बकवास कर देता है जितना समय result verify करने में लगे, उससे बेहतर है कि मैं खुद लिख लूँ और मेरे लिए coding का सबसे मज़ेदार हिस्सा वही है जब मैं खुद code लिखता हूँ LLM अभी तक मुझे ऐसे किसी उदाहरण के लिए उपयुक्त नहीं लगा जहाँ इंसान prompt के ज़रिए अस्थायी रूप से result ले, फिर उसे तुरंत save, integrate और handoff करे

    • AI उन सैकड़ों ad-भरी, बेतरतीब websites में से मुझे चाहिए जवाब जल्दी छाँटकर देने में बहुत उपयोगी है मैं Duck Duck Go AI को सवाल-जवाब के लिए अक्सर इस्तेमाल करता हूँ मैं उस पर उतना ही भरोसा करता हूँ जितना किसी data center को फेंक सकूँ, लेकिन जल्दी verify की जा सकने वाली जानकारी, जैसे किसी program की syntax या command options जैसी साफ़ चीज़ों में यह उपयोगी है

    • AI के इस्तेमाल में 'जितना डालोगे, उतना पाओगे' वाली बात बिल्कुल सटीक बैठती है अगर आप अंदरूनी कामकाज, edge cases, architecture, library selection वगैरह समझाने में बहुत समय लगाएँ और उन्हें ध्यान से Markdown में लिखें, तो कुछ बार दोहराने के बाद इस्तेमाल लायक code मिलने की संभावना काफ़ी बढ़ जाती है "X feature बना दो" जैसे छोटे prompt की तुलना में बहुत बड़ा फ़र्क पड़ता है लेकिन अगर आप इतना अच्छा prompt लिख पा रहे हैं, तो असल में आपने समस्या लगभग सुलझा ही ली है, और LLM सिर्फ एक तेज़ automatic typing machine रह जाता है typing ही तेज़ होती है, सोचने का ज़्यादातर काम तो इंसान पहले ही कर चुका होता है

  • मुझे लगता है कि कम-से-कम एक CEO इस हिस्से को समझता है juniors को छोड़कर सिर्फ AI से भरने का विचार लंबे समय में कंपनी के लिए बुरा है अगर senior लोग अलग होकर निकल जाएँ, तो पीछे कुछ नहीं बचेगा सच कहूँ तो मुझे नहीं पता कि AI किसी भी engineer के लिए, juniors सहित, सचमुच फायदेमंद है या नहीं software engineering खोज और सीखने की यात्रा है हर बार AI इस्तेमाल करते समय मुझे अपने math teacher की वह बात याद आती है कि "calculator इस्तेमाल करोगे तो दिमाग़ में कुछ नहीं टिकेगा" कुल मिलाकर ऐसा भी लगता है कि AI पिछले 45 वर्षों की अमेरिकी आर्थिक नीतियों का स्वाभाविक परिणाम है यह सिर्फ 1% के लिए short-term results का पीछा करना है, और healthy corporate ecosystem या economy के long-term development को नुकसान पहुँचाने का तरीका है यह सब देखकर लगता है Jack Welch बहुत गर्व महसूस करते

    • “अगर senior लोग चले जाएँ तो क्या होगा?” CEO वास्तव में senior के जाने की चिंता करने वाला व्यक्ति नहीं है बल्कि वह "junior को रहने दो" कहता है, लेकिन उसका निहितार्थ है "senior को बाहर करो", और यह मौजूदा industry trend से मेल खाता है OP के quote में कहा गया है कि "[juniors को replace करने] का विचार ‘मेरी सुनी हुई सबसे बेवकूफ़ी भरी बातों में से एक’ है", और साथ ही यह भी कि juniors शायद सबसे सस्ते कर्मचारी हैं और AI tools इस्तेमाल करने में सबसे ज़्यादा उत्साही भी आखिरकार इसका मतलब है कि capability और skill को ही threat, risk factor की तरह देखा जा रहा है पूरी industry को यह संकेत दिया जा रहा है कि ‘हड़बड़ी’ बनाए रखो और intellectual competitiveness के टूटने की रफ़्तार को जितना हो सके तेज़ करो

    • "कम-से-कम एक CEO ठीक से समझता है"

"AI हर engineer के लिए फ़ायदेमंद नहीं भी हो सकता" अगर CEO का interview सुनें तो यह CEO तो coding LLM अपनाने में पूरी तरह all-in दिखता है वह गर्व से कहता है कि AWS engineers के 80% लोग पहले ही LLM इस्तेमाल कर रहे हैं और आगे यह संख्या और बढ़ेगी मैं सलाह दूँगा कि interview के सिर्फ 10 मिनट ही सुन लें

* मुझे लगता है कि AI ने कुल मिलाकर मेरी learning process में मदद की है
  जिन personal projects को मैं सालों से बनाना चाहता था, उन्हें मैं हमेशा इसलिए छोड़ देता था क्योंकि शुरुआत की बाधा बहुत बड़ी लगती थी
  AI की वजह से repetitive और boring काम आसानी से हो जाते हैं, इसलिए मैं project को सचमुच completion तक धकेल पाया
  शायद AI के बिना शुरू से अंत तक अकेले करने पर मैं ज़्यादा सीखता, लेकिन अगर मैं शुरू ही नहीं कर पाता तो मुझे कुछ भी हासिल नहीं होता
  अब मैं सचमुच साफ़ तौर पर ज़्यादा सीख रहा हूँ

* अगर senior बने भी रहें लेकिन बदलाव या adoption में रुचि न लें या बहुत धीमे हों, तो वह भी risk है
  मुझे लगता है कि AI adoption से juniors की सीखने और बढ़ने की speed बहुत तेज़ हो जाएगी

  • पिछले कुछ महीनों में startups के साथ काम करते हुए मैंने कई ऐसे मामले देखे हैं जहाँ लोग LLM vibe coding में इतना गहरे फँस गए कि अब निकल नहीं पा रहे कई बार वे सही talent hire नहीं कर पाए थे या tech talent खो चुके थे वे AI code, खासकर Claude code, को internal 10x engineer समझ बैठते हैं और तेज़ iteration और बेहतर code की उम्मीद करते हैं मैंने कई काफ़ी समझदार founders को खुद Claude code से मिलने वाले उस dopamine के आदी होते देखा है, जिसमें लगता है जैसे उसने कई हफ्तों या कई सालों का software engineering काम कर दिया हो यह मान लेना कि AI complex problems को ‘सोच’ सकता है या ‘समझ’ सकता है, उसे बहुत ज़्यादा credit देना है मेरा मानना है कि हमें असली reasoning की जगह ‘typing speed में बचत’ को मापना चाहिए [1] vibebusters.com

  • मैं पूरी तरह सहमत हूँ कि "सोचना कैसे है" और "problem को decompose कैसे करना है" यह सिखाया जाना चाहिए engineering school के सबसे अच्छे professor हमेशा open-book exams लेते थे असल दुनिया में हर किसी के पास सभी data और information देखने का माहौल होता है लोगों को सिर्फ data खोजने के लिए पैसे नहीं दिए जाते, बल्कि data को analyze करने, समझने और उसे logically apply करने की क्षमता के लिए पैसे दिए जाते हैं इसी को engineering कहा जाता है, और वही professor यही सिखाते थे

    • कॉलेज में मैंने abstract algebra की class ली थी हर exam question या तो कोई प्रसिद्ध proof याद करके लिखना होता था, या नया proof बनाना होता था याद करना खुद में ज़बरदस्ती जैसा लगा, लेकिन फिर समझ आया कि proof को समझे बिना उसे याद करना संभव ही नहीं जब खुद नया proof बनाना होता था, तब दिमाग़ में पहले से modules बने होते थे, इसलिए approach कहीं ज़्यादा intuitive हो जाती थी मेरे हिसाब से असली memorization algorithm problem solving style के code को रटने जैसी चीज़ नहीं है, और actual application coding कहीं ज़्यादा human-centered improvisation, state-based on-the-fly graph traversal जैसी होती है वास्तविक समस्याओं में हमेशा कोई तय sequence नहीं होता, आख़िरकार heuristics ही मुख्य चीज़ है

    • मुझे लगता है कि hiring में यह इस क्षेत्र की सबसे मूल समस्या है सचमुच सक्षम developers मूलतः generalists होते हैं specialization की निश्चित रूप से value है, लेकिन पुराने legacy code hell या limits push करने जैसी स्थिति न हो तो expert का होना हमेशा ज़रूरी नहीं बल्कि unfamiliar stack पर काम कर चुका व्यक्ति कमज़ोरियों को भर सकता है या नया नज़रिया दे सकता है एक सक्षम general developer किसी भी stack में जल्दी adapt कर लेता है क्योंकि हर company का इस्तेमाल किया जाने वाला tech stack अलग तरह की उलझन होता है "15 साल React experience" जैसी शर्त लगा देने से भी, जो भी आए, तुरंत max-level productivity दे पाएगा ऐसा नहीं है onboarding time तो हर हाल में चाहिए लेकिन वास्तविक hiring managers अक्सर यह बात अच्छी तरह नहीं समझते बड़ी companies कुछ हद तक training देती हैं, लेकिन अब वह माहौल भी पहले जैसा नहीं रहा hiring competition में लाखों dollars खर्च किए जाते हैं, लेकिन किसी को भरकर विकसित करने की लागत पर उतना ध्यान नहीं दिया जाता पूरे industry level पर भी कोई professional association होना चाहिए जो hiring और talent development की संरचना को पूरी तरह बिगड़ने से रोके, लेकिन ऐसा कुछ नहीं है, इसलिए समस्या और बढ़ जाती है (मेरा मानना है कि हाल के layoffs, outsourcing आदि की वजह से unions पर ध्यान जाना भी इसी संदर्भ का हिस्सा है)

    • मुझे लगता है कि ऐसा बदलाव पहले से ही हो रहा है पारंपरिक CS curriculum का आधा हिस्सा mathematics है, और बाकी आधा भी नाम अलग होने के बावजूद मूलतः mathematics ही है academia की आलोचना बहुत होती है, लेकिन जब कोई कहता है कि "academia बेवकूफ़ है, इसे यह सिखाना चाहिए था", तो अक्सर वह चीज़ या तो पहले से सिखाई जा रही होती है या फिर ज़रूरत के हिसाब से जल्दी सीखी जा सकने वाली होती है ज़्यादातर नए trends वे चीज़ें हैं जो पहले से की जा रही हैं

    • कॉलेज के समय philosophy department का marketing slogan था, "thinking major, सोचने में major करो" hiring manager के रूप में मेरे अनुभव में humanities पढ़े हुए लोग analysis और understanding जैसी मूलभूत चीज़ों में कहीं बेहतर होते हैं मैं खुद CS/philosophy double major था, इसलिए मुझमें bias हो सकता है, लेकिन सिर्फ बहुत code लिख लेने वाले व्यक्ति की तुलना में analytical thinking वाला junior सचमुच कहीं ज़्यादा क़ीमती होता है analytical thinking को सिखाना coding से कहीं ज़्यादा कठिन है

    • computer engineering के एक professor थे जो business या user perspective से problem को decompose किए बिना सीधे coding शुरू कर देने को “crazy finger syndrome” कहते थे उस professor के 'सिर्फ coding करना चाहने वाले बेचैन students' पर किए गए jokes याद आते हैं मुझे लगता है कि हाल के bootcamps हमेशा ऊँचे ethical standards से मेल नहीं खाते

  • मैंने यह सवाल सुना है, “अगर भविष्य में किसी ने भी ठीक से सीखना ही बंद कर दिया, तो क्या होगा?” मुझे लगता है बहुत-से लोग इस निष्कर्ष को पहले ही स्वाभाविक मान चुके हैं फिर भी, ज़्यादातर companies जिस ढाँचे में long-term sustainability से ज़्यादा short-term profitability पर ध्यान देती हैं, उससे बाहर निकलना आसान नहीं होगा कम-से-कम internships/co-op को talent pipeline बनाए रखने के उपाय के रूप में लगातार ज़ोर दिया जा रहा है मुझे आगे ऐसा trend भी दिखता है कि junior developer hiring की मुश्किलों से बचने के लिए कंपनियाँ internships पर और ज़्यादा ज़ोर देंगी

  • अगर मैं अपना अनुभव संक्षेप में कहूँ, तो कुछ ऐसा है हमारे boss ने "AI adoption की वजह से बहुत-से लोगों को निकाला जाएगा" जैसा घोषणात्मक PR किया और AI leader होने का दिखावा किया, लेकिन असल में सब कुछ पूरी तरह गड़बड़ निकला, और अब मैं खुद आगे बढ़कर माफ़ी और सफ़ाई दे रहा हूँ

    • boss -> VP: "AI की वजह से लोगों की संख्या घटानी होगी" VP -> जनता: "2 साल के भीतर सभी engineers को AI से replace कर देंगे" boss -> VP: "VP को भी AI की वजह से कम करना होगा" VP -> जनता: "लोगों को AI से replace करना बेवकूफ़ी है"

    • फिर भी junior developers hire नहीं किए जा रहे हैं

  • लगता है AWS CEO ने भी अपना रुख बदल लिया है एक साल पहले उन्होंने कहा था कि "2 साल के भीतर AI सारा coding करेगा" [1] लगता है आखिरकार c-suite वास्तविकता स्वीकार करने लगा है [1] https://news.ycombinator.com/item?id=41462545

    • CEO ने वास्तव में ऐसा नहीं कहा था उन्होंने सिर्फ इतना कहा था कि 2 साल के भीतर developers शायद लगभग कोई code न लिखें और फिर आगे कहा, "अब हमें इस पर ज़्यादा ध्यान देना चाहिए कि क्या बनाना है, कैसे बनाना है, और असल customers को क्या चाहिए" article link शुरुआती premise से लेकर अभी के बयान तक context लगातार एक जैसा है "code लिखना" खुद कम महत्वपूर्ण हो सकता है, और इसलिए juniors को hire करके उन्हें सीखने का तरीका सिखाना चाहिए और ऐसी capabilities विकसित करनी चाहिए जो वास्तव में उपयोगी हों

    • सिद्धांत रूप में Amazon की market value का बड़ा हिस्सा talent capability है कुछ लोग workforce को सिर्फ cost मानते हैं और कहते हैं कि सारी value shareholders की है लेकिन अगर human assets की सचमुच value है, तो यह दावा करना कि सिर्फ AI से कोई भी वह value हासिल कर सकता है, उल्टा stock price के लिए बुरा है इसमें PE (price-to-earnings ratio) के गिरने का risk भी है, इसलिए इसे सकारात्मक मानना अजीब है अगर आप सच में मानते हैं कि सिर्फ AI होने से कुछ भी किया जा सकता है, तो shareholder के नज़रिए से capital किसी FAANG की तरह स्थिर रूप से बँधी नहीं रह सकती, और उसे लगातार नए 'next growth item' ढूँढने का बोझ उठाना पड़ेगा

    • executives के लिए हमेशा समय की दिशा को समझना ज़रूरी होता है

    • यह बिल्कुल भी विरोधाभासी बयान नहीं है autonomy वाले AI को निर्देश देने के लिए सिर्फ seniors ही नहीं, juniors से शुरू होने वाली talent pipeline भी अनिवार्य है बड़ी companies इस pipeline की चिंता करती हैं, जबकि छोटी companies उसे downstream में लेकर short term में सिर्फ seniors hire कर सकती हैं और interns न लें

    • दोनों बयानों के बीच कोई तार्किक विरोध नहीं है juniors को hire करना जारी रह सकता है, जबकि उनका काम actual coding से काफ़ी अलग हो जाए

  • अगर किसी को लगता है कि boss और CEO की position अलग है, तो मैं कहूँगा कि खुद जाकर verify करें news articles को context के बिना यूँ ही quote करना अच्छा नहीं है क्योंकि वास्तव में भविष्य की भविष्यवाणी कोई नहीं कर सकता [1]: https://www.shrm.org/topics-tools/news/technology/ai-will-shrink-corporate-workforce--amazon-ceo-warns

    • मुझे नहीं लगता कि दोनों CEOs के बयान एक-दूसरे से टकराते हैं "हमें college graduates को hire करते रहना चाहिए और उन्हें software बनाने का सही तरीका सिखाना चाहिए" - Matt Garman "आज जो कई काम लोग करते हैं, उनमें इंसानों की ज़रूरत कम हो जाएगी" - Andy Jassy फर्क सिर्फ nuance का है, मूल बात काफ़ी मिलती-जुलती है

    • मेरा मानना है कि quote करते समय मूल बात को context सहित यथासंभव समान रूप में quote करना नैतिक है किसे quote के लिए चुना जाता है, और किस तरह का context बनाया जाता है, उसी से news का tone तय होता है

    • दोनों बयान तार्किक रूप से बहुत consistent हैं

    • AWS से निकल चुके व्यक्ति के रूप में, मैं AWS के आधिकारिक बयानों पर पूरी तरह भरोसा नहीं करता मुझे पहले से पता था कि AWS कैसी company है, और मैं 46 साल की उम्र में अपनी 8वीं नौकरी के रूप में वहाँ गया था एक role जिसे "permanent remote" कहा गया था, उसमें भी मेरे इस्तीफ़ा देने के बाद RTO का आदेश आ गया था

  • academia में research talent pipeline कुछ इस तरह होती है undergraduate -> graduate student -> postdoc -> tenure/senior बहुत ही कम exceptions को छोड़ दें, तो शुरुआती दो stages छोड़कर कोई senior researcher नहीं बनता हर industry में यही बात लागू होती है juniors के बिना seniors नहीं बन सकते, इसलिए अगर आप चाहते हैं कि 'bots' सब कुछ करें, तो उसका risk भी तैयार रखिए

  • मुझे पूरा यक़ीन है कि जिन लोगों ने इन models के साथ लंबे समय तक काम किया है, वे सब इससे सहमत होंगे o3 release से पहले sama AGI post और उस समय tech जगत की doomer posts, पीछे मुड़कर देखें तो सचमुच बेतुकी लगती हैं

    • AGI doomerism सिर्फ एक marketing strategy थी अब हर कोई AI की असलियत समझता है, और अब हम बस AI द्वारा सारे documents पढ़कर सुनाने वाले एक नए search market की फिर से वापसी देख रहे हैं

    • यह शुरू से ही बेवकूफ़ी भरा noise था, लेकिन कोई भी ‘hype’ से पूरी तरह मुक्त नहीं रहता खासकर इसलिए क्योंकि बहुत सारा पैसा technology की वास्तविकता से ज़्यादा उसे बढ़ा-चढ़ाकर पेश करने वाली astroturfing में लगाया गया था

    • मुझे लगता है ChatGPT किसी भी ऐसे junior developer से बेहतर है जिसके साथ मैंने काम किया है junior लगभग एक साल तक team के लिए net negative होता है वास्तविक projects की ज़िम्मेदारी उठाने वाले व्यक्ति के रूप में मैंने कभी नहीं सोचा कि "काश कुछ और juniors होते" बल्कि 20% ज़्यादा देकर किसी mid-level को poach कर लेना कहीं बेहतर है