क्या AI अकेले नहीं, पर AI वाला एक इंसान office के कई लोगों की जगह ले लेगा?

senior_slacker , 27 मई 2026, 4:02:30 pm.

सार्वजनिक 7 वार्तालाप 16 विचार 141 अपवोट 15 डाउनवोट्स 0 शृंखला 232 दृश्य

बहुत से office workers ग़लत सवाल से ख़ुद को तसल्ली दे रहे हैं। वे बार-बार पूछते रहते हैं कि क्या AI उनका पूरा काम कर सकता है। उनका employer यह कसौटी इस्तेमाल नहीं करेगा। असली सवाल यह है कि क्या output इतना सस्ता बनाया जा सकता है, और इतना सस्ता जाँचा जा सकता है, कि वह role महँगा लगने लगे। बात यह नहीं कि क्या AI हमारा पूरा काम कर सकता है, बात है "क्या यह इसे इतना तेज़ कर सकता है कि मेरी team का बस आधा हिस्सा ही चाहिए?"। क्योंकि इसका जवाब, अफ़सोस, हाँ है।

In groups

सोचा

asli_roadmap • 6 जून 2026, 7:48:49 am

"दस की team अब एक करेगा" वाला अंत post के बाक़ी हिस्से से कमज़ोर है। मैंने आज तक किसी team को इसलिए आधा होते नहीं देखा कि output सस्ता हुआ। जो होता है वह यह कि scope फैल जाता है: वही लोग अब तीन गुना feature, तीन गुना customer commitment संभालते हैं। compression असल है, पर headcount में नहीं, उम्मीदों में दिखती है। employer सस्ता output देखकर लोग नहीं घटाता, वह और माँग जोड़ देता है।

यह इसलिए मायने रखता है कि office के काम का एक बड़ा हिस्सा पहले से ही review करने लायक़ रूप में आता है। एक market note, एक draft, एक documentation pass, एक research summary। एक slide deck। साफ़ acceptance criteria वाला एक routine code fix। उन outputs के पीछे की हाथ की मेहनत भले अब भी असली हो, पर तैयार product अक्सर इतना सुलझा हुआ होता है कि कोई ज़्यादा senior इंसान उसे देख ले, ज़ाहिर ग़लतियाँ ठीक कर दे, और फिर भी पुरानी पूरी तरह लदी हुई labor की लागत से कम ख़र्च करे।

यही वह mechanism है जिसे लोग घूरकर देखना नहीं चाहते। AI को trust, judgment, या context की जगह एक साथ नहीं लेनी पड़ती। उसे बस पहले pass का इतना हिस्सा machine से बनने लायक़ बना देना है कि एक reviewer उस पर निगरानी रख सके जिसके लिए पहले कई लोग शून्य से बनाते थे। व्यवहार में इसका मतलब है कम analysts, कम coordinators, कम junior writers, clean-up का काम करने वाले कम junior coders, और बचे हुए लोगों पर ज़्यादा दबाव कि वे हर line ख़ुद बनाने के बजाय machine का output validate करें।

यह pattern तुम्हें आम workflow में पहले से दिख सकता है। एक manager को पहले एक analyst की ज़रूरत होती थी कि वह source material इकट्ठा करे, internal memo draft करे, और पहली recommendation को आकार दे। अब analyst शायद अब भी हो, पर शायद एक साथ कई managers को संभाल सकता है। या manager को कम analysts चाहिए। यही चीज़ code review में होती है। इंसान अब भी मायने रखता है, कभी-कभी बहुत, पर इंसान को ऊपर validation, edge cases, और ज़िम्मेदारी की तरफ़ खींच लिया जाता है जबकि सस्ता पहला pass कहीं और बन जाता है।

यही वजह है कि office का काम लोगों के मानने से ज़्यादा ख़तरे में है। ऐसा इसलिए क्योंकि information का काम पहले महँगा हुआ करता था। संगठनों को पहले pass के लिए इंसानों को पैसा देना ही पड़ता था क्योंकि उसे पाने का कोई और तरीक़ा था ही नहीं। एक बार पहला pass सस्ता हो जाए, तो role की क़ीमत ज़्यादा सख़्ती से आँकी जाने लगती है। role की क़ीमत अब सुलझी हुई भाषा बनाने के इर्द-गिर्द नहीं लगती। वह ownership, verification, और नतीजों के इर्द-गिर्द लगने लगती है।

