मई 2026 में, Tom's Hardware ने रिपोर्ट किया कि "Amazon के कर्मचारी आंतरिक कोटा पूरा करने के लिए AI का अनावश्यक उपयोग कर रहे हैं।" कंपनी ने एक आंतरिक लक्ष्य रखा था कि "80% से अधिक डेवलपर्स को हर सप्ताह AI टूल्स का उपयोग करना चाहिए," और टोकन खपत को एक आंतरिक लीडरबोर्ड पर सामने रखा गया। कर्मचारियों ने टोकन पंप करके प्रतिक्रिया दी: "कॉपी-पेस्ट स्तर के कार्य भी जबरन AI के माध्यम से चलाना," "एक सवाल को कई में बाँट देना," "केवल टोकन खर्च करने के लिए Claude से कविता लिखवाना।" Meta और Microsoft पर भी ऐसे ही व्यवहार दर्ज किए गए।

सिलिकॉन वैली ने इस प्रवृत्ति को नाम दिया: "Tokenmaxxing।" एक नया कार्यस्थल मानक जहाँ टोकन खपत को अधिकतम करना पुरस्कृत किया जाता है। लगभग हर Fortune 500 कंपनी AI उपयोग को ट्रैक कर रही है, लेकिन बहुत कम ROI मापती हैं (ModelOp के CTO के अनुसार)। मेट्रिक "उपयोग की मात्रा = कार्य की मात्रा" संगठनात्मक निर्णयों को गलत दिशा में मोड़ने लगी है।

मेरा दृष्टिकोण पहले स्पष्ट कर दूँ: "टोकन खपत = कार्य उत्पादन" 1990 के दशक में डेवलपर्स को KLOC (कोड की लाइनें) से मापने का 2020 के दशक का दोहराव है. मात्रा मापना आसान है, लेकिन मात्रा और मूल्य अलग चीज़ें हैं. 22,000 डेवलपर्स और 4,000 टीमों पर किया गया अध्ययन दर्शाता है कि AI उपयोग ने कार्य पूर्णता +34% बढ़ाई, लेकिन बग्स +54% बढ़े और PR समीक्षा समय 5 गुना हो गया. यह लेख कवर करता है कि यह बुरा मेट्रिक क्यों फैला, इसमें क्या गलत है, क्या विकल्प मौजूद हैं (Salesforce का AWU, DORA, AWS के परिणाम मेट्रिक्स), और व्यक्ति व संगठन आज से कौन से पाँच व्यावहारिक कदम उठा सकते हैं — सब ज़मीनी डेटा और प्राथमिक स्रोतों द्वारा समर्थित।

TOKENMAXXING · 2026

केवल "कितना" मापिए और ज़मीन टूट जाती है

— मात्रा +34%, लेकिन गुणवत्ता टूटती है: बग्स +54% / समीक्षा समय 5×

मात्रा (पूर्ण किए गए कार्य)
+34%
पूर्ण किए गए Epics +66%। AI उपयोग वास्तव में विकास को तेज़ करता है।
गुणवत्ता (प्रति डेव बग्स)
+54%
प्रति डेवलपर प्रोडक्शन बग्स आधे से अधिक बढ़े। "तेज़ लेकिन बग-भरा" अब वास्तविकता है।
समीक्षा समय
माध्य PR समीक्षा समय 5 गुना लंबा। मात्रा का बोझ समीक्षकों पर — मनुष्य AI आउटपुट दर को नहीं झेल सकते।

स्रोत: Faros AI "Tokenmaxxing" अध्ययन (22,000 डेव × 4,000 टीमें)
केवल मात्रा का पीछा कीजिए और ज़मीन टूट जाती है। 1990 के दशक में KLOC से हमने जो सबक सीखा था — अब एक नई इकाई के साथ दोहराया जा रहा है।

1. Amazon का "80% साप्ताहिक AI उपयोग" आदेश — और उसके बाद का टोकन पंपिंग

मई 2026 में, Tom's Hardware ने एक खोजी रिपोर्ट प्रकाशित की जिसने "Tokenmaxxing" को सुर्खियों में ला दिया। Amazon ने एक आंतरिक लक्ष्य रखा था: "80% से अधिक डेवलपर्स को हर सप्ताह AI टूल्स का उपयोग करना चाहिए।" टोकन खपत को एक आंतरिक लीडरबोर्ड पर देखा जा सकता था, और मैनेजर्स ने प्रदर्शन समीक्षाओं में इसका संदर्भ दिया।

