कोई कंपनी क़रीब किसी भी अच्छे tool को बर्बाद कर सकती है, बस उससे ग़लत metric जोड़ दे। काम की जगह पर सिर्फ़ incentives मायने रखते हैं, चाहे वे पैसे हों, status हो, promotion हो... कर्मचारी incentives के साथ काम करते हैं। आप और मैं भी। क़रीब हर कोई वही करता है जिससे उसका या उसके अपनों का फ़ायदा हो। इसलिए काम पर हम आख़िरकार वही करते हैं जिससे हमें promotion मिले, ज़्यादा पैसा मिले, ज़्यादा job security मिले... हम कंपनी के मालिक नहीं हैं, हम कर्मचारी हैं। हम अपना ख़याल रखते हैं। यह ठीक है।
हमारे यहाँ leadership ने "हर decision के साथ एक agent plan attach करो" वाला norm चुपके से बना दिया। अब आधे decision notes में एक agent-generated plan चिपका रहता है जिसे किसी ने पढ़ा भी नहीं, क्योंकि वो आधुनिक दिखता है। तुमने इसे tools के नौकरशाही बनने वाल
हमारे यहाँ leadership ने "हर decision के साथ एक agent plan attach करो" वाला norm चुपके से बना दिया। अब आधे decision notes में एक agent-generated plan चिपका रहता है जिसे किसी ने पढ़ा भी नहीं, क्योंकि वो आधुनिक दिखता है।
तुमने इसे tools के नौकरशाही बनने वाली बात में रखा, और यही सबसे सटीक हिस्सा है। काम वही है, बस उस पर अब एक AI ritual चढ़ गया है जो किसी को कोई फ़ैसला लेने में मदद नहीं करता।
कोई कंपनी क़रीब किसी भी अच्छे tool को बर्बाद कर सकती है, बस उससे ग़लत metric जोड़ दे। काम की जगह पर सिर्फ़ incentives मायने रखते हैं, चाहे वे पैसे हों, status हो, promotion हो... कर्मचारी incentives के साथ काम करते हैं। आप और मैं भी। क़रीब हर कोई वही करता है जिससे उसका या उसके अपनों का फ़ायदा हो। इसलिए काम पर हम आख़िरकार वही करते हैं जिससे हमें promotion मिले, ज़्यादा पैसा मिले, ज़्यादा job security मिले... हम कंपनी के मालिक नहीं हैं, हम कर्मचारी हैं। हम अपना ख़याल रखते हैं। यह ठीक है।
जब management token consumption, prompt volume, agent count, या रोज़ाना AI usage का जश्न मनाने लगता है, तो लोग काम के नतीजों के बजाय machine activity के लिए optimize करने लगते हैं। अगर आपकी नौकरी इसलिए ख़तरे में है क्योंकि आप पर AI इस्तेमाल न करने का ठप्पा लगा है, तो... आप AI इस्तेमाल करते हैं। ख़ूब, ख़ासकर जब engineers को इसे और ज़्यादा इस्तेमाल करने का इनाम मिलता हो। इसका मतलब यह नहीं कि वे बेवक़ूफ़ हैं। इसका मतलब है कि वे कर्मचारी हैं। कर्मचारी उसी के पीछे भागते हैं जो leadership को दिखता है, ख़ासकर जब दिखने वाली चीज़ इनाम लेकर आती हो। अभी AI activity ढेरों इनाम लेकर आती है।
यह बस नए लिबास में वही KPI corruption है। संगठन सिद्धांत में जानते हैं कि एक बार कोई metric target बन जाए तो वह एक साफ़ माप नहीं रह जाता, फिर जिस पल वह metric technical और भविष्य की तरफ़ झाँकती हुई लगती है, उसी पल वे यह नियम भूल जाते हैं। AI इस भूलने की बीमारी को और बढ़ा देता है क्योंकि machine activity को graph पर दिखाना आसान है और उसकी डींग मारना आसान। AI adoption उन्हीं में से एक है।
बेहतर scoreboard ज़्यादा मुश्किल और कम चापलूस होता है। एक support team की कल्पना कीजिए जो गर्व से अपना AI-assisted response volume दोगुना कर देती है। यह बढ़िया लगता है, जब तक आप यह न देख लें कि escalations भी बढ़ गए क्योंकि first-pass responses उथले थे और supervisors उन्हें ठीक करने में ज़्यादा वक़्त लगा रहे थे। बेहतर metric यह नहीं है कि "हमने कितने AI जवाब बनाए?" यह है, "क्या first-response time बेहतर हुआ बिना escalation, rework, या customer की झुँझलाहट के बढ़े?" यही बात engineering पर भी लागू होती है। ज़्यादा tokens फूँकना बेमानी है अगर review time, defect rate, और rollback risk सब बदतर हो जाएँ। वैसे भी engineering team का असल में कितना असर पड़ा?
एक एतराज़ है जिसे गंभीरता से लेना चाहिए। rollout की शुरुआत में, usage metrics मायने रख सकते हैं। अगर कोई tool को छू ही नहीं रहा, तो adoption की कोई कहानी ही नहीं है। ठीक। पर अस्थायी experimentation metrics की एक बुरी आदत है — स्थायी vanity metrics बन जाने की। एक बार status और मूल्यांकन दिखने वाली AI activity से जुड़ जाएँ, तो संगठन scoreboard भरने के लिए activity बनाने लगता है।
इसी तरह काम के tools नौकरशाही बन जाते हैं। कर्मचारी तब भी prompt करने लगते हैं जब उन्हें बस ख़ुद फ़ैसला कर लेना चाहिए था। नेता agent plans माँगने लगते हैं क्योंकि agent plans आधुनिक लगते हैं। टीमें असल cost, quality, और delivery के बजाय नापी जा सकने वाली AI surface area के लिए optimize करती हैं। संस्था ने बस पैसा बर्बाद करने का एक नया तरीक़ा ढूँढ लिया है, और साथ में अपनी पीठ भी थपथपा लेती है।
यह कभी एक सुलझी हुई समस्या थी। management पहले engineers को ज़्यादा code लिखने का इनाम देता था। तो codebases नाटकीय ढंग से बढ़ती जातीं और भुरभुरी और फूली हुई बन जातीं। इस सरल metric ने पहले ही दिखा दिया था कि आप performance के लिए सरल metrics नहीं रख सकते और अच्छे नतीजों की उम्मीद नहीं कर सकते। जैसे ही आप उन्हें रखते हैं, लोग उन्हीं के लिए optimize करने लगते हैं। और यह ठीक है, मैं भी यही करता हूँ।
देख भाई, बड़ी कंपनी में engineers को AI "adopt" करने पर bonus मिलता है। मेरी कंपनी में adoption का इनाम यह था कि server bill बच जाए। एक salary list जो मैं चुका नहीं सकता था, उसने मुझे token count से ज़्यादा अच्छा सिखा दिया कि कौन-सी activity असली है।
Support वाला तुम्हारा उदाहरण बिल्कुल वही है जो हमारे यहाँ engineering side पर हुआ। असली metric का सवाल सही है, तो ठीक करने वाले सवाल ये हैं।
क्या review time बढ़ा।
क्या rollback rate बढ़ा।
क्या वही bug दूसरी बार आ रहा है।
हमारे case में AI-assisted PRs का volume दोगुना हुआ और तीनों number बिगड़े। dashboard पर adoption हरा था, on-call पर हम जल रहे थे। surface area नापना आसान है, असर नापना नहीं, इसलिए वही नापा जाता है जो आसान है।
Thesis से सहमत हूँ, पर एक जगह तुमने ख़ुद को छूट दे दी। "और यह ठीक है, मैं भी यही करता हूँ" वाला अंत बार-बार आता है, मानो वो किसी आलोचना को बेअसर कर देता हो।
नहीं करता। यह मानना कि "सब incentive के पीछे भागते हैं" एक observation है, justification नहीं। तुम system की आलोचना करते हो और साथ-साथ ख़ुद को उससे बरी भी कर लेते हो, यही दोहरी चाल argument को थोड़ा कमज़ोर करती है।
Great Hanoi Rat वाली मिसाल perfect है, पर इसका modern नाम भी रख दो, Goodhart's law, "जब कोई measure target बन जाए, वो अच्छा measure रहना बंद कर देता है"। यह संगठन theory में decades पुराना है।
जो AI के साथ नया है वो बस यह है कि machine activity graph पर बहुत साफ़ दिखती है, इसलिए leadership को उसे target बनाने का लालच और ज़्यादा है। पूँछ काटकर चूहे वापस छोड़ने वाली बात token count पर भी हूबहू लागू होती है।
पूँछ कटे चूहे वापस नाली में, बस अब उनका नाम "weekly active agents" है 💀
जैसे ही management ने token usage को dashboard पर रखा, वही चीज़ हुई जो हर metric के साथ होती है, लोग उसे game करने लगे। मेरी टीम में एक बंदा अब हर trivial fix के लिए agent चलाता है, सिर्फ़ इसलिए कि weekly usage report में वो green दिखे।
नतीजा यह कि review में मेरा वक़्त बढ़ गया, क्योंकि वो agent diffs अक्सर ज़रूरत से बड़े और शक़ी होते हैं। usage ऊपर गया, असली throughput नीचे। Goodhart की पुरानी कहानी, बस नया lipstick।
हमारे यहाँ leadership ने "हर decision के साथ एक agent plan attach करो" वाला norm चुपके से बना दिया। अब आधे decision notes में एक agent-generated plan चिपका रहता है जिसे किसी ने पढ़ा भी नहीं, क्योंकि वो आधुनिक दिखता है।
तुमने इसे tools के नौकरशाही बनने वाली बात में रखा, और यही सबसे सटीक हिस्सा है। काम वही है, बस उस पर अब एक AI ritual चढ़ गया है जो किसी को कोई फ़ैसला लेने में मदद नहीं करता।
एक चीज़ जोड़ूँगी, यह सिर्फ़ metric corruption नहीं, एक नई तरह की performance है। अब लोग सबके सामने prompt करते हैं, ताकि दिखे कि वो "AI-forward" हैं, भले फ़ैसला उन्हें ख़ुद आता हो।
और जैसे हर visible performance में होता है, इसका बोझ बराबर नहीं बँटता। जो चुपचाप काम कर देता है वो अब "AI नहीं अपना रहा" का ठप्पा झेलता है, चाहे उसका output बेहतर हो। तुमने incentive तो पकड़ा, पर वो किसके सिर सबसे भारी पड़ता है, वो छूट गया।