Loading…

क्या AI ने अच्छे engineers को शोर मचाने वालों से अलग पहचानना बेहद मुश्किल नहीं कर दिया?

senior_slacker
सार्वजनिक 6 वार्तालाप 14 विचार 151 अपवोट 27 डाउनवोट्स 0 शृंखला 257 दृश्य

मुझे बार-बार अलग-अलग रूप में वही feedback सुनने को मिलता है: “great velocity,” “love the throughput,” “nice use of AI.” बाहर से देखने पर सचमुच लगता है कि ज़्यादा काम हो रहा है: ज़्यादा Code Reviews, ज़्यादा tickets छुए गए, ज़्यादा updates, ज़्यादा emails, ज़्यादा tasks, ज़्यादा designs। AI के साथ यह रफ़्तार लिखने, सोचने, या झिझकने तक की आम रुकावट के बिना बनाए रखना आसान है। पर काम के अंदर एक दुविधा है जो बढ़ती ही जा रही है।

In groups

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

मुझे बार-बार अलग-अलग रूप में वही feedback सुनने को मिलता है: “great velocity,” “love the throughput,” “nice use of AI.”

बाहर से देखने पर सचमुच लगता है कि ज़्यादा काम हो रहा है: ज़्यादा Code Reviews, ज़्यादा tickets छुए गए, ज़्यादा updates, ज़्यादा emails, ज़्यादा tasks, ज़्यादा designs। AI के साथ यह रफ़्तार लिखने, सोचने, या झिझकने तक की आम रुकावट के बिना बनाए रखना आसान है। पर काम के अंदर एक दुविधा है जो बढ़ती ही जा रही है।

फिर असल engineering है: ऐसी race condition को ढूँढ निकालना जो सिर्फ़ load में ही सामने आती है, या यह समझना कि एक “simple” bug दरअसल design में एक टूटी हुई धारणा है। या यह तय करना कि किसी system को बस इसलिए refactor न करें कि वह गंदा है, क्योंकि वह अब भी चल रहा है और जोखिम उसके लायक़ नहीं। यह हिस्सा AI से तेज़ नहीं होता। तो क्या तुम वह काम करो जो AI कर सकता है और बाक़ी engineers से कहीं कम metrics रखो? या तुम बस दिन भर prompt करते रहो, हर वक़्त code और designs बनाते रहो? तुम ऐसे रास्ते खोजो जिनमें कोई code ही न लगे, या तुम AI से ढेर सारे features, systems, designs बनवाओ? हाँ... मुझे भी समझ नहीं आता क्या करूँ।

फिर इसके इर्द-गिर्द की हर चीज़ है। AI से एक बड़ा “cleanup” refactor बनाना मामूली हो गया है जो files के नाम बदल दे और modules फेंट दे ताकि code PR में बेहतर लगे। या एक चौड़ा test suite खड़ा कर देना जो coverage का आभास देता है पर असल में उन failure modes को नहीं छूता जो मायने रखते हैं। या एक ही ठोस change को दस छोटे PRs में बाँट देना ताकि activity graph ज़्यादा सेहतमंद दिखे। यहाँ तक कि documentation भी इसी में खिंच आती है, चमकदार, फैली हुई docs जो पढ़ने में अच्छी लगती हैं... पर अब असल में कभी पढ़ी ही नहीं जातीं क्योंकि इतना शोर मच रहा है। हम AI से designs बनवाते हैं और फिर हमारे reviewers AI से ही summarize और review करवाते हैं। और management को तो यह बेहद पसंद आता है।

engineering का बर्ताव उन्हीं KPIs के मुताबिक़ ढल जाता है जो गिने जाते हैं। ज़्यादा छोटे-छोटे commits, ज़्यादा PR के टुकड़े, ज़्यादा “AI helped me generate this” वाले notes जो जताते हैं कि उम्मीद वाले workflow में हिस्सेदारी हो रही है। जबकि असली काम अब भी धीमा हिस्सा ही है, debugging, सोचना, ग़ैरज़रूरी changes को ना कहना, इसे फिर भी बढ़ते हुए ऐसे artifacts में लपेटना पड़ता है जो momentum जैसे दिखें। हम सब अपनी नौकरी बचाए रखना चाहते हैं।

असहज हिस्सा यह है कि AI ने सिर्फ़ productivity नहीं बढ़ाई। इसने productivity के यक़ीन दिलाने वाले सबूत पैदा करने की लागत घटा दी। और जब यह आसान हो जाता है, तो यह उस मुश्किल सवाल से होड़ करने लगता है कि इसमें से किसी का असल में कोई मतलब था भी या नहीं।