कर्मचारियों ने क्या किया? "कॉपी-पेस्ट स्तर के कार्य को भी जबरन AI से चलाना।" "एक सवाल को कई में तोड़ देना।" "Claude से सिर्फ़ टोकन खर्च करवाने के लिए कविता लिखवाना।" किसी भी नाम से यह टोकन की निष्क्रिय खपत है। Tom's Hardware द्वारा उद्धृत Amazon के कर्मचारियों ने कहा कि कोटा का दबाव तीव्र था, और वे "उन कार्यों में AI को घुसा रहे थे जहाँ AI न उपयोग करना तेज़ होता।" यही पैटर्न Meta और Microsoft पर भी सामने आते हैं — यह केवल Amazon की कहानी नहीं है।

Trending Topics (EU तकनीकी प्रेस) ने इस बदलाव को इस तरह सारांशित किया: "एक तकनीकी मेट्रिक नई कार्य संस्कृति का धर्म बन रहा है।" "AI उपयोग का प्रदर्शन करना" स्वयं एक मूल्यांकन धुरी बन जाता है। यह 2026 में Fortune 500 कंपनियों में एक साथ हो रहा है।

2. क्यों फैला "टोकन खपत = कार्य उत्पादन"

तो बड़ी कंपनियाँ पहली बार में ऐसी कच्ची मेट्रिक क्यों अपना रही हैं? तीन कारण।

कारण ①: AI निवेश को न्यायोचित ठहराना आवश्यक है

Fortune 500 कंपनियों ने पिछले दो वर्षों में AI में अरबों डॉलर निवेश किए हैं। जब भी CFO या बोर्ड पूछता है "इस निवेश पर रिटर्न क्या है?", CTO को एक संख्या चाहिए। टोकन खपत वह संख्या है जिसे उत्पन्न करना सबसे आसान है। API गेटवे के लॉग, आंतरिक चैट इतिहास, कोडिंग-टूल उपयोग — सब अपने आप एकत्रित हो जाते हैं। "उपयोग की मात्रा" को "निर्मित मूल्य की मात्रा" के रूप में पढ़ना स्पष्टीकरण का सबसे कम प्रतिरोध वाला रास्ता बन गया।

कारण ②: AI विरोधियों को धुएँ से बाहर निकालना

हर संगठन में ऐसे कर्मचारी होते हैं जो AI के प्रति संशयी हैं: गोपनीयता की चिंता, गुणवत्ता की चिंता, या बस नए टूल्स सीखने की अनिच्छा। प्रबंधन AI उपयोग को अनिवार्य करना चाहता है, लेकिन केवल आदेश से लोग नहीं चलते। टोकन खपत को सामने लाना "उन लोगों की पहचान" करने का साधन बन जाता है जो AI का उपयोग नहीं कर रहे हैं। Amazon का 80% लक्ष्य ठीक इसी के लिए बना है।

कारण ③: एकल तुलनीय स्केलर की माँग

"गुणवत्ता," "परिणाम," या "कोड की स्वच्छता" जैसे गुणात्मक मापों की आसानी से तुलना नहीं की जा सकती। "व्यक्ति A ने इस माह 1M टोकन उपयोग किए, व्यक्ति B ने 500K" — एकल स्केलर मान ऐसा लगता है मानो A ने स्पष्ट रूप से अधिक किया। आसान तुलना आलसी निर्णयों को आमंत्रित करती है। यह संरचनात्मक रूप से 1990 के दशक के KLOC (कोड की एक हज़ार लाइनें) की विफलता के समान है।

3. मात्रा–गुणवत्ता विचलन पर ठोस डेटा

यदि "उपयोग की मात्रा = किया गया कार्य" सच होता, तो टोकन मेट्रिक ठीक होती। वास्तविकता क्या दिखाती है? Faros AI 2026 अध्ययन — 22,000 डेवलपर्स पर 4,000 टीमों में — ने ऐसी संख्याएँ प्रकाशित कीं जो इसे निर्णायक रूप से खारिज करती हैं।

Faros AI 2026 / N=22,000

AI उपयोग क्या बढ़ाता है — और क्या तोड़ता है

↑ बढ़ा
  • पूर्ण किए गए कार्य: +34%
  • पूर्ण किए गए Epics: +66%
  • जोड़ी गई कोड लाइनें: तेज़ी से ऊपर
  • PR संख्या: स्पष्ट रूप से ऊपर
