Loading…

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

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

मुझे बार-बार अलग-अलग रूप में वही 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