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