art और दूसरे मुश्किल-से-तय होने वाले काम से इसका फ़र्क़ सीमित ही रहना चाहिए। अच्छा visual काम अब भी text, spreadsheet की logic, या routine code changes के मुक़ाबले ठीक-ठीक बताना मुश्किल और सस्ते में जाँचना मुश्किल है। इससे creative काम बचा हुआ नहीं हो जाता। इसका बस इतना मतलब है कि compression की logic वहाँ सबसे मज़बूत है जहाँ कामयाबी बताना आसान हो और नाकामी सस्ते में जाँची जा सके।

जो काम बेहतर बचता है वह हक़ीक़त के ज़्यादा क़रीब होता है। वह systems का मालिक होता है, नतीजों पर मुहर लगाता है, ज़िम्मेदारी सोखता है, और उस उलझे हुए context को संभालता है जो किसी review queue में करीने से नहीं समाता। उस इंसान की नौकरी को निचोड़ना ज़्यादा मुश्किल है जिसे किसी physical system को validate करना हो, किसी live client के झगड़े को संभालना हो, किसी outage के जवाब का मालिक होना हो, या तब फ़ैसला लेना हो जब inputs अधूरे हों और ग़लती की क़ीमत असली हो। अगर कुछ है तो यह उन बचे हुए इंसानी अड़चनों को और साफ़ कर देता है। मसलन engineers के लिए, यह code (और designs तक) लिखने की लागत काफ़ी घटा देता है, जबकि उन लोगों की क़ीमत बढ़ा देता है जो किसी चीज़ को ढालकर पूरा कर सकें। एक end-to-end इंसान होना, यानी कोई ऐसा जो किसी idea या feature को कई components में तोड़ सके और फिर उन्हें प्राथमिकता देकर उन पर execute कर सके, software engineering अब यही है। मुमकिन है तुम अब ज़्यादा code न लिखो, ख़ासकर जैसे-जैसे AI इसमें बेहतर होता जाए। पर तुम्हें patterns, designs, tooling समझने होंगे... और इन सबको एक साथ जोड़ना होगा।

हाँ, AI अपने दम पर कुछ नहीं बनाएगा। पर AI वाला एक इंसान वह बना देगा जो पहले 10 लोगों की team किया करती थी। तो, उन 9 से, तुम पक्के तौर पर कह सकते हो कि AI उनकी जगह ले रहा है।

Thoughts

process_ki_diary • 13 जून 2026, 6:36:48 am

इसमें एक परत और जोड़ दूँ। validation का काम तभी सस्ता है जब किसी ने पहले से document किया हो कि "सही" दिखता कैसा है। हमारी ज़्यादातर जगहों पर वह कहीं लिखा ही नहीं होता, वह उन्हीं junior के सिर में रहता है जिन्हें machine replace कर रही है। उन्हें हटाओ तो reviewer के पास output तो है पर वह कसौटी नहीं जिससे उसे जाँचा जाए।

Permalink
chhupa_hua_kaam • 12 जून 2026, 7:35:41 pm

आपकी बात का सबसे मज़बूत रूप यही है: role की क़ीमत अब language बनाने पर नहीं, ownership और verification पर लगती है। मानती हूँ। पर एक चीज़ छूट रही है। जो काम "clean-up" कहकर junior से छीन लिया जाता है, वही जगह थी जहाँ अगला senior बनता था। आप पहला pass सस्ता कर रहे हैं और साथ-साथ वह सीढ़ी हटा रहे हैं जिससे लोग validate करना सीखते हैं। पाँच साल बाद reviewer कहाँ से आएँगे।

Permalink
main_exit_liquidity • 11 जून 2026, 10:23:46 am

"end-to-end इंसान" यानी वो जो idea को components में तोड़कर ख़ुद execute करे। मेरे ज़माने में उसे "founder" कहते थे और उसे salary नहीं मिलती थी।

Permalink
asli_roadmap • 6 जून 2026, 7:48:49 am

"दस की team अब एक करेगा" वाला अंत post के बाक़ी हिस्से से कमज़ोर है। मैंने आज तक किसी team को इसलिए आधा होते नहीं देखा कि output सस्ता हुआ। जो होता है वह यह कि scope फैल जाता है: वही लोग अब तीन गुना feature, तीन गुना customer commitment संभालते हैं। compression असल है, पर headcount में नहीं, उम्मीदों में दिखती है। employer सस्ता output देखकर लोग नहीं घटाता, वह और माँग जोड़ देता है।

Permalink
main_exit_liquidity • 4 जून 2026, 8:00:11 pm

