Amazon में कुछ डेवलपर्स का कहना है कि उनका काम गोदाम के श्रम जैसा होता जा रहा है

 (nytimes.com)
7 पॉइंट द्वारा GN⁺ 2025-05-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Amazon डेवलपर्स AI अपनाए जाने के बाद काम की रफ्तार के दबाव और काम के सरलीकरण का अनुभव कर रहे हैं
  • मैनेजर उत्पादकता बढ़ाने के नाम पर AI टूल्स के उपयोग को जोरदार तरीके से प्रोत्साहित कर रहे हैं
  • कुछ लोगों का मानना है कि दोहराए जाने वाले काम घटने से काम की गुणवत्ता बेहतर हुई है, लेकिन जूनियर डेवलपर्स के लिए विकास के अवसर खोने की चिंता भी है
  • कोडिंग सीधे सृजन से हटकर समीक्षा और सत्यापन-केंद्रित काम बनती जा रही है, जिससे कुछ लोगों को लगता है कि यह अब उनका अपना काम नहीं रह गया
  • Amazon Employees for Climate Justice जैसे आंतरिक समूह इस मुद्दे सहित जॉब स्ट्रेस और भविष्य की संभावनाओं को लेकर चिंता साझा कर रहे हैं

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

कोडिंग भी अब ‘स्पीड रेस’ के दौर में

  • औद्योगिक क्रांति के बाद बार-बार दिखने वाली मशीनीकरण से नौकरी के सरलीकरण की घटना अब कोडिंग में भी दिख रही है
  • AI नौकरियां खत्म करने के बजाय मौजूदा भूमिकाओं को और सरल व तेज़ तरीके से किए जाने वाले रूप में बदल रहा है
  • Microsoft के शोध के अनुसार, AI सहायक ‘Copilot’ का उपयोग करने वाले डेवलपर्स की उत्पादकता 25% से अधिक बढ़ी
  • Amazon ने इसे अपनाते हुए AI के जरिए और तेज़ व अधिक कुशल काम की मांग की है, और शेयरहोल्डर पत्र में इसे ‘लागत घटाने और प्रतिस्पर्धा बनाए रखने’ की कुंजी बताया है
  • उदाहरण के तौर पर, एक डेवलपमेंट टीम पिछले साल की आधी टीम साइज पर चल रही है, फिर भी उससे उतनी ही मात्रा में कोड की अपेक्षा की जा रही है

कंपनियों में व्यापक रुझान

  • Shopify ने सभी कर्मचारियों के लिए AI उपयोग को बुनियादी आवश्यकता बनाया है और कहा है कि इसे प्रदर्शन मूल्यांकन में भी शामिल किया जाएगा
  • Google आंतरिक हैकथॉन में रोजमर्रा की उत्पादकता बढ़ाने वाले AI टूल्स के विकास को विषय बना रहा है। पहले से ही 30% से अधिक कोड AI सुझावों के जरिए बन रहा है

सकारात्मक पहलू और चिंताएं

  • कुछ मैनेजर्स का कहना है कि AI अपनाने से उबाऊ और दोहराव वाले काम कम हुए हैं, जिससे अधिक रचनात्मक काम पर ध्यान दिया जा सकता है
  • Amazon का कहना है कि AI की वजह से 4,500 साल के बराबर डेवलपमेंट काम की बचत हुई है
  • लेकिन Harvard के अर्थशास्त्री Lawrence Katz का कहना है कि शुरुआती स्तर के डेवलपर्स के लिए करियर ग्रोथ के अवसर खत्म हो सकते हैं
  • जैसे पहले फैक्ट्री मजदूरों ने ‘स्पीड रेस’ का दबाव झेला था, वैसे ही डेवलपर्स पर भी और तेज़, और अधिक काम निपटाने का दबाव बढ़ रहा है

डेवलपर्स को महसूस हो रहा बदलाव

  • Amazon के लॉजिस्टिक्स वेयरहाउस की तरह, डेवलपर्स भी AI की वजह से काम के ऑटोमेशन और बंटवारे को महसूस कर रहे हैं
  • AI का उपयोग ‘विकल्प’ है, लेकिन परफॉर्मेंस टार्गेट पूरा करने के लिए यह व्यवहार में लगभग अनिवार्य हो जाता है
  • जिन फीचर्स को पहले बनने में कई हफ्ते लगते थे, उन्हें अब कुछ ही दिनों में पूरा करना पड़ता है, और इसके लिए मीटिंग समय घटाया जा रहा है और AI-जनरेटेड कोड का उपयोग बढ़ाया जा रहा है
  • AI पूरे प्रोग्राम तक बना सकता है, लेकिन कोड पढ़ने और उसकी समीक्षा का काम बढ़ने से मज़ा और डूबकर काम करने की भावना घटती है