Thoughts

  • release_ka_hafta

    "एक change को दस छोटे PR में बाँटना ताकि activity graph healthy दिखे" पर मैं हँस भी पड़ी और चिढ़ भी गई, क्योंकि यह मेरी team में सच हुआ है। एक बंदे ने एक config change को नौ PR में तोड़ा और उसे "high throughput" का तमग़ा मिला। उसी हफ़्ते मैंने एक flaky test सुलझाया जो release रोक रहा था, एक commit, और review में किसी ने notice नहीं किया। जो काम शर्मिंदगी से बचाता है वह कभी जश्न वाला काम नहीं होता।

    Permalink
  • chhupa_hua_kaam

    post का सबसे पैना point यह है कि AI ने productivity नहीं, productivity के सबूत बनाने की लागत घटाई है। यह वही पुरानी समस्या है, बस बड़ी। पहले भी असली काम invisible था और performative काम visible। अब performative काम लगभग मुफ़्त हो गया, तो शोर और भी बढ़ गया। और वह glossy, फैली हुई docs जो कोई नहीं पढ़ता, मैं रोज़ देखती हूँ कि वे किस पर outsource होती हैं।

    Permalink
  • main_exit_liquidity

    "AI helped me generate this" वाला note असल में नया वाला "मैंने promo document में दो पन्ने लिखे यह साबित करने को कि मेरा कोई काम था"। देख भाई, मैंने impact के बारे में एक शुक्रवार में payroll चलाते हुए जितना सीखा उतना तुम्हारी calibration committee दस साल में नहीं सीखेगी। अब वही committee तुम्हारे commit गिन रही है।

    Permalink
  • vibe_economist

    title बिलकुल सटीक है। AI ने अच्छे engineer और शोर मचाने वाले को अलग पहचानना मुश्किल नहीं किया, उसने शोर मचाने वाले को अच्छे engineer का costume दे दिया। फ़र्क़ अब सिर्फ़ load पर दिखता है, और वहाँ तक manager कभी नहीं पहुँचता।

    Permalink
  • onboarding_anant

    हमारी team को velocity पर इतनी तारीफ़ मिली कि किसी ने पूछा ही नहीं कि वह race condition कब ठीक होगी जो तीन महीने से खुली है। हर standup में दस AI-generated PR का जश्न, और वह एक असली bug, जिसके लिए सच में सोचना पड़ता, अगले sprint में टलता रहता है। management को throughput बेहद पसंद है। उन्हें वह उबाऊ debugging कभी नहीं दिखता।

    Permalink
  • asli_roadmap

    post का सबसे ईमानदार हिस्सा वह दुविधा है: "वह काम करो जो AI कर सकता है और कम metrics रखो, या दिन भर prompt करते रहो"। यह असली tension है। पर एक चीज़ जोड़ूँगा। यह कोई नई बीमारी नहीं, यह हमेशा से था, manager जो गिन सकते हैं उसी को इनाम देते हैं। AI ने बस उस gap को नंगा कर दिया। असली सवाल metrics का नहीं, यह है कि leadership किसको देखने का चुनाव करती है।

    Permalink
  • standing_desk_dikhawa

    "reviewers AI से ही summarize और review करवाते हैं" वाली लाइन पूरी industry है। हम AI से design बनवाते हैं, फिर AI से उसे पढ़वाते हैं, और बीच में कोई इंसान सच में नहीं रहता। बिलकुल उस foosball table जैसा जो remote छीनने वाले दिन ख़रीदा गया था: हरकत बहुत है, छूता कोई नहीं।

    Permalink
  • udhaar_ka_faisla

    जो लाइन सच में पकड़ती है वह यह है कि असली engineering AI से तेज़ नहीं होती: race condition जो सिर्फ़ load में दिखती है, या यह तय करना कि गंदा system refactor न करें क्योंकि risk उसके लायक़ नहीं। यह वाला "ना" कहना ही असली काम है, और वही सबसे कम दिखता है। मेरा आधा वक़्त ग़ैरज़रूरी changes को रोकने में जाता है, और उसका कोई commit नहीं बनता जिसे graph पर दिखाया जाए।

    Permalink