↓ टूटा
  • बग्स की संख्या: +54%
  • PR समीक्षा समय:
  • पुनः कार्य दर: ऊपर
  • प्रोडक्शन घटनाएँ: ऊपर की ओर रुझान

"आउटपुट मात्रा बढ़ती है, लेकिन गुणवत्ता और रखरखाव झेलते हैं।"
यही ज़मीनी हक़ीक़त है। टोकन-खपत मेट्रिक्स तस्वीर के केवल एक आधे हिस्से को देखते हैं।

"AI विकास को तेज़ करता है" स्वयं गलत नहीं है। कार्य +34%, Epics +66% — ये वास्तविक मूल्य दर्शाने वाली वास्तविक संख्याएँ हैं। समस्या यह है कि वही डेटा सेट लागत के बारे में क्या दिखाता है। बग्स +54%, समीक्षा समय 5 गुना — मानव समीक्षक AI-जनित कोड के साथ नहीं चल सकते, और दोष आगे रिस जाते हैं। कुछ शोधकर्ता चेताते हैं कि अल्पकालिक उत्पादकता लाभ दीर्घकालिक तकनीकी-ऋण वृद्धि से समाप्त हो सकते हैं

4. ज़मीनी स्तर पर हो रही तीन विकृतियाँ

सिद्धांत पर्याप्त। ज़मीनी स्तर पर वास्तव में क्या हो रहा है? तीन अवलोकनीय पैटर्न।

विकृति ①: टोकन पंपिंग

सबसे आम। AI को केवल "उपयोग करते हुए दिखने" के लिए कॉल करना। Amazon वाले व्यवहार: "कॉपी-पेस्ट कार्य को AI से चलाना," "एक प्रश्न को कई में तोड़ना," "AI से असंबंधित विषयों पर चैट करना।" शुद्ध लागत वृद्धि, कोई मूल्य नहीं। मेट्रिक अब कंपनी के AI ROI को सक्रिय रूप से बिगाड़ रही है — जिसे ट्रैक करना ही इसका उद्देश्य था।

विकृति ②: सार के बजाय गति

यदि "अधिक लिखने से बेहतर समीक्षा मिलती है" नियम है, तो लोग उसी अनुसार प्रतिक्रिया करते हैं। हल्की समीक्षा करना और तेज़ी से मर्ज करना, टेस्ट छोड़ना, रीफैक्टर टालना — अल्पकालिक आउटपुट बढ़ाने के लिए सब तर्कसंगत कार्य। Faros का "बग्स +54%" इसका पूर्वानुमेय परिणाम है।

विकृति ③: "AI-अनुकूल" कार्यों की ओर बहाव

एक अधिक सूक्ष्म विकृति। कार्य कठिन, महत्वपूर्ण समस्याओं (डिज़ाइन, तकनीकी-ऋण सफाई, गहन शोध) से दूर हटकर उन नियमित कार्यों की ओर (CRUD कोड, दस्तावेज़ निर्माण, टेस्ट स्कैफ़ोल्डिंग) जिनमें AI अच्छा है स्थानांतरित हो जाते हैं। केवल मापनीय कार्य आगे बढ़ते हैं। यह Goodhart's Law (जब एक माप लक्ष्य बनता है, तो वह अच्छा माप नहीं रहता) का पाठ्यपुस्तकीय रूप है।

इतिहास दोहराता है: 1990 के दशक में, कई कंपनियों ने डेवलपर्स का मूल्यांकन KLOC (कोड की एक हज़ार लाइनें) से करने की कोशिश की। परिणाम: "बिना उद्देश्य के भरा गया कोड," "सरल तर्क को लंबे ढंग से लिखना," "उपयोगी रीफैक्टर से बचना (क्योंकि वे लाइन संख्या घटाते हैं)।" तीस वर्ष बाद, हम "टोकन" नामक नई इकाई से वही गलती दोहरा रहे हैं।

5. बेहतर मेट्रिक्स — AWU, DORA, परिणाम-आधारित

यदि टोकन उत्तर नहीं हैं, तो आपको क्या मापना चाहिए? तीन 2026-शैली के विकल्प

वैकल्पिक मेट्रिक्स × 3

टोकन से परे AI प्रभाव मापें