करियर विकास और जुड़ाव में कमी

  • जूनियर डेवलपर्स टेस्ट ऑटोमेशन की वजह से कोड को गहराई से समझने के अवसर खो सकते हैं
  • AI प्लानिंग डॉक्युमेंट लिखने, कोड टेस्ट करने जैसे कई कामों में मदद कर रहा है, लेकिन माहौल इंसान नहीं बल्कि टूल-केंद्रित मूल्यांकन की ओर बढ़ रहा है
  • Obama कैंपेन के पूर्व CTO Harper Reed का कहना है कि यह ऐसा दौर है जिसमें हर हिस्से को गहराई से समझना ज़रूरी नहीं रह गया, और यह मैन्युफैक्चरिंग जैसे बदलाव के समान है
  • दूसरी ओर, Simon Willison आइडिया को हकीकत में बदलने की गति तेज़ होने के लिहाज से AI को सकारात्मक मानते हैं

असंतोष और संगठनात्मक प्रतिक्रिया

  • AI के उपयोग और उससे जुड़े कामकाजी बदलावों के कारण कई डेवलपर्स Amazon Employees for Climate Justice समूह में अपनी चिंता और तनाव साझा कर रहे हैं
  • खासकर काम की गुणवत्ता में गिरावट और करियर की अनिश्चितता को लेकर चिंता अधिक है, जो पहले ऑटो उद्योग के मजदूरों द्वारा महसूस किए गए स्पीड रेस वाले तनाव जैसी है
  • अभी डेवलपर्स के यूनियन बनाने की कोई स्पष्ट हलचल नहीं है, लेकिन संगठन के भीतर साझा समझ और सहानुभूति बढ़ रही है

ऐतिहासिक संदर्भ और आगे की दिशा

  • 1936 की GM हड़ताल की तरह, नौकरी की रफ्तार और स्वायत्तता के सवाल मजदूर कार्रवाई के उत्प्रेरक बन सकते हैं
  • पहले व्यक्ति अपने काम के तरीके और गति को नियंत्रित कर सकता था, लेकिन अब व्यवस्था पूरी प्रक्रिया की निगरानी और स्पीड-केंद्रित मूल्यांकन पर आधारित होती जा रही है

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

