- software engineering उन क्षेत्रों में से है जहाँ AI का अपनाना तेज़ रहा है, लेकिन यह कहानी कि AI एक निश्चित क्षमता स्तर पर पहुँचते ही बड़े पैमाने पर layoffs करवा देगा, अभी उपलब्ध सबूतों से समर्थित नहीं है
- Block, Snap, Intuit के मामलों में AI layoffs के औचित्य के रूप में सामने आया, लेकिन असली पृष्ठभूमि वित्तीय दबाव, लागत घटाने की ज़रूरत, और management layers कम करने से ज़्यादा सीधे जुड़ी थी
- software development निर्णय, execution और delivery की sandwich structure है; AI execution layer को compress करता है, लेकिन क्या बनाना है यह तय करना, और नतीजों को validate कर उनकी ज़िम्मेदारी लेना, automation का मज़बूती से प्रतिरोध करता है
- “vibe coding” वह तरीका है जिसमें बिना supervision या review के agents पर काम छोड़ दिया जाता है, जबकि वास्तविक engineers agents को agentic engineering शैली में इस्तेमाल करते हैं, जहाँ इंसान control और accountability बनाए रखते हैं
- अगर AI से software production की लागत घटती है, तो software की माँग बढ़ सकती है; individual engineers के careers हिल सकते हैं, लेकिन कुल demand मज़बूत बनी रहने की संभावना है
AI ने software engineers को क्यों replace नहीं किया, और आगे भी क्यों नहीं कर पाएगा
-
Coding agents as normal technology
- AI jobs replace करेगा या नहीं, इसको लेकर चिंता और अनिश्चितता बहुत है, लेकिन इस सवाल को समझने के लिए उस क्षेत्र को देखना ज़रूरी है जहाँ AI की क्षमता और adoption तेज़ी से बढ़ी है: software engineering
- यह कहानी कि AI क्षमता एक खास threshold पर पहुँचते ही बड़े पैमाने पर layoffs शुरू हो जाएँगे, उपलब्ध सबूतों के आधार पर खारिज की जा सकती है
- अगर लगभग बिना regulatory barriers वाले क्षेत्र में भी बड़े पैमाने पर layoffs की यह कहानी सच नहीं बैठती, तो दूसरे professions में और भी बड़े buffers होने की संभावना है
- knowledge work और software development को decide-execute-deliver sandwich की तरह देखा जा सकता है; AI execution layer को compress करता है, लेकिन decision और delivery layers सिर्फ capability बढ़ने से automate नहीं हो जाते
- software engineering demand के भविष्य को लेकर सावधानीपूर्ण आशावाद संभव है, लेकिन कुल demand स्वस्थ रहने पर भी individual engineers के careers अस्थिर हो सकते हैं
software क्षेत्र में AI-जनित बड़े पैमाने के layoffs के मामले आम तौर पर “AI washing” के अधिक क़रीब हैं
-
Block का मामला
- Block ने फ़रवरी में 4,000 कर्मचारियों की छँटनी की घोषणा की, और Jack Dorsey ने कहा कि AI “छोटी और flat teams” को संभव बनाता है, साथ ही 2025 के अंत तक model capabilities में सुधार का ज़िक्र किया
- बाद की रिपोर्टिंग ने अलग तस्वीर दिखाई: Block ने pandemic के दौरान headcount को तीन गुना से अधिक बढ़ाया था और फिर उस पर भारी वित्तीय दबाव था
- Cash App team की data scientist Naoko Takeda ने लिखा कि Block ने AI सब पर थोप दिया था, लेकिन productivity gains बहुत सीमित थे; उन्होंने 75% retention raise proposal ठुकराया और इस्तीफ़ा दे दिया
- interview देने वाले दूसरे कर्मचारियों की Block में AI क्या कर सकता है और Dorsey मुद्दे को कितना समझते हैं, इस पर काफ़ी अलग राय थी
- Aaron Levie ने कहा कि CEOs तेज़ prototype तो देख लेते हैं, लेकिन उसे finished product बनाने में लगने वाले 90% काम को नहीं देख पाते, जिससे AI की utility को लेकर भ्रम पैदा होता है
-
Snap का मामला
- Snap ने अप्रैल में लगभग 1,000 लोगों को निकाला, और Evan Spiegel ने layoff memo में AI को मुख्य कारणों में बताया
- Spiegel ने कहा कि नया code का 65% AI द्वारा generate किया गया था
- लेकिन वास्तविक layoffs activist investor campaign के बाद हुए, जिसने लागत घटाने की माँग की थी
- Snap ने 2017 IPO के बाद हर साल net loss दर्ज किया, और 2026 में उसका stock 30% से अधिक गिर गया
- छँटनी की प्रकृति यह थी कि augmented reality division में अलग-अलग भूमिकाओं के 150 पद हटाए गए; अगर AI असली कारण होता, तो company-wide programming या AI-exposed roles में cuts अपेक्षित होते
-
Intuit का मामला
- Intuit ने मई में 3,000 कर्मचारियों की कटौती की घोषणा की, और साथ में Anthropic तथा OpenAI के साथ contracts की खबर भी आई
- media ने इसे AI-केंद्रित restructuring से जोड़ा, लेकिन CEO ने कहा कि layoffs का AI से संबंध नहीं है
- कंपनी ने बताया कि कटौती “high-coordination roles” और अत्यधिक management layers में थी
- Block, Snap, Intuit के मामले दिखाते हैं कि AI अक्सर layoffs के सतही औचित्य के रूप में सामने आता है, जबकि वास्तविक पृष्ठभूमि संगठनात्मक हालात और cost structure से अधिक सीधे जुड़ी होती है
-
AI washing पूरी अर्थव्यवस्था में दिखने वाली घटना है
- software engineering layoffs की जिन AI-कहानियों की समीक्षा की गई, उनमें हर बार narrative mismatch का वही पैटर्न दिखा
- अमेरिका में 59% hiring managers ने माना कि hiring freeze या layoffs समझाते समय वित्तीय सीमाओं की तुलना में AI पर ज़ोर देना stakeholders को ज़्यादा स्वीकार्य लगता है
- Forrester के J. P. Gownder ने कहा कि जब AI-आधारित layoffs की तैयारी कर रही कंपनियों से पूछा जाता है कि क्या उनके पास mature और validated AI apps हैं, तो दस में से नौ के पास कुछ भी नहीं होता, और उन्होंने शुरुआत भी नहीं की होती
- HBR survey में दुनिया भर के 1,000 से अधिक executives में 21% ने AI को “anticipate” करते हुए बड़े पैमाने पर headcount cuts किए, और 39% ने low या medium स्तर की preemptive cuts कीं
- लेकिन वास्तविक AI implementation के कारण पहले से बड़े पैमाने पर headcount cut करने वालों का हिस्सा सिर्फ 2% था; यह anticipation-based cuts और real implementation-based cuts के बीच बड़ा gap दिखाता है
-
WARN Act data
- WARN Act उन business closures और mass layoffs के लिए विशेष disclosures की माँग करता है जो 100 से अधिक workers को प्रभावित करते हैं
- New York राज्य ने मार्च 2025 में अमेरिकी राज्यों में सबसे पहले WARN Act filing form में AI disclosure checkbox जोड़ा
- पहले एक साल में 160 से अधिक कंपनियों ने WARN notices दायर किए, लेकिन किसी ने भी AI box पर check नहीं किया
- मई के अंत तक New York Department of Labor की पुष्टि के अनुसार केवल Nespresso ने checkbox चुना था
- अगर filings सही हैं, तो उस अवधि में New York राज्य के लगभग 25,000 laid-off workers में से सिर्फ 46 लोग AI से प्रभावित थे, यानी लगभग 0.2%
-
layoffs, AI productivity effects को देखने का ग़लत signal हैं
- research बताती है कि AI productivity effects मौजूदा कर्मचारियों को बड़े पैमाने पर निकालने के बजाय hiring slowdown के ज़रिए काम करते हैं
- मौजूदा कर्मचारियों को हटाने पर वह tacit knowledge और organizational capital खो जाता है, जो AI का प्रभावी उपयोग करने के लिए ज़रूरी है
- layoffs severance, morale damage और rehiring risk के लिहाज़ से भी महँगे होते हैं
- सिर्फ natural attrition के ज़रिए भी कुछ वर्षों में वही नतीजा पाया जा सकता है, इसलिए mass layoffs अक्सर अनावश्यक होते हैं
-
employment trend data
- Federal Reserve के economists का paper अमेरिकी संदर्भ में उपलब्ध सबूतों को समेटता है
- employment अब भी बढ़ रहा है, लेकिन ChatGPT के बाद यह उस counterfactual path की तुलना में सालाना लगभग 3 percentage points धीमा बढ़ा है, जो AI के बिना होता
- इस research methodology में self-employment शामिल नहीं है, इसलिए growth slowdown का कुछ हिस्सा startups की ओर shift में absorb हुआ हो सकता है
- दूसरी studies इस बात के सबूत देती हैं कि AI entrepreneurship को आसान बनाता है
- वास्तविक तस्वीर Federal Reserve study से भी अधिक स्वस्थ हो सकती है
-
AI-संबंधित job losses वास्तव में मौजूद हैं, लेकिन उनका प्रकार अलग है
- जब AI product demand को घटा देता है, तब software engineering jobs में नुकसान हो सकता है
- Chegg और Stack Overflow ऐसे उदाहरण हैं जहाँ AI ने homework help या technical help products की demand को घटाया, और दोनों कंपनियों ने layoffs किए
- इस स्थिति में AI ने सीधे workers का काम नहीं किया, बल्कि उस काम की ज़रूरत को कम कर दिया
- 1950 की अमेरिकी census की 270 occupations में automation से गायब हुई occupation सिर्फ elevator operator थी, लेकिन telegraph operator जैसी कई भूमिकाएँ नई technology के कारण अनावश्यक हो गईं
- IBM या SAP जैसी AI बेचने वाली कंपनियों में layoffs भी workers replacement से अधिक, मौजूदा functions से तेज़ी से बढ़ती product lines की ओर talent reallocation वाली सामान्य corporate restructuring के क़रीब हैं
coding agents labor replacement में क्यों नहीं बदले: decide-execute-deliver sandwich
-
AI द्वारा लिखे गए code का अनुपात labor replacement से लगभग असंबंधित है
- कुछ tech leaders AI द्वारा लिखे गए code के अनुपात को layoffs या भविष्य की jobs में गिरावट के अनुमान के साथ पेश करते हैं
- यह तरीका इस सरल सोच को मज़बूत करता है कि अगर AI सारा code लिख दे, तो coders की ज़रूरत नहीं रहेगी
- लेकिन AI-written code ratio labor replacement को समझने के लिए लगभग अप्रासंगिक metric है
- code writing bottleneck नहीं था, और पहले भी नहीं था
-
code writing bottleneck नहीं था
- 2019 के एक paper ने पहले के research को मिलाकर निष्कर्ष निकाला कि developers coding पर अपने समय का सिर्फ 9% से 61% तक खर्च करते हैं, जो आश्चर्यजनक रूप से कम है
- यह परिणाम Microsoft के 6,000 developers के internal data से भी मेल खाता है
- coding agents के adoption शुरू होने के बाद 2025 के अंत तक कई लेखों ने भी कहा कि code writing bottleneck नहीं है
- developers समझते हैं कि चाहे agents ज़्यादातर code लिख दें, कुल productivity पर उसका असर सीमित हो सकता है
-
तीन असली bottlenecks
- असली bottleneck यह तय करना और specify करना है कि क्या बनाया जाए
- deliver हुए परिणाम को validate करना और उसकी ज़िम्मेदारी लेना भी एक मुख्य bottleneck है
- codebase, business और environment की गहरी मानवीय समझ decision और delivery दोनों के लिए ज़रूरी है
- software engineer का काम decision, execution और delivery की sandwich है, और understanding इन तीनों layers की बुनियादी शर्त है
- AI ने sandwich के बीच वाले हिस्से को compress किया है, लेकिन दोनों किनारे ज़्यादातर वैसे ही बने हुए हैं
-
“Writing Code vs. Shipping Code” सबूत
- Writing Code vs. Shipping Code में 100,000 GitHub developers पर AI productivity effects का विश्लेषण किया गया
- AI agents ने लिखी गई code lines को 8 गुना बढ़ाया, जो इस बात से मेल खाता है कि execution layer काफ़ी compress होती है
- लेकिन releases में सिर्फ 30% की वृद्धि हुई, जो मज़बूती से संकेत देता है कि decision और delivery layers में human bottlenecks अब भी बने हुए हैं
-
decision layer का बहुत पतला होना कठिन है
- development teams को तय करना होता है कि क्या बनाना है
- junior software engineers जो महत्वपूर्ण सबक सीखते हैं, उनमें से एक यह है कि requirements specification उम्मीद से कहीं ज़्यादा समय लेती है
- requirements specification को compress करने पर बाद के चरणों में अधिक दर्द होता है
- यह layer users की ज़रूरतों, market signals, organizational priorities और कई मामलों में regulatory constraints को ध्यान में रखती है, इसलिए automation कठिन है
- जैसे-जैसे AI capabilities बढ़ेंगी, AI को delegate किए जा सकने वाले decisions का दायरा बढ़ेगा, लेकिन जो decisions delegate किए जा सकते हैं वे competitive advantage का स्रोत नहीं रहेंगे
- human decision-making का मूल्य ऊपर के स्तरों पर शिफ्ट होगा, और software complexity समय के साथ बढ़ती रहती है, इसलिए इस प्रक्रिया की कोई साफ़ upper ceiling नहीं है
-
delivery layer accountability और validation की वजह से बनी रहती है
- human teams को उन outcomes की जवाबदेही लेनी होती है जिन्हें वे ship करते हैं
- भविष्य में कभी ऐसा हो सकता है कि teams mission-critical code को पर्याप्त testing और understanding के बिना deploy करें
- लेकिन आज का AI इतना अस्थिर है कि ऐसा अव्यवस्थित तरीका software teams और customers दोनों के लिए अस्तित्वगत ख़तरा बन सकता है
- भले ही technical barriers हट जाएँ, इसका मतलब यह नहीं कि इंसानों को AI को control सौंपना ही होगा
- साझा norms, law और policy के ज़रिए human accountability बनाए रखना संभव है
- liability law और sector-specific regulation पहले से speed barriers की तरह काम कर रहे हैं, और इन्हें और सख़्त किया जा सकता है
-
भविष्य का software engineer crane operator के ज़्यादा क़रीब होगा
- जैसे-जैसे execution layer का और हिस्सा AI को delegate होगा, software engineer की भूमिका crane operator जैसी होती जाएगी
- AI agents अधिकतर cognitive heavy lifting करेंगे, और इंसान का मुख्य काम agents की supervision और control होगा
- कुछ लोग कहते हैं कि cost के कारण human-controlled future संभव नहीं होगा
- लेकिन अपर्याप्त supervision वाले coding agents के operational databases delete कर देने या अन्य नुकसान पहुँचाने के उदाहरण पहले ही चर्चा में आ चुके हैं
- ऐसे मामले नए norm कम और sensational exceptions ज़्यादा हैं, जो AI पर अति-निर्भरता के ख़तरों से सीखने का अवसर देते हैं
- high-risk कामों में low-supervision AI use बढ़ रहा है या नहीं, इसे पहचानना software engineering ही नहीं, पूरी अर्थव्यवस्था के लिए एक महत्वपूर्ण data gap है
-
programming का संकुचन सिर्फ AI की वजह से नहीं है
- sandwich के compress होने का रुझान नया है, लेकिन सिर्फ AI की वजह से नहीं
- 20 साल से भी पहले Bureau of Labor Statistics ने programming और software engineering को अलग-अलग track करना शुरू किया था
- मोटे तौर पर programmers execution करते हैं, जबकि software engineers sandwich के बड़े हिस्से को संभालते हैं
- programming सिकुड़ गई, और इसे simple execution work माना गया, इसलिए इसका compensation भी काफ़ी कम है
- AI पुराने trend को तेज़ करता है और pure technical execution skills की value को और घटाता है
- यह pattern, जिसमें इंसान decision और delivery वाले सिरों पर गहराई से शामिल रहते हैं और AI बीच की execution layer automate करता है, पूरे knowledge work में व्यापक रूप से लागू हो सकता है
Vibe coding, agentic engineering नहीं है
-
terminology confusion
- “vibe coding” शब्द को बहुत अलग-अलग practices के लिए ढीले ढंग से इस्तेमाल किया जा रहा है, जिससे software engineering में हो रहे बदलावों को लेकर भ्रम पैदा हो रहा है
- वास्तविक vibe coding में user agent को बस बता देता है कि क्या करना है, और execution के दौरान supervise नहीं करता, न ही code review करता है
- इस user में code review करने की क्षमता भी नहीं हो सकती, और वह नतीजों को सिर्फ तब परखता है जब कुछ साफ़ तौर पर टूट गया हो
- यह उस तरीके से अलग है जिससे अधिकांश software engineers agents का इस्तेमाल करते हैं
-
Agentic engineering
- अधिकांश software engineers agents को tools की तरह इस्तेमाल करते हैं, जबकि outcome पर control और accountability इंसान के पास रहती है
- इस practice के लिए agentic engineering शब्द का उपयोग बढ़ रहा है
- जैसे-जैसे agentic engineering standard बन रही है, engineers यह पा रहे हैं कि coding agents की supervision उम्मीद से ज़्यादा समय लेती है
- Simon Willison ने कहा कि agents की निगरानी करते-करते वे सुबह 11 बजे तक mentally exhausted हो जाते हैं; यह वास्तविक अनुभवों से भी मेल खाता है
-
SWE-chat data
- SWE-chat logging tool में स्वेच्छा से शामिल हुए open source developers की coding-agent interactions का dataset है
- इस study में agents द्वारा बनाए गए code का 44% हिस्सा ही user commits तक जीवित रहा
- vibe-coded commits ने human-only commits की तुलना में 9 गुना अधिक दर से vulnerabilities पेश कीं
- सबसे सामान्य user intent नया code generate करना नहीं, बल्कि existing code को समझना था; अनुपात 19% बनाम 13% था
- dataset self-selected sample है, इसलिए सिर्फ इस study के आधार पर मज़बूत निष्कर्ष नहीं निकाले जा सकते
- फिर भी यह दूसरे सबूतों को मज़बूत करता है कि vibe coding और agentic engineering अलग patterns हैं
-
मुख्य अंतर
- vibe coding और agentic engineering पूरी तरह अलग दो categories नहीं, बल्कि एक spectrum के दो छोर हैं
- सभी projects one-off projects या mission-critical projects में साफ़-साफ़ नहीं बँटते
- सभी workflows किसी table के बाएँ या दाएँ column में ठीक-ठीक फिट नहीं बैठते
- jobs के सवाल में महत्वपूर्ण बात यह है कि कंपनियाँ unvalidated vibe coders को software engineers की जगह रखकर production software deploy नहीं कर सकतीं
आगे क्या हो सकता है
-
बड़े पैमाने पर layoffs की भविष्यवाणी के टिकना कठिन क्यों है
- AI advocates कह सकते हैं कि mass layoffs अभी आए नहीं हैं, बस आने वाले हैं
- लेकिन अगर sandwich model सही है, तो ऐसी भविष्यवाणियाँ सच नहीं होंगी
- AI ने sandwich की बीच वाली layer को पहले ही काफ़ी compress कर दिया है, और यह compression वास्तव में दशकों पहले शुरू हो चुका था
- भले ही execution layer तुरंत और पूरी तरह perfect हो जाए, मौजूदा स्थिति से बदलाव सीमित रहेगा
- decision और delivery layers के AI का प्रतिरोध करने की वजह capability limits नहीं हैं
-
software engineers की demand बढ़ भी सकती है
- AI सिर्फ software engineering jobs को खत्म नहीं करेगा, demand बढ़ा भी सकता है
- technology productivity बढ़ने से software बनाने की लागत घटेगी, तो लोग अधिक software खरीदेंगे
- economics की भाषा में software की price elasticity अधिक है
- अगर AI software engineers को replace नहीं करता, तो software demand में वृद्धि software engineers की derived demand भी बढ़ाएगी
- “Jevons’ paradox” वह आर्थिक शब्द है जिसका AI discourse में अक्सर इसी विचार को समझाने के लिए उपयोग होता है
-
ऐतिहासिक pattern
- अमेरिका में programmers की employment 1950 के आसपास लगभग शून्य थी, लेकिन आज वह लाखों में है
- यह agriculture जैसी occupations से बहुत अलग है, जहाँ mechanization और automation ने labor demand को बुरी तरह घटाया
- इंसानों की calorie consumption अपेक्षाकृत स्थिर रहती है, लेकिन उत्पादित software की मात्रा दस लाख गुना बढ़ सकती है
- आधुनिक कारों में कई onboard computers पर चलने वाला लगभग 100 million lines of code होता है
- code demand की कोई upper ceiling हो भी, तो हम अभी उसके आस-पास नहीं हैं
- लगभग हर cognitive काम software से लाभान्वित होता है, और AI coding cost घटाकर work और personal use के लिए one-off utilities बनवाना आसान कर रहा है
-
इसका मतलब सिर्फ Big Tech का और बड़ा होना नहीं है
- भविष्य में software बहुत ज़्यादा हो सकता है और software engineers की संख्या भी बढ़ सकती है, लेकिन इसका मतलब यह नहीं कि बड़ी tech कंपनियाँ ही और बड़ी होंगी
- आज भी software engineers का बड़ा हिस्सा non-software कंपनियों के internal organizations में काम करता है
- यह हिस्सा आगे और बढ़ सकता है
- “AI rollups” उस विचार को कहा जाता है जिसमें venture capital या private equity dental clinics, accounting firms जैसे Main street businesses खरीदकर उनमें software engineers या AI engineers जोड़ते हैं और उन्हें AI-native रूप में फिर से बनाते हैं
- यह विचार सिर्फ hype भी साबित हो सकता है; अभी निश्चित रूप से कहना जल्दबाज़ी होगी
-
democratization prediction पर आपत्ति
- कुछ लोगों का अनुमान है कि AI software engineering को democratize कर देगा और software engineering demand घट जाएगी
- उनका मानना है कि उत्पादित software और software production में लगने वाला human time दोनों बढ़ेंगे, लेकिन यह काम software engineers के बजाय दूसरे लोग करेंगे
- उदाहरण के लिए, उनका तर्क है कि legal software वह व्यक्ति ज़्यादा आसानी से बना पाएगा जिसे software engineering training की जगह legal training मिली हो
- लेकिन यह दावा vibe coding और agentic engineering, तथा execution layer और पूरी sandwich के बीच भ्रम पैदा करता है
- FORTRAN, COBOL, SQL जैसी पुरानी languages भी अपने समय में programming democratization की उम्मीदों के साथ आई थीं, लेकिन ऐसा नहीं हुआ
- असली barrier syntax सीखना नहीं, बल्कि accountability बनाए रखते हुए अच्छे decisions लेने की परिपक्व judgment है
-
individual careers में बड़े structural बदलाव आ सकते हैं
- समय के साथ लोगों के कंप्यूटर से नए काम करवाने में लगाया जाने वाला समय बढ़ने की संभावना है
- यह activity software बनाना, agents की मदद से complex workflows manage करना, या किसी और रूप में हो सकती है
- आवश्यक skills software skills, AI skills और domain expertise का मिश्रण होंगी
- आज के software engineers इन नई भूमिकाओं के लिए सबसे बेहतर ढल पाएँगे या नहीं, यह अभी स्पष्ट नहीं है
- कुल software labor demand मज़बूत रहने का मतलब यह नहीं कि individual workers प्रभावित नहीं होंगे
- AI software production के तरीके में बड़े structural changes ला रहा है, और कौन-से engineers लाभ में रहेंगे या नुकसान उठाएँगे, यह उनकी company type, geography, seniority और adaptation speed पर निर्भर करेगा
1 टिप्पणियां
Hacker News की राय
कंप्यूटर इंडस्ट्री के पूरे इतिहास में हमने software engineering automation को आक्रामक और उत्साहपूर्वक आगे बढ़ाया है, और हर बार इससे हम बड़ी और बेहतर चीज़ें अधिक तेज़ी से बना पाए हैं
जैसे-जैसे productivity बढ़ी, काम का मूल्य भी बढ़ा और expectations भी साथ में ऊपर गईं, और अब तक दुनिया में software की demand असीमित रही है
AI software engineers को replace नहीं कर पाया क्योंकि हर बार productivity बढ़ने पर target भी साथ में आगे खिसक गया
यह प्रवाह दो स्थितियों में खत्म हो सकता है: पहली, productivity इतनी बढ़ जाए कि दुनिया की software demand पूरी की जा सके
अभी ऐसा कोई सबूत नहीं दिखता, और यह भी साफ़ बताना होगा कि इस बार पूरी computer industry के इतिहास से यह क्यों अलग है
दूसरी, जब AI स्वायत्त रूप से काम करते हुए इंसानों से बेहतर software engineer बन जाए
यानी ऐसी स्थिति जहाँ AI+मानव developer, अकेले AI से बेहतर न हो; लेकिन अब तक के सबूत यही दिखाते हैं कि AI developers का amplifier है, और अच्छे नतीजों के लिए expert को दिशा देनी पड़ती है जबकि AI ज़्यादा से ज़्यादा 90% काम करता है
निकट भविष्य में इन दोनों में से किसी एक के होने का मज़बूत सबूत नहीं है, इसलिए software engineers फिलहाल सुरक्षित दिखते हैं
लेकिन अगर आपकी technical breadth कम है और आप किसी खास क्षेत्र, जैसे frontend web development, पर केंद्रित हैं, तो चिंता ज़्यादा होनी चाहिए
भले ही AI पूरे software engineering पेशे को replace न करे, लेकिन generalist के निर्देशन में कुछ खास domains को पूरी तरह absorb कर लेने की संभावना काफ़ी अधिक है
कुल मिलाकर हम पहले ही लोगों की वास्तविक ज़रूरत से ज़्यादा software बना रहे हैं, और उसका बड़ा हिस्सा कचरे से लेकर खुली धोखाधड़ी, यहाँ तक कि लगभग malicious चीज़ों तक फैला हुआ है
अंततः शायद to-do list management या file sync जैसी छोटी-छोटी ज़रूरतों के लिए आम लोग अपने-अपने AI से customized software लिखवाएँगे, और software engineers सिर्फ बड़े enterprise projects में रह जाएँगे
पिछले कई दशकों में commercial software की सबसे भारी प्रवृत्ति चरम anti-user non-customization रही है
सिर्फ एक happy path छोड़ा गया है, और अगर वह आपकी ज़रूरत के मुताबिक न हो तो मानो कहा जाता है कि फिर खुद ही देखो
आम लोगों के लिए commercial software लगभग है ही नहीं, और open source भी सामान्य users से दूर होता जा रहा है
जल्द ही साधारण लोग अपनी तरह से समस्याएँ हल करने वाला software खुद बना सकेंगे
ज़्यादातर मामलों में quality और accuracy उतनी महत्वपूर्ण नहीं होंगी; customized, free होना, और intrusive surveillance/advertising platform न होना उससे ज़्यादा महत्वपूर्ण होगा
एक frontend developer के रूप में, मुझे लगता है कि मौजूदा state-of-the-art models वह उबाऊ backend plumbing work अच्छी तरह कर लेते हैं जिसकी मुझे परवाह नहीं, लेकिन वास्तविक customers जो customized design चाहते हैं, उसमें वे अभी भी अच्छे नहीं हैं
मेरा मतलब यह नहीं कि कोई निश्चित रूप से सही या ग़लत है; मैं इस बात से सहमत हूँ कि नई दुनिया में सफल होने का सबसे अच्छा तरीका ज़्यादा general technical breadth है
लेकिन अभी LLM stack के किसी एक हिस्से पर इतना पूरी तरह कब्ज़ा नहीं कर पाया है कि उस क्षेत्र के specialists ही गायब हो जाएँ
हालिया analysis के मुताबिक लॉन्च होने वाले apps की संख्या बहुत बढ़ी है, लेकिन कुल reviews और downloads स्थिर हैं
यानी apps बहुत ज़्यादा हो गए हैं, लेकिन users उतने नहीं बढ़े, या लगभग नहीं बढ़े
इसके लिए "WRITING CODE VS. SHIPPING CODE: PRODUCTIVITY EFFECTS ACROSS GENERATIONS OF AI CODING TOOLS" का p40 / figure 12 देखें: https://www.nber.org/system/files/working_papers/w35275/w352...
analysis पेज 42~43 पर है
यह साबित नहीं किया जा सकता कि pie fixed है, लेकिन इसका उलटा भी साबित नहीं किया जा सकता कि pie infinite है
software की economic growth की चर्चा में लोग जो अहम बात भूल जाते हैं, वह यह है कि पैसा कहीं-न-कहीं से आना चाहिए
growth जारी रखने के लिए कोई ऐसा व्यक्ति, जो अभी software पर पैसा नहीं खर्च कर रहा, उसे नया भुगतान शुरू करना होगा; और देखना होगा कि वे लोग कौन हैं, उनके पास कितना पैसा है, और वह किन दूसरे खर्चों से प्रतिस्पर्धा करेगा
बहुत-सी कंपनियाँ आज भी custom spreadsheets या Microsoft Access जैसी technology पर निर्भर हैं
क्योंकि वे ठीक वही काम कर देती हैं जो चाहिए, उनकी लागत स्थिर रहती है, और उनमें अतिरिक्त बदलाव या maintenance बहुत कम चाहिए होता है
अगर हम अपने बंद bubble के बाहर देखें, तो पता चलता है कि बहुत से लोग upgrade में दिलचस्पी नहीं रखते; वे बस चाहते हैं कि जो पुरानी चीज़ वे पहले से जानते हैं, वही चलती रहे
और मुझे यह भी साफ़ नहीं दिखता कि वह अनुपात 99% तक क्यों नहीं पहुँच सकता
AI निश्चित रूप से software engineer को replace करेगा
जैसा कि लेख में कहा गया है, missing हिस्सा delivery·operations है, और वह software engineer से ज़्यादा DevOps/SRE/Cloud engineer का क्षेत्र है
मैं cloud engineer के रूप में काम करता हूँ, और मेरे कई non-engineer दोस्तों ने मुझसे संपर्क किया कि अब वे अपने side project को शुरू से कई languages में बना सकते हैं और उसे local, web app, native app के रूप में चला सकते हैं
उनमें जो कमी है, वह “सामान्य developer” की तरह आसानी से deploy और maintain कर सकने वाला platform है
अभी इस foundation को बनाना काफ़ी झंझट वाला है, लेकिन AGENTS.md, skills, और सख्त integration tests से यह पर्याप्त रूप से संभव है
एक बार यह बन जाए, तो non-technical user claude/codex को अपनी ज़रूरत बताकर software engineer को hire किए बिना भी development जारी रख सकते हैं
claude/codex पहले से तय architecture के आधार पर निर्णय ले सकता है और non-technical user का मार्गदर्शन कर सकता है
मेरे anecdotal case में AI ने पहले ही कई software engineer को replace कर दिया है
अगर इस तरह की foundation को productize कर दिया जाए, तो greenfield project को agent coder और platform engineering के ज़रिए सिर्फ product perspective से manage किया जा सकता है
यही आज की स्थिति है, और बस 5 साल बाद की कल्पना कर लीजिए
सिर्फ इसलिए कि non-engineer कोई app बनाकर ले आए, इसका मतलब यह नहीं कि AI ने software engineer को replace कर दिया है या कर देगा
आप Dr. Google से symptoms खोजकर lifestyle changes, herbal remedies, और OTC दवाइयाँ आज़मा सकते हैं, और सचमुच फ़ायदा भी हो सकता है, लेकिन इससे doctors बिल्कुल गायब नहीं हो जाते
generative AI से music theory, musical sense, या creativity के बिना भी music बनाया जा सकता है, लेकिन इससे musical talent वाले लोग खत्म नहीं हो जाते
AI की मदद से घर का DIY किया जा सकता है, फिर भी engineers गायब नहीं हो जाते
domain expert को वास्तव में क्या चाहिए, यह prototype-iteration improvement के ज़रिए स्पष्ट करने में कौन मदद करेगा
hobby software makers जिन operating system, language, version control system, editor, terminal emulator, knowledge/document management system, PaaS platform आदि पर निर्भर हैं, उन्हें कौन लिखेगा और maintain करेगा
क्या उन्होंने जो बनाया है, उसका इतना सही testing किया है कि उसे robust कहा जा सके
क्या वे उन edge cases को समझते हैं जो सामने आ सकते हैं
security ठीक है
prompt देकर जल्दी से कुछ बना लेना engineering के बराबर नहीं है
शायद लोग ऐसा इसलिए नहीं देख पा रहे क्योंकि वे यह गलती करते हैं कि software engineering की value मुख्यतः निकले हुए code, यानी bit array, में है
project की मुख्य value theory और abstraction को गढ़ने की प्रक्रिया में होती है: https://pages.cs.wisc.edu/~remzi/Naur.pdf
कुछ engineer 2 हफ्ते में app बनाकर फिर कभी उसे हाथ न लगाएँ, ऐसा हो सकता है, लेकिन ऐसे काम से जीविका चलाने वाला कोई व्यक्ति मैं नहीं जानता
“आपके business के लिए WordPress site” जैसी चीज़ें संभव हो सकती हैं
समस्या तब आती है जब 432 features हों और 433वाँ feature जोड़ते समय बाकी सबको छेड़े बिना काम करना हो
कुछ मामलों में ज़रा सी भी गलती नहीं हो सकती, और कभी-कभी एक feature ही complexity को engineer की संभालने की रफ़्तार से तेज़ बढ़ा देता है, जिससे समय के साथ project इतना बड़ा हो जाता है कि वह manage न हो सके
यह बड़े system के साथ integrate होने वाले छोटे application का idea था, और 2~3 दिनों में 3~4 commits के साथ proof of concept बन गया
यह प्रभावशाली था, लेकिन उसे बनाने वाले ने पिछले 3 महीनों में उस project पर 400 commits और किए, और fixes चलते-चलते practically उस app को बनाना और maintain करना part-time या full-time job बन गया
वह व्यक्ति प्रशिक्षित software developer नहीं होते हुए भी वैसा बन गया, और security या best practices को नहीं समझता
अगर Claude और बेहतर हो जाए, तो बोझ कम हो सकता है और शायद पूरा दिन न खाए, लेकिन अभी हमारी कंपनी के ये शुरुआती “vibe apps” सब के सब maintenance work बन गए हैं और लगातार ज़्यादा समय खा रहे हैं
यह साफ़ है कि लोग software कम नहीं, बल्कि ज़्यादा चाहते हैं
पारंपरिक software engineering भले गायब हो जाए, लेकिन expanding platform management, security, complexity, documentation, और business logic अब भी हमारी कंपनी के सामने मौजूद हैं
यह कहना सही है कि text से project बनाया जा सकता है, लेकिन सबसे simple software को छोड़ दें तो मुझे कभी भी “set and forget” जैसा कुछ नहीं लगा
अब भी किसी न किसी को पूरे system को manage करना पड़ता है
चाहे उस व्यक्ति ने software engineering की training ली हो या नहीं
experienced developer के untrained व्यक्ति से बेहतर करने की संभावना अब भी अधिक है
हाँ, जिज्ञासु builders तेज़ी से catch up कर सकते हैं, लेकिन पारंपरिक developers के पास अब भी बड़ा advantage है
क्योंकि हम हमेशा यह जानना चाहते थे कि अंदर चीज़ें कैसे काम करती हैं
वे लोग जो मौजूदा vibe app बनाने में कई महीने लगा रहे हैं, उसे मैं AI का इस्तेमाल करके एक घंटे में बना सकता था
vercelचलाने जितना आसान हो गया है, और agent भी सिर्फ़ request मिलने पर बिना किसी दिक्कत के यह कर सकता हैdesktop software deployment platform के हिसाब से थोड़ा अधिक कठिन है
फिर भी side project और शानदार software के बीच का gap अब भी बहुत बड़ा है, और यह मानना मुश्किल है कि वह gap कभी भर जाएगा
समझ नहीं आता कि AI से पहले जो समस्याएँ पहले ही solve हो चुकी थीं, वे पहले replace क्यों नहीं हुईं
यह मानना भी कठिन है कि personal project को complex infrastructure की ज़रूरत होती है
मैं किसी financial app को, जिसे अनिश्चितकाल तक maintain करना हो, vibe coding से नहीं बनाऊँगा
legacy system को भी नहीं छेड़ूँगा
AI ने कुछ engineers को replace किया है, यह स्पष्ट है, लेकिन non-engineer दोस्तों द्वारा side project बनाने के उदाहरण की relevance कम है
उन्होंने इसलिए बनाया क्योंकि अब यह संभव हो गया है; ज़्यादा संभावना यह है कि वे मूल रूप से किसी को hire करके इसे बनवाने वाले ही नहीं थे
जैसे अब तक उन्होंने hire नहीं किया था
मैं एक development agency में काम करता/करती हूँ, और हमारे ज़्यादातर client ऐसे startup हैं जिन्हें बहुत जल्दी market में जाना होता है
करीब डेढ़ साल से हम agent-based development इस्तेमाल कर रहे हैं, और इस दौरान हमारी भूमिका काफ़ी बदल गई है
project inflow के बारे में सटीक संख्या तो नहीं बता सकता/सकती, लेकिन जो बदलाव साफ़ दिखता है वह यह है कि delivery scope को लेकर expectations बदल गई हैं
पहले जो project 5 लोग करते थे, अब वही आमतौर पर 1~2 लोग करते हैं
व्यावहारिक रूप से greenfield project का बड़ा हिस्सा automate हो चुका है
UX/UI design iteration, system architecture iteration, और ऐसे कठिन problems पर कई approaches आज़माना जिनके लिए clear metrics नहीं हैं—ऐसे बहुत से manual काम अब तुरंत हो जाते हैं
अगर आप उसे दिमाग में समझ सकते हैं, तो मानो आप उसे दुनिया के सामने 100वें हिस्से के समय में ला सकते हैं
इस दौरान काम करने का तरीका और systems के बारे में सोचने का तरीका भी बहुत बदल गया है
अब हम LLM के साथ सहजीवी रूप से काम करते हैं, और इसके बिना काम करना सच में बहुत मुश्किल लगता है
इसका मतलब यह नहीं कि हम LLM द्वारा लिखा code समझ नहीं पाते; हम हर बदलाव को track करते हैं और codebase को LLM से कहीं ज़्यादा गहराई से समझते हैं
बस, manually code लिखने की क्षमता काफ़ी घट गई है, और मुझे लगता है कि यह ठीक है
अभी यह ज़्यादा ऐसा लगता है जैसे हम business goals और उन्हें सबसे अच्छी तरह support करने वाली technology के बीच एक translation layer हों
यह अब भी problem solving ही है, लेकिन कहीं ज़्यादा high-level problem solving, और अब भी दिलचस्प और मज़ेदार है
इस दौर में developers के लिए सबसे अच्छी strategy शायद यही है कि critical thinking बनाए रखें और tools को अपने फ़ायदे में इस्तेमाल करें
अब सबके पास superpower है
ज़रूरी नहीं कि आप किसी company में ही काम करें; एक solo developer भी अविश्वसनीय चीज़ें बना सकता है, इसलिए अब पहले जितनी दूसरों पर निर्भरता नहीं रही
शायद भविष्य एक ऐसी macro product economy हो, जहाँ हर व्यक्ति दुनिया को कुछ अनोखा दे
अगर agent coding greenfield project बनाने लायक काफ़ी अच्छी हो गई है, तो इसका असर सिर्फ developers पर नहीं बल्कि पूरी companies और पूरे industry sectors पर पड़ेगा
development agency का business model इसलिए मौजूद है क्योंकि जिन companies की technical capability कमज़ोर होती है उन्हें software सँभालना नहीं आता, और कुछ मामलों में यह शुरुआती labor-intensive काम को outsource करने का opportunistic तरीका भी होता है
लेकिन अब वही technology agency clients की उँगलियों पर है, इसलिए यह बस समय की बात है कि CEO और managers vibe coding शुरू करें और समझ जाएँ कि उन्हें बस “थोड़ी technical समझ वाला एक developer” चाहिए
यह बात कई SaaS businesses तक भी फैल सकती है
अब भी बहुत से छोटे business manual work हटाने के लिए custom software चाहते हैं, लेकिन गंभीर software developer हमेशा बहुत महँगे रहे हैं
इसलिए वे अक्सर किसी के भतीजे के बनाए ढीले-ढाले code या मुश्किल से चलने वाले SaaS पर निर्भर हो जाते थे
अब वे अपना custom solution बना सकते हैं, जो शायद अब भी काफ़ी rough होगा, लेकिन उससे ज़्यादा हासिल किया जा सकता है
Big Tech जो कर रही है वह recession के हिसाब से realignment के ज़्यादा क़रीब है; असल में ज़्यादा चिंताजनक बात mid-small tech sector की उथल-पुथल है
वजह यह भी है कि उनके पास clients लाने के लिए network नहीं होता
ज़्यादातर developers को ज़रूरत होती है कि company कम-से-कम marketing संभाले ताकि वे अपने असली काम पर ध्यान दे सकें
code generation और code discernment दिमाग की अलग-अलग क्षमताएँ हैं
programming में छोटे-छोटे syntactic details बहुत होते हैं, इसलिए code लिखने में दिक्कत होने पर भी review अच्छी तरह किया जा सकता है
https://xcancel.com/karpathy/status/2015883857489522876
असली दुनिया की सफल companies के पास data, patents·IP, network effects वगैरह के रूप में moat होता है
development time 100वाँ रह जाने का मतलब यह नहीं कि आप तुरंत कोई नया business बना सकते हैं
अगर अभी tech industry को देखें तो ऐसी बहुत-सी companies दिखती हैं जो agile AI-based builders से disrupt हो सकती हैं, लेकिन वास्तव में lock-in effects की वजह से ऐसा हो नहीं रहा
“1950 की अमेरिकी जनगणना में 270 occupations में से automation से सिर्फ elevator operator की job ही गायब हुई” वाला दावा ग़लतफ़हमी पैदा करता है
उसी अवधि में agricultural jobs workforce के 15% से घटकर 2% रह गईं
उसमें कहा गया है कि यह agriculture जैसे उन jobs से अलग है जहाँ mechanization और automation ने labor demand को बहुत घटा दिया
लोग जितनी calories consume करते हैं वह मात्रा काफ़ी स्थिर रहती है, और सिर्फ 25% बढ़ोतरी से obesity epidemic पैदा हो गया, लेकिन produced software की मात्रा लाखों गुना बढ़ गई—फ़र्क यह है
प्रतिशत वाला आँकड़ा गिरावट को बढ़ा-चढ़ाकर दिखाता है क्योंकि कुल workforce बढ़ गई थी
लेकिन अगर व्यापक food industry employment देखें, तो वह काफ़ी बढ़ी है
इसलिए “coder” employment घट सकती है, फिर भी व्यापक “software/tech” industry employment बढ़ सकती है
उस job category का लगभग 95% पहले ही automate हो चुका है, लेकिन वे अक्सर इसका दोष उल्लुओं पर डालते हैं
factories और conveyor belts के साथ भी यही हुआ
जब-जब automation आता है, लोग jobs खोते रहते हैं, और हम बस “उम्मीद” करते हैं कि वे कुछ और ढूँढ़ लें, या फिर “generalist बनो”, “specialist बनो”, “service sector में जाओ”, “coding सीखो”, “coal mining करो” जैसी अतिवादी और परस्पर-विरोधी आशावादी बातें सुनते हैं
सिर्फ @pmarca को सुन लें तो दिख जाता है कि tech leadership कितनी खोई हुई और incoherent है
industrial automation पर Stripe Press की नई किताब भी देखने लायक है: https://press.stripe.com/origins-of-efficiency
AI पर सबसे ज़्यादा भोला भरोसा रखने वाले लोग आम तौर पर tinkerers थे
LLM-assisted coding की वजह से किसी चीज़ के साथ छेड़छाड़ करने की रफ़्तार चौंकाने वाली तरह से बढ़ गई है, इसलिए यह समझ में आता है
tinkering एक process है, और लोग चीज़ें बनाने और उन्हें tweak करने की क्रिया से ही बहुत आनंद लेते हैं
result अक्सर दूसरी या तीसरी प्राथमिकता होता है
AI ने हमारी act करने और इस तरह tinkering करने की क्षमता को बहुत बढ़ाया है, लेकिन वह अपने-आप meaningful impact, यानी “engineering”, पैदा नहीं करता
activity से ज़्यादा impact मायने रखता है
prototyping, debugging, testing वगैरह सिर्फ इसलिए नकली काम नहीं हो जाते कि वे जल्दी होने लगे हैं
compiler भी अपने-आप impact पैदा नहीं करता
CI, IDE, frameworks, और cloud infra के साथ भी यही बात है
वे उन्हें इस्तेमाल करने वाले इंसान की leverage बढ़ाते हैं
पत्नी की जगह AI ने ले ली
वह programmer थी, और कंपनी ने खुलकर मेरी पत्नी और कुछ अन्य लोगों को replace करने के मकसद से agents बनाए थे, और उनके काम करना शुरू करने के लगभग एक महीने बाद उसे निकाल दिया गया
हमारी टीम में 18 महीने पहले एक नया boss आया था, और उसमें खुला favoritism था, और जिसे वह पसंद करता था वह इकलौता व्यक्ति था जो team player नहीं था
उसने 18 महीनों में remote workers को, उनके पिछले performance की परवाह किए बिना, निकालने का तरीका ढूंढ लिया
उनमें से एक को boss से ऊंचे level के कई awards भी मिले थे, लेकिन boss हमेशा उसी toxic व्यक्ति को पहचान देता था
यह AI replacement नहीं था, लेकिन लोगों को बेकार महसूस कराने वाला माहौल शायद AI से replace होने जैसा ही लगता होगा
मेरे supervisor सहित उस टीम के सभी लोग दूसरी नौकरियों के लिए apply कर रहे हैं
supervisor को high-functioning autism है, और boss अक्सर उसका मज़ाक उड़ाता है
उनकी mental health के लिए मैं सच में चाहता हूँ कि वे सफल हों
मैंने HR के सामने कई बार मुद्दा उठाया, और work policy में वे clauses भी ढूंढे जिन्हें boss तोड़ रहा था, लेकिन कम-से-कम यहाँ मैंने सीखा कि ऐसे नियम बस कागज़ी हैं
उल्टा इससे मेरी पीठ पर निशाना ही बन गया, इसलिए मुझे निकलना पड़ा
कई और लोगों ने भी चिंता जताई थी, और उनमें से ज़्यादातर बाद में दूसरी नौकरी ढूंढ चुके लोग हैं
शुक्र है, मुझे भी जल्द ही जाने के लिए नई नौकरी मिल गई और मैं उसे लेकर उत्साहित हूँ
उम्मीद है सब ठीक होगा
जानना चाहूँगा कि आगे क्या हुआ, क्या नई नौकरी मिली, और क्या अब भी software में ही हो
सिर्फ इसलिए कि AI layoffs पर corporate communication नकली है, इससे खतरा खत्म नहीं हो जाता
corporate पक्ष की बातें झूठी हो सकती हैं, लेकिन technology का असर असली हो सकता है, और इस context में वह सिर्फ noise है
लेख के burger diagram की तरह यह मानना भी बहुत plausible नहीं लगता कि execution stage छोटी होती जाएगी जबकि बाकी सारे stages बड़े हो जाएंगे, और इस तरह burger का कुल आकार वैसा ही रहेगा
फिर भी, software engineering के कुछ क्षेत्र अभी भी खतरे से बहुत दूर लगते हैं
खासकर वे क्षेत्र जहाँ correctness सबसे महत्वपूर्ण है
web development में बहुत ज़्यादा चीज़ें बस जैसे-तैसे चला देने की गुंजाइश होती है, लेकिन rocket guidance code अलग चीज़ है
LLM शायद दोनों कर सके, लेकिन बाद वाले को जल्द ही कोई vibe coding से करेगा, ऐसा नहीं लगता
AI सचमुच पहले से ही कुछ हिस्सों को replace कर चुका है, और आगे और भी करेगा
यह सभी software engineers को replace नहीं करेगा, लेकिन Pandora's box खुल चुका है, इसलिए कम-मेहनत, कम-जोखिम वाले काम AI करने लगेगा
Lovable जैसी services पर बहुत सारे projects वास्तव में production में चल रहे हैं, और विकल्प यह था कि उन्हें इंसान बनाते
नौकरियों को replace हमेशा employer करता है
graphics cards के ढेर को मानवीय रूप मत दीजिए
लेख का यह हिस्सा मुझे आश्वस्त नहीं करता
दावा यह है कि “असली bottleneck हैं (1) क्या बनाना है यह तय करना और उसे specify करना, (2) जो deliver हुआ है उसे verify करना और उसकी जिम्मेदारी लेना, (3) codebase, business, और environment की गहरी मानवीय समझ”
हो सकता है coding को महंगा और bottleneck माना जाता रहा हो, इसलिए upstream और downstream दोनों तरफ बहुत मेहनत की जाती थी ताकि input सही हो और output को फेंकना न पड़े
अगर coding को तेज़ और सस्ता stage माना जाने लगे, तो output को फेंका जा सकेगा, इसलिए upstream में उसी स्तर की oversight की ज़रूरत शायद न रहे
software के malfunction करने का असर और backward compatibility बनाए रखना उससे कहीं ज़्यादा बुरा है