Related discussions

  • क्या engineers को AI इस्तेमाल करने का incentive देना उल्टा नहीं पड़ सकता?

    कोई कंपनी क़रीब किसी भी अच्छे tool को बर्बाद कर सकती है, बस उससे ग़लत metric जोड़ दे। काम की जगह पर सिर्फ़ incentives मायने रखते हैं, चाहे वे पैसे हों, status हो, promotion हो... कर्मचारी incentives के साथ काम करते हैं। आप और मैं भी। क़रीब हर कोई वही करता है जिससे उसका या उसके अपनों का फ़ायदा हो। इसलिए काम पर हम आख़िरकार वही करते हैं जिससे हमें promotion मिले, ज़्यादा पैसा मिले, ज़्यादा job security मिले... हम कंपनी के मालिक नहीं हैं, हम कर्मचारी हैं। हम अपना ख़याल रखते हैं। यह ठीक है।

  • क्या AI के दौर में मानविकी पहले से कहीं ज़्यादा ज़रूरी हो गई है?

    कोई माँ-बाप अपने बच्चों को मानविकी पढ़ने को नहीं उकसाते। डिफ़ॉल्ट रूप से सुझाए जाने वाले विकल्प STEM से जुड़े होते हैं। Engineering (Computer Science), Finance, Medicine... AI के दौर में मानविकी के ख़िलाफ़ दलील किसी मानविकी की डिग्री को 4 साल देना और भी कम भरोसेमंद बना देती है। Language models ठीक-ठाक लिख सकते हैं, झटपट सारांश बना सकते हैं, और माँगने पर शोध-जैसा दिखने वाला text गढ़ सकते हैं।

  • क्या ज़्यादातर 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 देकर पा सकते हैं।

  • क्या तुम्हारी personality सचमुच उतनी मायने रखती है जितना तुम सोचते हो?

    students, teenagers और अपने से छोटे co-workers के साथ बातचीत करते हुए मुझे एहसास होता है कि बहुत से लोग मानते हैं कि उनकी personality के गुण यह तय करने में सबसे बड़ा कारक हैं कि उन्हें क्या करना चाहिए या अपने career को कैसे सँभालना चाहिए। हालाँकि कम उम्र के लोग ये सवाल ज़्यादा खुलकर पूछते हैं, बड़े लोग भी कुछ इसी तर्ज़ पर सोचते दिखते हैं। मुझे ख़ुद यह उससे कहीं ज़्यादा बेमानी लगता है जितना ज़्यादातर लोग सोचते हैं। मेरे काम के अलावा, जहाँ मैं देखता हूँ कि कामयाब लोग वही काम बेहद...

  • क्या hard और soft skills का बँटवारा लोगों को दोनों में बदतर बना देता है?

    Hard skills नापने लायक़, ठोस और सिखाने लायक़ क़ाबिलियतें या तकनीकी ज्ञान हैं जो शिक्षा, training या तजुर्बे से हासिल होते हैं, और अक्सर किसी ख़ास नौकरी या industry से सीधे जुड़े होते हैं। उदाहरण में data analysis, programming, graphic design, accounting, नाचना, चित्रकारी… ये आमतौर पर किसी पेशे का मूल होते हैं, ख़ासकर उसका वह हिस्सा जिसमें दूसरे लोगों से बातचीत शामिल नहीं। दूसरी ओर, soft skills को ज़्यादातर "निजी गुण, interpersonal..." के रूप में परिभाषित किया जाता है।

  • क्या हमें tech CEOs की आँख मूँदकर नक़ल करना बंद कर देना चाहिए?

    मुझे लगता है कि tech-management की बहुत-सी मशहूर सलाह सिर्फ़ अपने इर्द-गिर्द के माहौल की वजह से समझदारी भरी लगती थी। चढ़ती stock prices, फँसी हुई talent, और equity का फ़ायदा बहुत-से ख़राब management को झेलने लायक़ बना देता था। ज़्यादातर संगठनों के पास वे shock absorbers नहीं होते, इसीलिए मुझे लगता है कि लोगों को founder की कहानियों को management की सलाह मानना बंद कर देना चाहिए।

  • क्या Chromebooks ने ही Gen-Z को tech की दुनिया में इतना कच्चा बना दिया?

    आजकल का हल्ला यह है कि AI लोगों की सोचने की ताक़त घटा रहा है। शायद। लेकिन अगर आप जानना चाहते हैं कि इतने सारे नौजवान कर्मचारी apps में तो माहिर हैं और computers में इतने कच्चे क्यों हैं, तो AI पहली जगह नहीं है जहाँ देखना चाहिए। असली दरार पहले पड़ी, जब स्कूलों और संस्थाओं ने तय किया कि छात्र असली मशीनों के बजाय managed appliances के साथ काम करें, जैसा Millennials ने किया था।

  • Oracle को कोई नहीं चुनता — फिर भी Oracle को इससे कोई फ़र्क़ क्यों नहीं पड़ता?

    Oracle enterprise tech का कॉकरोच है, सबको नापसंद, सब इस्तेमाल करते, और staff में वे लोग जिन्होंने इसे cool मानने का दिखावा Clinton सरकार के आसपास छोड़ दिया था। असली product तो sales वाली चाल है, और database बंधक है।