① AWU (Agentic Work Units)
Salesforce का 2026 प्रस्ताव। AI इनपुट (टोकन, कंप्यूट) को पूर्ण किए गए कार्य की इकाइयों में अनुवाद करता है। "क्या बना" को स्केलर बनाता है। मानकीकरण अभी प्रगति पर है।
② DORA 4 Metrics
Google-मूल। Deploy आवृत्ति, lead time, change failure rate, MTTR15 वर्षों की मान्यता के साथ परिणाम-केंद्रित। AI युग में भी कार्य करता है।
③ परिणाम संकेतक
AWS-अनुशंसित। Deployment गति, कोड गुणवत्ता, परिचालन दक्षता, टीम उत्पादकता, व्यावसायिक प्रभाव संयोजन में। सटीकता के लिए सरलता का त्याग।

इनमें साझा क्या है: "क्या निकला" मापें, "क्या उपयोग हुआ" नहीं।
पकड़ना कठिन, लेकिन इनमें से कोई भी अकेले टोकन खपत की तुलना में बेहतर निर्णय चलाएगा।

मेरा व्यक्तिगत फैसला: DORA सबसे व्यावहारिक है। पंद्रह वर्षों का परिचालन उपयोग, प्रचुर बेंचमार्क डेटा, और AI युग में विकृत होने की संभावना कम। Salesforce का AWU महत्वाकांक्षी है लेकिन अभी उद्योग मानक नहीं। यदि आप कल मापने योग्य कुछ चाहते हैं, तो DORA से शुरू करें

6. व्यक्तियों और संगठनों के लिए आज ही पाँच कदम

सिद्धांत तय। कल सुबह आप वास्तव में क्या कर सकते हैं? भूमिका के अनुसार विभाजित।

व्यक्तिगत डेवलपर्स के लिए

  • ① टोकन खपत को अपना मेट्रिक न बनाएँ: भले ही आपका मैनेजर देख रहा हो, स्वयं का मूल्यांकन आपने जो पूरा किया उससे करें। यदि कोई कार्य AI के बिना तेज़ है, तो उस पर AI न थोपें
  • ② समीक्षा समय का बजट बनाएँ: मानें कि AI-जनित कोड में "पढ़ने का समय ≥ लिखने का समय।" समीक्षा के लिए भेजने से पहले अपने PR को पूरी तरह पढ़ने का समय आवंटित करें
  • टोकन बचत के साथ संयोजित करें: prompt caching, Batch API, संक्षिप्त निर्देश — "कम टोकन उपयोग के साथ उच्च परिणाम" ही वास्तविक कौशल है

प्रबंधन के लिए

  • ④ टोकन खपत का उपयोग केवल खरीद संकेत के रूप में करें: व्यक्तिगत मूल्यांकन के रूप में कभी नहीं। केवल यह पुष्टि करने के लिए संगठन-व्यापी ट्रैक करें कि AI निवेश का उपयोग हो रहा है, इससे अधिक नहीं
  • ⑤ DORA मेट्रिक्स पर स्विच करें: Deploy आवृत्ति, change failure rate, MTTR त्रैमासिक चक्र पर। यह देखने के लिए AI अपनाने से पहले/बाद की तुलना करें कि लाभ वास्तविक हैं या केवल टोकन पंपिंग
सबसे महत्वपूर्ण: कार्यकारी, CFO, या बोर्ड को रिपोर्ट करते समय, "टोकन खपत एक गतिविधि मेट्रिक है, व्यावसायिक परिणाम परिणाम मेट्रिक्स हैं" को अलग करें। सब कुछ एक संख्या से समझाने की कोशिश ही लापरवाह निर्णयों को जन्म देती है। "उपयोग की मात्रा" और "उत्पादित मूल्य" को अलग विषयों के रूप में देखें — यह अनुशासन AI युग में संगठन को अच्छी तरह चलाने की कुंजी है।

सारांश