देख भाई, यह "AI वाला एक इंसान दस की जगह ले लेगा" वाली लाइन हर founder deck में 2019 से है, बस तब उसमें microservices लिखा था। नतीजा यह कि एक बंदा दस का काम करता ज़रूर है, पैसा एक का ही पाता है, और बाक़ी नौ का budget कहीं और "reinvest" हो जाता है। मैंने वह reinvestment देखी है। वो office के नए फ़र्नीचर में थी।

Permalink
udhaar_ka_faisla • 4 जून 2026, 12:06:10 am

सबसे सही बात इसी में है कि सवाल "पूरा काम" नहीं, "पहला pass" है। जिस चीज़ का साफ़ acceptance criteria हो, उसे validate करना उसे शून्य से बनाने से सस्ता है, यह सच है। पर एक चेतावनी: machine का पहला pass अक्सर इस तरह गलत होता है कि वह सही दिखे। उसे पकड़ने में जो वक़्त जाता है वह कई बार ख़ुद लिखने से ज़्यादा होता है, और यह बोझ हमेशा उसी senior पर गिरता है जो पहले से दो outage संभाल रहा है।

Permalink
byaaj_ka_dar • 2 जून 2026, 4:33:02 am

एक सवाल। अगर पहला pass सच में इतना सस्ता हो गया, तो company उस बचत का क्या करती है? labor cost घटने से margin बढ़ता है या वह बचत आगे price war में बह जाती है? क्योंकि अगर हर competitor के पास वही tool है, तो किसी की लागत नहीं बचती, बस सबका output सस्ता होता है। तब role तो दबाव में रहता है, पर वजह AI नहीं, वजह यह है कि advantage किसी के पास नहीं बचा।

Permalink
standing_desk_dikhawa • 1 जून 2026, 7:50:35 am

यार सही लिखा, बस जिस company में मैं हूँ वहाँ इसका अमल थोड़ा अलग दिखता है। उन्होंने junior नहीं घटाए। उन्होंने सबको एक AI license दिया, एक email भेजा "अब हम 2x productive हैं", और headcount वहीं रखा पर targets दुगने कर दिए। तो हाँ, एक इंसान दस का काम कर रहा है, बस वो दस अलग लोग नहीं, वही एक थका हुआ बंदा है।

Permalink
release_ka_hafta • 30 मई 2026, 7:23:57 am

पिछले दो release से यही चल रहा है। पहले एक junior pipeline का पहला draft बनाता था, मैं review करती थी। अब वह draft tool से आता है, और मैं पूरे दिन वही validate करती हूँ। काम कम नहीं हुआ, बस सारा का सारा मेरे जैसे लोगों पर खिसक गया जो पहले से release week में सोते नहीं। आपकी बात इस मायने में सही है, बस उसमें यह नहीं लिखा कि बचे हुए लोग किस हाल में हैं।

Permalink

Related discussions

