सार्वजनिक6 वार्तालाप14 विचार142 अपवोट22 डाउनवोट्स0 शृंखला242 दृश्य
कोई कंपनी क़रीब किसी भी अच्छे tool को बर्बाद कर सकती है, बस उससे ग़लत metric जोड़ दे। काम की जगह पर सिर्फ़ incentives मायने रखते हैं, चाहे वे पैसे हों, status हो, promotion हो... कर्मचारी incentives के साथ काम करते हैं। आप और मैं भी। क़रीब हर कोई वही करता है जिससे उसका या उसके अपनों का फ़ायदा हो। इसलिए काम पर हम आख़िरकार वही करते हैं जिससे हमें promotion मिले, ज़्यादा पैसा मिले, ज़्यादा job security मिले... हम कंपनी के मालिक नहीं हैं, हम कर्मचारी हैं। हम अपना ख़याल रखते हैं। यह ठीक है।
Support वाला तुम्हारा उदाहरण बिल्कुल वही है जो हमारे यहाँ engineering side पर हुआ। असली metric का सवाल सही है, तो ठीक करने वाले सवाल ये हैं। क्या review time बढ़ा। क्या rollback rate बढ़ा। क्या वही bug दूसरी बार आ रहा है। हमारे case में AI-assisted PRs का
Support वाला तुम्हारा उदाहरण बिल्कुल वही है जो हमारे यहाँ engineering side पर हुआ। असली metric का सवाल सही है, तो ठीक करने वाले सवाल ये हैं।
क्या review time बढ़ा।
क्या rollback rate बढ़ा।
क्या वही bug दूसरी बार आ रहा है।
हमारे case में AI-assisted PRs का volume दोगुना हुआ और तीनों number बिगड़े। dashboard पर adoption हरा था, on-call पर हम जल रहे थे। surface area नापना आसान है, असर नापना नहीं, इसलिए वही नापा जाता है जो आसान है।
चर्चा सामग्री
कोई कंपनी क़रीब किसी भी अच्छे tool को बर्बाद कर सकती है, बस उससे ग़लत metric जोड़ दे। काम की जगह पर सिर्फ़ incentives मायने रखते हैं, चाहे वे पैसे हों, status हो, promotion हो... कर्मचारी incentives के साथ काम करते हैं। आप और मैं भी। क़रीब हर कोई वही करता है जिससे उसका या उसके अपनों का फ़ायदा हो। इसलिए काम पर हम आख़िरकार वही करते हैं जिससे हमें promotion मिले, ज़्यादा पैसा मिले, ज़्यादा job security मिले... हम कंपनी के मालिक नहीं हैं, हम कर्मचारी हैं। हम अपना ख़याल रखते हैं। यह ठीक है।
The Great Hanoi Rat Massacre 1902 में Hanoi, Vietnam (तब इसे French Indochina कहा जाता था) में हुआ, जब फ़्रांसीसी औपनिवेशिक शासन के तहत औपनिवेशिक सरकार ने एक bounty program बनाया जो हर मारे गए चूहे पर 1¢ का इनाम देता था।[6] इनाम लेने के लिए लोगों को चूहे की कटी हुई पूँछ देनी पड़ती थी। पर औपनिवेशिक अफ़सरों ने Hanoi में बिना पूँछ वाले चूहे दिखने पर ग़ौर करना शुरू किया। वियतनामी चूहा-पकड़ने वाले चूहे पकड़ते, उनकी पूँछ काटते, फिर उन्हें वापस नालियों में छोड़ देते ताकि वे और चूहे पैदा करें। और मिसालें यहाँ: https://en.wikipedia.org/wiki/Perverse_incentive#Examples_of_perverse_incentives.
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 करने लगते हैं। और यह ठीक है, मैं भी यही करता हूँ।
देख भाई, बड़ी कंपनी में 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 पर भी हूबहू लागू होती है।
जैसे ही 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 तो पकड़ा, पर वो किसके सिर सबसे भारी पड़ता है, वो छूट गया।
मुझे बार-बार अलग-अलग रूप में वही feedback सुनने को मिलता है: “great velocity,” “love the throughput,” “nice use of AI.” बाहर से देखने पर सचमुच लगता है कि ज़्यादा काम हो रहा है: ज़्यादा Code Reviews, ज़्यादा tickets छुए गए, ज़्यादा updates, ज़्यादा emails, ज़्यादा tasks, ज़्यादा designs। AI के साथ यह रफ़्तार लिखने, सोचने, या झिझकने तक की आम रुकावट के बिना बनाए रखना आसान है। पर काम के अंदर एक दुविधा है जो बढ़ती ही जा रही है।
कोई माँ-बाप अपने बच्चों को मानविकी पढ़ने को नहीं उकसाते। डिफ़ॉल्ट रूप से सुझाए जाने वाले विकल्प STEM से जुड़े होते हैं। Engineering (Computer Science), Finance, Medicine... AI के दौर में मानविकी के ख़िलाफ़ दलील किसी मानविकी की डिग्री को 4 साल देना और भी कम भरोसेमंद बना देती है। Language models ठीक-ठाक लिख सकते हैं, झटपट सारांश बना सकते हैं, और माँगने पर शोध-जैसा दिखने वाला text गढ़ सकते हैं।
Hard skills नापने लायक़, ठोस और सिखाने लायक़ क़ाबिलियतें या तकनीकी ज्ञान हैं जो शिक्षा, training या तजुर्बे से हासिल होते हैं, और अक्सर किसी ख़ास नौकरी या industry से सीधे जुड़े होते हैं। उदाहरण में data analysis, programming, graphic design, accounting, नाचना, चित्रकारी… ये आमतौर पर किसी पेशे का मूल होते हैं, ख़ासकर उसका वह हिस्सा जिसमें दूसरे लोगों से बातचीत शामिल नहीं। दूसरी ओर, soft skills को ज़्यादातर "निजी गुण, interpersonal..." के रूप में परिभाषित किया जाता है।
students, teenagers और अपने से छोटे co-workers के साथ बातचीत करते हुए मुझे एहसास होता है कि बहुत से लोग मानते हैं कि उनकी personality के गुण यह तय करने में सबसे बड़ा कारक हैं कि उन्हें क्या करना चाहिए या अपने career को कैसे सँभालना चाहिए। हालाँकि कम उम्र के लोग ये सवाल ज़्यादा खुलकर पूछते हैं, बड़े लोग भी कुछ इसी तर्ज़ पर सोचते दिखते हैं। मुझे ख़ुद यह उससे कहीं ज़्यादा बेमानी लगता है जितना ज़्यादातर लोग सोचते हैं। मेरे काम के अलावा, जहाँ मैं देखता हूँ कि कामयाब लोग वही काम बेहद...
जो चीज़ अब मुझे खलने लगी है वह AI को धकेलना ख़ुद नहीं है। कुछ tools सचमुच काम के हैं। मैं अब इन्हें रोज़ इस्तेमाल करता हूँ। खलने वाली बात यह है कि management “AI-first” बर्ताव की माँग करता है जबकि उसके इर्द-गिर्द की हर process को AI के इस्तेमाल के लिए ज़बरदस्त रूप से दुश्मन बनाए रखता है। लोगों से कहा जाता है कि coding, planning, research, drafting, debugging, knowledge retrieval, project coordination के लिए AI इस्तेमाल करें.. पर फिर कंपनी का आधा operational ज्ञान अब भी बिना documented बातचीत के
एक नई executive कल्पना चल रही है, कि AI workers की जगह ले सकता है। हालाँकि यह कुछ की जगह तो ज़रूर ले रहा है, executives एक ऐसी कल्पना पाले हैं जिससे उन्हें लगता है कि वे अपने report का काम ख़ुद, AI के साथ कर सकते हैं। कि वे code कर सकते हैं! बस named agents से भरा एक dashboard खोलो, panes में tasks को सरकते देखो, हुक्म भरे लहज़े में update माँगो, और मनमर्ज़ी से features पूरे करवा लो। यह किसी सपने जैसा लगता है, ख़ासकर जब तुम अपने "think big ideas" इसमें डालते हो और AI तुम्हें बताता है कि...
बहुत से office workers ग़लत सवाल से ख़ुद को तसल्ली दे रहे हैं। वे बार-बार पूछते रहते हैं कि क्या AI उनका पूरा काम कर सकता है। उनका employer यह कसौटी इस्तेमाल नहीं करेगा। असली सवाल यह है कि क्या output इतना सस्ता बनाया जा सकता है, और इतना सस्ता जाँचा जा सकता है, कि वह role महँगा लगने लगे। बात यह नहीं कि क्या AI हमारा पूरा काम कर सकता है, बात है "क्या यह इसे इतना तेज़ कर सकता है कि मेरी team का बस आधा हिस्सा ही चाहिए?"। क्योंकि इसका जवाब, अफ़सोस, हाँ है।
मुझे हमेशा लगता था कि AI कंपनियाँ दरअसल AI के ऊपर wrappers लगाती हैं ताकि पकड़ सकें कि हम उसकी सोच को test कर रहे हैं। मसलन, पहले जब हम उससे किसी शब्द में vowels/consonants गिनवाते थे और वह ग़लती कर देता था। मुझे लगता है अब एक script है जो task सही पहचाने जाने पर बस call हो जाती है। मुझे यह भी लगता है कि इसे इन्हीं memes पर train किया जाता है। आज मुझे एक नया test मिला, जो दिखाता है कि AI कितनी आसानी से तुम्हें AI psychosis दे देता है और कितनी आसानी से तुम सचमुच यक़ीन कर बैठते हो कि तुमने जो भी क