संक्षेप:

  • 2026: Amazon, Meta, Microsoft पर "Tokenmaxxing" (मेट्रिक मुद्रास्फीति के लिए टोकन-पंपिंग) देखा गया — अब एक उद्योग शब्द
  • Faros AI 22,000-डेवलपर अध्ययन: AI उपयोग कार्य पूर्णता +34% बढ़ाता है लेकिन बग्स +54%, समीक्षा समय 5 गुनामात्रा और गुणवत्ता विचलित होती हैं
  • "टोकन खपत = कार्य उत्पादन" 1990 के दशक के KLOC मूल्यांकन का 2020 के दशक का दोहराव है। Goodhart's Law विकृति को अपरिहार्य बनाता है
  • तीन ज़मीनी विकृतियाँ: टोकन पंपिंग / सार के बजाय गति / AI-अनुकूल कार्यों की ओर बहाव
  • विकल्प: Salesforce AWU / DORA 4 / AWS परिणाम संकेतक। आज DORA सबसे व्यावहारिक है
  • व्यक्ति: स्वयं का मूल्यांकन पूर्ण किए गए कार्य से करें। संगठन: मूल्यांकन को DORA पर स्विच करें, टोकन खपत को केवल गतिविधि-स्तरीय डेटा के रूप में रिपोर्ट करें

2026 में, संगठनों के भीतर AI के साथ, मात्रा मापने का प्रलोभन पहले से कहीं अधिक प्रबल है। API लॉग आपको मुफ़्त में टोकन संख्या देते हैं — इसीलिए उन संख्याओं को "कार्य उत्पादन" के रूप में पढ़ने का जाल इतना गहरा है। तीस वर्ष पहले KLOC से हमने जो सबक सीखा वह "टोकन" नामक नई इकाई में नहीं दोहराया जाना चाहिए। यही AI युग में आवश्यक संगठनात्मक बुद्धिमत्ता का पहला हिस्सा है।

FAQ

Q1. क्या यह छोटी कंपनियों में भी होता है?

हाँ, आकार की परवाह किए बिना। वास्तव में, छोटी कंपनियों पर "मापनीय से मूल्यांकन" का दबाव अधिक होता है, और नेता सबसे आसान मेट्रिक पकड़ लेते हैं। यहाँ तक कि स्टार्टअप्स भी "100% AI उपयोग लक्ष्य" जैसे आंतरिक नियम बना रहे हैं। वही जाल।

Q2. AI-विरोधी कर्मचारियों को कैसे चलाएँ?

"इसे आज़माएँ और मुझे बताएँ कि आप क्या सोचते हैं" दीर्घकाल में "इसका उपयोग करें" से बेहतर काम करता है। टोकन कोटा अल्पकाल में संख्याएँ उत्पन्न करते हैं लेकिन विरोधियों को दिखावे के लिए उपयोग करने वाले लोगों में बदल देते हैं। वास्तविक अपनाने के लिए मनोवैज्ञानिक सुरक्षा और प्रशिक्षण निवेश आवश्यक है — नई-तकनीक रोलआउट का बुनियादी नियम, जो केवल AI के लिए अनूठा नहीं है।

Q3. क्या यह इंजीनियरिंग के बाहर (बिक्री, मार्केटिंग) पर भी लागू होता है?

और भी अधिक। बिक्री और मार्केटिंग आउटपुट गुणात्मक और मापने में कठिन हैं, इसलिए नेता "AI-तैयार प्रस्तावों की संख्या" या "दागे गए ChatGPT प्रश्न" जैसे सतही मेट्रिक्स पकड़ लेते हैं। इसके बजाय आपको मापना चाहिए: क्लोज़ दर, ग्राहक संतुष्टि, lead time — परिणाम मेट्रिक्स जो AI से पहले भी मौजूद थे।

Q4. मैं अपनी टीम के लिए DORA कैसे मापूँ?

मुफ़्त टूल्स काम करते हैं। GitHub Insights, Jellyfish, LinearB, Faros AI। Google के आधिकारिक dora.dev पर बेंचमार्क और स्पष्टीकरण हैं। शुरुआत में मैन्युअल एकत्रीकरण ठीक है — केवल तिमाही-दर-तिमाही तुलना यह उजागर कर देती है कि AI वास्तविक मूल्य उत्पन्न कर रहा है या नहीं

Q5. क्या "टोकन खपत = कार्य उत्पादन" पूरी तरह गलत है?

पूरी तरह गलत नहींसमग्र संगठनात्मक AI गतिविधि के एक मैक्रो संकेतक के रूप में, यह उपयोगी है। "उपयोग नहीं हो रहा" एक वास्तविक संकेत है। समस्या है इसे व्यक्तिगत मूल्यांकन, KPI, या कोटा के लिए उपयोग करनामैक्रो अवलोकन के रूप में ठीक, व्यक्तिगत माइक्रो मूल्यांकन के रूप में नहीं — इन्हें अलग रखें।