1 टिप्पणियां

 
GN⁺ 2025-05-26
Hacker News राय
  • archive.ph/HVZRL लिंक में साझा की गई सामग्री
  • मुझे LLM-आधारित डेवलपमेंट, crypto या VR की तरह एक बढ़ा-चढ़ाकर पेश किया गया hype लगता है। हाल ही में vibe coding से लिखे गए codebase के bugs ठीक करते हुए लगा कि यह तरीका बिना किसी संरचना वाले business problems को वैसे ही code में ढाल देता है, यानी एक तरह का अव्यवस्थित chaos। जिन हिस्सों में सुधार चाहिए, उन्हें संकीर्ण patches से जोड़ते-जोड़ते नतीजा एक जटिल और बेतरतीब code बनता है। context window की सीमा आते ही LLM अपने ही patch भी याद नहीं रख पाता। English (या किसी भी human language) में मैं जो code चाहता हूँ उसे ठीक-ठीक समझाना अस्पष्ट होता है, और senior developers ने code में जो वर्षों का अनुभव और trial-and-error समेटा है, उसे prompt में पूरी तरह उँडेलना बेहद भारी काम है। "यह ऐसे क्यों लिखा गया" के उलट, असल में "ऐसी स्थिति में यह मत करो, वह करो" जैसी अत्यंत ठोस और अंतहीन सूची चाहिए होती है
    • यह observation पिछले 30 वर्षों में मैंने देखे लगभग हर (सिर्फ एक को छोड़कर) codebase के वर्णन से पूरी तरह मेल खाता है
    • एक आपत्ति—AI ने 30 के आसपास ऐसी जगहों पर code patterns ढूँढने में मदद की है जहाँ से structure निकालना था। मुझे लगता है vibe coding की समस्या तकनीक नहीं, रवैया है। जो लोग खुद coding से बचना चाहते हैं, वे long-term structure या quality से अधिक अभी की सुविधा पर ध्यान देते हैं; यह एक तरह का laziness amplifier है
    • हकीकत में बहुत सा production code patch पर patch लगाकर चलने वाले code snippets का संग्रह ही है। दुखद बात यह है कि CPU इतने तेज़ हैं कि ऐसा code भी बस चल जाता है
    • human language की अस्पष्टता वाली बात से सहमत हूँ। natural language के जरिए software को स्पष्ट रूप से नियंत्रित करने की कोशिश कई बार हो चुकी है, और कानून की तरह यहाँ भी gray areas की व्याख्या खत्म नहीं होती। अगर भविष्य में developers को compile से पहले program के अर्थ पर बहस करनी पड़े, तो वह भविष्य निराशाजनक होगा
    • AI सचमुच crypto या VR जितना बढ़ा-चढ़ाकर पेश किया गया hype लगता है। लेकिन software engineering जैसे अत्यधिक technical पेशों पर भी automation का असर पड़ेगा। पिछले 10 वर्षों में tech industry के लोगों ने मान लिया था कि वे बाकी workers की समस्याओं से अलग हैं, लेकिन replacement/layoff culture के कारण अब wages को दबाने की प्रक्रिया तेज़ हो रही है। भले AI तुरंत सबको replace न करे, पर अगर 5 लोगों का काम 4 लोग AI के साथ करने लगें, तो 1 की छँटनी होगी और बचे लोग भी salary hike माँगने से हिचकेंगे। तर्क यह है कि tech workers को समझना चाहिए कि वे भी आखिरकार workers ही हैं
  • Harper Reed के "code को गहराई से समझने की ज़रूरत नहीं" वाले विचार पर, ऐसी बात उलटे "compile हो रहा है तो deploy कर दो" जैसी जुगाड़ू सोच लगती है। automated line में quality लगातार मापी जाती है, फिर भी असली मशीनें कोण गड़बड़ा देने या कहीं और welding कर देने जैसी hallucination नहीं करतीं, जबकि LLM-आधारित software में ऐसी छोटी-छोटी त्रुटियाँ बार-बार होती हैं
  • संदेह है कि LLM-आधारित tools ने सच में developer productivity नाटकीय रूप से बढ़ाई है, या बस संगठनों ने यह खोज लिया है कि अब कम—और पहले से कम privileged—developers से भी काम चल सकता है। बड़े tech firms के भीतर "क्रांतिकारी productivity gains" के उदाहरण ज़्यादा नहीं दिखते, अभी तक तो बस इतनी-सी productivity improvement दिखी है जो investment को किसी तरह justify कर सके
    • इसका बड़ा हिस्सा perception का मामला है। पहले development कठिन काम माना जाता था, लेकिन AI tools आने के बाद coding की entry barrier कम दिखने लगी है। software development अब धीरे-धीरे factory work जैसा महसूस होने लगा है, और बौद्धिक संतोष कम हुआ है
    • codebase की long-term maintainability पर संदेह है। vibe coding धीरे-धीरे complexity, subtle bugs और abstraction problems जोड़ता जाता है, जिससे maintenance और नई features बनाना और कठिन होता है। short-term productivity gain के चक्कर में long-term quality गिर सकती है
    • संगठन पहले से ही bureaucratic प्रक्रियाओं के जरिए "de-skilling" करते आए हैं, यानी कम skilled लोगों को standardization के जरिए replace करना। यह लंबी अवधि में ज़हरीली रणनीति हो सकती है, लेकिन consistency मिल जाए तो वे "औसतन काम चलाऊ solution" पर संतुष्ट हो जाते हैं
    • इस तर्क के असरदार होने के लिए यह मानना पड़ेगा कि Amazon management short-term profit को long-term quality से ऊपर रखता है, लेकिन मुझे इस पर पूरा भरोसा नहीं
  • मैं जल्द ही retire होने वाला हूँ, और हाल के बदलावों से निराशा होती है। 90s में career शुरू किया था, तब लंबे समय तक experimentation और creativity में डूबने की गुंजाइश थी। अब unit tasks, status reports और लगातार justification देना ज़रूरी हो गया है। आगे भी दिलचस्प developers रहेंगे, लेकिन ऐसे अवसर कम होते जा रहे हैं। सच कहें तो यह वही रास्ता है जिस पर automation की वजह से मुश्किल में पड़े दूसरे पेशे पहले ही चल चुके हैं, इसलिए यह किसी अर्थ में न्यायसंगत परिणाम है
    • रोज़मर्रा की status reporting, stand-up आदि समय लेते हैं, और अक्सर बस उन लोगों से एक दिन की और आज़ादी पाने के लिए औपचारिक प्रतिक्रिया भर होते हैं जो मेरे काम को समझते ही नहीं; इससे काम का मूल्य घटता है
    • मैं भी 90s में industry में आया था और JIRA-आधारित सूक्ष्म नियंत्रण वाली स्थिति से सहमत हूँ। फिर भी मैं यह नहीं मानता कि पहले का दौर ही पूरी तरह स्वर्णयुग था। शायद पुरानी अच्छी बातों को ही याद रखने वाला nostalgia bias भी है। लेकिन आज भी पर्याप्त चुनौतीपूर्ण और अच्छे काम, और सीखने की चीज़ें मौजूद हैं
    • दिशा engineers की jobs के automation से ज़्यादा, practically management roles को AI-केंद्रित निगरानी से replace करने की लगती है
  • software development को नाटकीय रूप से तेज़ करने का एक तरीका यह भी है कि किसी के open source code को सीधे copy करके इस्तेमाल करो और copyright/license के निशान हटाकर लागू कर दो। अगर सीधे पकड़े जाने की चिंता हो, तो किसी outsourcing vendor से उसे "धुलवाया" जा सकता है, या आजकल AI से यह काम सस्ते और तेज़ तरीके से हो सकता है। Google पहले ऐसे व्यवहार से बचता था, उसमें साहस की कमी थी। लेकिन छोटे startups copyright violation के जोखिम को नज़रअंदाज़ करके AI का इस्तेमाल करते हुए तेज़ सफलता का दाँव खेल रहे हैं
    • जिस industry में मैं हूँ, वहाँ code की कमी से ज़्यादा बड़ी समस्या यह तय करना है कि "क्या" और "कैसे" बनाना है। कई अनोखी समस्याएँ Stackoverflow या Github से हल नहीं होतीं
    • Google भी असल में पहले से ही websites का content scrape करके उसे search results में सीधे दिखाता रहा है, यानी traffic दिए बिना दूसरों की सामग्री का उपयोग। इस बार भी वह बस देर से पहुँचा है
    • विडंबना यह है कि कुछ लोगों का कहना है कि वे चाहेंगे कि बड़ी कंपनियाँ open source code की नकल ही कर लें। क्योंकि उनके खुद के बनाए कठोर और अक्षम तरीकों को user के रूप में झेलने से वह बेहतर है
    • open source में code डालने की सीमाओं से सहमत हूँ। बड़ी कंपनियाँ अक्सर open source को free labor पाने के साधन की तरह बढ़ावा देती हैं। भले short-term में contributions कम हो जाएँ, लंबी अवधि में industry शायद इससे अधिक स्वस्थ बनेगी
    • ChatGPT के उभार और Sam Altman की leadership की गैर-जिम्मेदाराना प्रकृति की आलोचना
  • Simon Willison का यह कहना कि code लिखने से ज़्यादा कठिन और कम मज़ेदार काम code पढ़ना है, और Amazon developers का यह अनुभव कि AI documentation और testing जैसे सहायक कामों में बहुत मदद कर रहा है—ये बातें प्रभावशाली लगीं। अब coding से अधिक मौजूदा code review और bug fixing पर भूमिका शिफ्ट हो रही है
    • शुरुआती दिनों की याद आती है जब code लिखना मज़ेदार था। अब bugs ठीक करना ज़्यादा दिलचस्प लगता है, और LLM साधारण repetitive coding अपने ऊपर ले लेता है, जिससे मैं चुनौतीपूर्ण समस्याओं पर ध्यान दे सकता हूँ। LLM की वजह से development का कुछ आनंद बचा हुआ है
    • इस लेख से जो माहौल महसूस होता है, वह काफ़ी नकारात्मक है
  • जब भी productivity बढ़ाने वाली नई technology आती है, कंपनियाँ जल्दी उसका लाभ standardize कर लेती हैं। बराबरी बनाए रखने के लिए लगातार पढ़ना-सीखना पड़ता है, और कभी न कभी ऐसे माहौल में जाने पर भी विचार करना पड़ता है जहाँ अपनी growth का लाभ खुद मिल सके, जैसे self-employment। लेकिन अकेले काम करने का मतलब है AI में निपुण लोगों से प्रतिस्पर्धा करना, इसलिए कोई आसान समाधान नहीं है
    • तीन संभावित future scenarios दिखते हैं। 1) codebase धीरे-धीरे chaos और instability में ढहने लगते हैं, और अंत में experienced developers को महँगे दाम पर फिर लाना पड़ सकता है। 2) AI इतना-सा ठीक code बनाता रहेगा कि काम चल जाए; quality या reliability बहुत ऊँची न हो, पर बड़ी दुर्घटनाएँ भी न हों। 3) AI अचानक इतना intelligent हो जाए कि codebase की अवधारणा ही खत्म हो जाए, और software ज़रूरत पड़ते ही dynamically generate और evolve हो। मौजूदा LLM अभी इससे बहुत दूर हैं। corporate executives विकल्प 3 पर विश्वास करते हैं, लेकिन फिलहाल 1 और 2 ही अधिक यथार्थवादी हैं। अगर सही management हो, तो 2 वाले संतुलित दृष्टिकोण की ओर भी जाया जा सकता है
    • productivity gains को अधिक न्यायसंगत ढंग से बाँटने वाले models भी हैं। जैसे पुराने Europe में work hours कम करना। आज तो हाल यह है कि workers भी किसी अस्पष्ट, व्यस्त-दिखने वाले बेकार काम में उलझे लगते हैं
    • तुम मूलतः Marxist नज़रिया रख रहे हो, लेकिन मज़ेदार यह है कि निष्कर्ष फिर self-alienation पर जाकर रुकता है। थोड़ा-सा मिलकर दबाव बनाया जाए तो सुधार संभव है, पर लोग ऐसा करते नहीं
    • यह मानकर मत चलो कि जीवनभर लगातार self-improvement करते रहना ही एकमात्र रास्ता है; समाज के दूसरे लोगों के साथ मिलकर employer से सामूहिक माँग करने का रास्ता भी है। 5-day workweek, 8-hour workday और child labor ban भी collective action से ही मिले थे। सिर्फ अपना काम करते रहना और दूसरों की सफलता पर ध्यान देना ही ज़रूरी नहीं
  • हमारा industry जिस तरह बचकाना होता जा रहा है, वह हमेशा चौंकाता है। बड़े enterprises और बड़े codebases का अनुभव रखने वाला कोई भी जानता है कि नया code generate करना development का छोटा-सा हिस्सा भर है
    • वास्तव में नए code के अलावा बाकी सहायक काम भी बड़े enterprises में अक्षम हैं। AI शायद इन्हें भी बदले और लगातार होने वाली meetings या अमूर्त चर्चाएँ कम हों
    • अभी जो लोग बहुत उत्साहित हैं, उनमें से काफ़ी लोग दरअसल नवीनतम paradigms में उलझकर खुद code लिखने में कठिनाई महसूस करने लगे हैं। वे Copilot जैसे LLM tools से जल्दी POC बनाकर उसे production तक पहुँचा देते हैं, लेकिन quality, scalability आदि पर गहराई से नहीं सोचते। फिर वही लोग AI adoption से productivity बढ़ने के किस्से बिना शर्त बेचते हैं, और बड़े enterprises के हितों से मेल खाते दावे ही दोहराते हैं। जबकि जो लोग वास्तव में इन्हें इस्तेमाल करते हैं, वे जानते हैं कि ज़मीनी काम में कमियाँ बहुत हैं
    • मैं भी कुल समय का लगभग 20% ही coding में लगाता हूँ, बाकी requirements जुटाने, design, testing और schedule management में जाता है। अगर उस 20% code work का आधा समय बच जाए, तो शायद बचे समय में testing या documentation बेहतर कर पाऊँ
  • यह भ्रम है कि LLM की मदद से development efficiency भारी मात्रा में बढ़ जाएगी। सच तो यह है कि बुनियादी कौशल होने पर ही quality गिराए बिना productivity बढ़ सकती है। यानी skilled लोगों के लिए यह productivity amplifier है, लेकिन अगर सिर्फ बड़े पैमाने पर beginners की टीम को LLM पकड़ा दिया जाए, तो high-quality software बनाना मुश्किल है
    • यह बात बार-बार कही जाती है, लेकिन असली प्रश्न है कि "quality" की cutoff line कहाँ है। वास्तव में एक युवा developer study team के साथ मेरा एक SRE दोस्त साप्ताहिक reviews करता है और वे LLM का सक्रिय उपयोग करते हैं; code quality और scalability भी पर्याप्त है। गति धीमी है, पर नतीजा खराब नहीं
    • "अच्छा" software हर जगह ज़रूरी नहीं होता, और Deloitte, Accenture जैसी कंपनियों के revenue model को देखें तो अधिकांश businesses quality की परवाह ही नहीं करते। ज़्यादातर के लिए "काफ़ी ठीक दिखने वाला" software ही पर्याप्त है