क्या AI सचमुच managers को पागल बना रहा है?
एक नई executive कल्पना चल रही है, कि AI workers की जगह ले सकता है। हालाँकि यह कुछ की जगह तो ज़रूर ले रहा है, executives एक ऐसी कल्पना पाले हैं जिससे उन्हें लगता है कि वे अपने report का काम ख़ुद, AI के साथ कर सकते हैं। कि वे code कर सकते हैं! बस named agents से भरा एक dashboard खोलो, panes में tasks को सरकते देखो, हुक्म भरे लहज़े में update माँगो, और मनमर्ज़ी से features पूरे करवा लो। यह किसी सपने जैसा लगता है, ख़ासकर जब तुम अपने "think big ideas" इसमें डालते हो और AI तुम्हें बताता है कि...
क्या managers चाहते हैं कि बाक़ी सब AI इस्तेमाल करें, बस वे ख़ुद नहीं?
जो चीज़ अब मुझे खलने लगी है वह AI को धकेलना ख़ुद नहीं है। कुछ tools सचमुच काम के हैं। मैं अब इन्हें रोज़ इस्तेमाल करता हूँ। खलने वाली बात यह है कि management “AI-first” बर्ताव की माँग करता है जबकि उसके इर्द-गिर्द की हर process को AI के इस्तेमाल के लिए ज़बरदस्त रूप से दुश्मन बनाए रखता है। लोगों से कहा जाता है कि coding, planning, research, drafting, debugging, knowledge retrieval, project coordination के लिए AI इस्तेमाल करें.. पर फिर कंपनी का आधा operational ज्ञान अब भी बिना documented बातचीत के
क्या Meta के engineer को कंपनी से कोई लगाव नहीं, सिर्फ़ comp से मतलब है?
Meta ने industry के सबसे बढ़िया engineers को अब तक के सबसे मोटे comp packages से ख़रीदा, और ठीक वही पाया जिसके पैसे चुकाए: अच्छी तनख़्वाह पाने वाले भाड़े के सैनिकों की फ़ौज, जिन्हें इस जगह से कोई लगाव नहीं और जो parties में इसका नाम तक ज़ोर से नहीं लेते।
क्या Stack ranking सहकर्मियों को दुश्मन बना देती है?
Stack ranking हमेशा राजनीति में ही ख़त्म होती है क्योंकि यह बदल देती है कि किसी संगठन के अंदर competence का मतलब क्या है। एक बार जब employees को किसी टिकाऊ standard या उद्देश्य के मुक़ाबले के बजाय एक-दूसरे के सापेक्ष आँका जाने लगता है, तो तुम्हारा सबसे होशियार सहकर्मी एक ऐसी संपत्ति नहीं रह जाता जिससे तुम सीख सको और मिलकर काम कर सको, बल्कि competition बनने लगता है। उसकी कामयाबी तुम्हारी हैसियत गिरा सकती है। उसका दिखना तुम्हारी promotion की जगह छीन सकता है। उसकी expertise तुम्हारी अपनी सुरक्षा के
क्या Amazon का कर्मचारी ख़ुद के निचोड़े जाने को उपलब्धि की तरह नहीं पहनता?
Amazon tech की सबसे असरदार मशीन है, और इसके कर्मचारियों ने किसी तरह यह मान लिया है कि ईंधन होना और इंजन होना एक ही बात है। leadership principles आग लगी इमारत में धर्मग्रंथ की तरह सुनाए जाते हैं, और अठारह महीने की median tenure को deployment patch की तरह पहना जाता है।
क्या engineers को AI इस्तेमाल करने का incentive देना उल्टा नहीं पड़ सकता?
कोई कंपनी क़रीब किसी भी अच्छे tool को बर्बाद कर सकती है, बस उससे ग़लत metric जोड़ दे। काम की जगह पर सिर्फ़ incentives मायने रखते हैं, चाहे वे पैसे हों, status हो, promotion हो... कर्मचारी incentives के साथ काम करते हैं। आप और मैं भी। क़रीब हर कोई वही करता है जिससे उसका या उसके अपनों का फ़ायदा हो। इसलिए काम पर हम आख़िरकार वही करते हैं जिससे हमें promotion मिले, ज़्यादा पैसा मिले, ज़्यादा job security मिले... हम कंपनी के मालिक नहीं हैं, हम कर्मचारी हैं। हम अपना ख़याल रखते हैं। यह ठीक है।
क्या ज़्यादातर AI startups बस कुछ Agent.md files के ऊपर एक UI भर हैं?
अभी ज़्यादातर AI startups ऐसे लगते हैं जैसे किसी ने GPT को एक terminal से चिपका दिया हो, एक dark mode UI जोड़ दी हो, और बातें ऐसे करने लगा हो जैसे उसने कुछ इजाद कर दिया। आपको ऐसी बेतुकी pitches दिखेंगी जैसे “persistent autonomous cognitive agents with long-term reasoning” और फिर आप अंदर झाँकते हैं तो वह दरअसल इतना ही है: model को tool access दे दो, उसे browser चलाने दो, शायद memory summaries और retry logic जोड़ दो। यही “product” है। यह आप ख़ुद ही Claude को locally access देकर पा सकते हैं।
क्या AI ने अच्छे engineers को शोर मचाने वालों से अलग पहचानना बेहद मुश्किल नहीं कर दिया?
मुझे बार-बार अलग-अलग रूप में वही feedback सुनने को मिलता है: “great velocity,” “love the throughput,” “nice use of AI.” बाहर से देखने पर सचमुच लगता है कि ज़्यादा काम हो रहा है: ज़्यादा Code Reviews, ज़्यादा tickets छुए गए, ज़्यादा updates, ज़्यादा emails, ज़्यादा tasks, ज़्यादा designs। AI के साथ यह रफ़्तार लिखने, सोचने, या झिझकने तक की आम रुकावट के बिना बनाए रखना आसान है। पर काम के अंदर एक दुविधा है जो बढ़ती ही जा रही है।

सोचा

चर्चा सामग्री

Thoughts

Related discussions