Uber COO का कहना है कि tokenmaxxing पर होने वाले खर्च को सही ठहराना अब लगातार मुश्किल होता जा रहा है

 (businessinsider.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Uber के COO का मानना है कि AI पर होने वाले खर्च को, उससे मिलने वाले नतीजों के अनुपात में, सही ठहराना अब लगातार मुश्किल होता जा रहा है
  • Uber के CTO द्वारा यह बताने के बाद कि 2026 के लिए Claude Code का बजट पहले ही खत्म हो चुका है, कंपनी के भीतर चर्चा तेज हो गई
  • अधिक token usage का सीधा अनुपात में अधिक उपयोगी consumer features से जुड़ना अभी तक साबित नहीं हुआ है
  • Uber के CEO ने कहा कि AI निवेश की भरपाई के लिए Uber hiring की रफ्तार धीमी कर रहा है
  • Big Tech के tokenmaxxing रुझान के विपरीत, Duolingo ने कर्मचारियों की प्रतिक्रिया के बाद AI उपयोग को performance review में शामिल करने का फैसला वापस ले लिया

Uber के अंदर AI लागत को सही ठहराने की समस्या

  • Uber के COO Andrew Macdonald का मानना है कि कंपनी के भीतर AI लागत को सही ठहराना अब लगातार कठिन होता जा रहा है
  • शनिवार को जारी Rapid Response इंटरव्यू में उन्होंने कहा कि AI अभी कंपनी द्वारा किए जा रहे खर्च के अनुपात में असर नहीं दिखा रहा है
  • Uber CTO Praveen Neppalli Naga ने अप्रैल में The Information को दिए इंटरव्यू में कहा था कि Uber, 2026 के लिए Claude Code का बजट पहले ही खर्च कर चुका है; इसके बाद आंतरिक चर्चा और बढ़ गई
  • इस बयान ने ऐसी स्थिति पैदा की जिसे Macdonald ने “दिमाग फटने जैसा पल” कहा, और कंपनी के भीतर AI token consumption तथा workforce size के बीच trade-off पर चर्चा होने लगी

token usage और product outcomes के बीच कड़ी का अभाव

  • Macdonald ने Uber के senior engineering leaders से बातचीत के बाद यह निष्कर्ष निकाला कि अधिक token usage का मतलब उपयोगी consumer features में समान अनुपात में बढ़ोतरी नहीं है
  • उनके शब्दों में, “वह कड़ी अभी मौजूद नहीं है”; यानी संभव है कि अधिक features ship हो रहे हों, लेकिन किसी खास metric को सीधे इस निष्कर्ष से जोड़ना मुश्किल है कि “अब हम वास्तव में 25% अधिक उपयोगी consumer features बना रहे हैं”
  • जब AI पर होने वाला खर्च नतीजों से सीधे नहीं जुड़ पाता, तब उससे जुड़े trade-off costs को सही ठहराना और कठिन हो जाता है
  • CEO Dara Khosrowshahi ने इसी महीने की शुरुआत में earnings call में कहा कि AI निवेश की भरपाई के लिए Uber hiring धीमी कर रहा है

users को मुफ्त जैसा लगता है, लेकिन लागत कंपनी उठाती है

  • Macdonald का कहना है कि अगर users खुद पैसे नहीं दे रहे हों और सिर्फ “दिलचस्प use cases” सोच रहे हों, तो AI उन्हें मुफ्त जैसा लग सकता है
  • लेकिन अंततः कंपनी ही इसकी लागत चुकाती है
  • AI उपयोग का विस्तार केवल productivity experiment नहीं, बल्कि ऐसी cost structure के रूप में देखा जा रहा है जो budget और staffing पर असर डालती है

Big Tech के tokenmaxxing से अलग रुझान

  • Big Tech, AI का अधिकतम उपयोग करने वाले tokenmaxxing पर जोर दे रही है, और कुछ कंपनियां कर्मचारियों के AI उपयोग को evaluation में शामिल कर रही हैं
  • Meta, Google, JPMorgan उन कंपनियों में गिने गए हैं जो AI उपयोग को performance reviews, goals, raises और promotions से जोड़ रही हैं
  • दूसरी ओर, कुछ कंपनियां AI उपयोग को हर हाल में आगे बढ़ाने के तरीके से पीछे हटने लगी हैं
  • Duolingo ने तब AI उपयोग को performance review में शामिल करने का फैसला वापस लिया जब कर्मचारियों ने पूछा, “क्या AI इस्तेमाल करने के लिए ही AI इस्तेमाल करना चाहिए?”
  • Duolingo CEO Luis von Ahn ने अप्रैल के एक podcast इंटरव्यू में कहा कि यह वास्तविक नतीजों की जवाबदेही तय करने से ज्यादा, कुछ मामलों में अनुपयुक्त चीज़ को ज़बरदस्ती आगे बढ़ाने जैसा लगने लगा था

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • 2007~2009 में, जब Google data center capacity को तेज़ी से बढ़ा रहा था, खासकर काम के घंटों के बाहर, idle capacity बहुत ज़्यादा होती थी
    कोई भी engineer priority 0 पर जितना चाहे उतना काम चला सकता था, और जब कोई ज़्यादा महत्वपूर्ण काम resources माँगता, तो वही jobs सबसे पहले मार दी जाती थीं
    रात भर चलने वाले MapReduce experiments बहुत किए गए, और कुछ समय तक internal services भी priority 0 पर चलती रहीं, इसलिए वे लगभग “मुफ़्त” जैसी चलती थीं
    usage बढ़ने के साथ ऐसी services धीरे-धीरे unstable हो गईं, और आखिरकार या तो उनके resource usage को justify करना पड़ा या scale down करना पड़ा, लेकिन वह सही दिशा थी
    AI token usage के लिए भी ऐसा ही model अच्छा लग सकता है। बड़ी tech companies अपने LLM data centers रख सकती हैं, internal demand संभाल सकती हैं, और फिर काम के बाहर की idle capacity को employees के experiments के लिए खोल सकती हैं
    रोज़मर्रा के काम में token count से ज़्यादा token efficiency को बढ़ावा देना चाहिए। हर हफ़्ते कई घंटे की human labor बचाने वाली automation पर बहुत tokens खर्च करना अच्छा उपयोग है, लेकिन एक आसान frontend bug को debug करने में बहुत tokens जला कर भी 4 घंटे लगना बर्बादी है

    • क्या यह OpenAI की batch processing जैसा नहीं है? request 24 घंटे के भीतर process हो जाती है और cost आधी होती है
      https://developers.openai.com/api/docs/guides/batch
    • नहीं लगता कि LLM users इतने logical तरीके से व्यवहार करेंगे। काफ़ी users शायद insist करते हैं कि हर छोटी-मोटी task पर Opus ही फेंकना चाहिए
    • ज़्यादातर AI frontends interactive work के हिसाब से बने हैं, इसलिए ऐसे priority 0 tasks define करना मुश्किल हो जाता है जिन्हें कभी भी process हो जाना काफ़ी हो
      spec-driven development जैसी workflows में, जहाँ इंसान लगातार loop के अंदर नहीं बल्कि ऊपर से verify करता है, यह approach कहीं ज़्यादा natural लगती है, लेकिन कम-से-कम Google frontend experience के आधार पर, अभी तक मैंने ऐसा कहीं ठीक से supported नहीं देखा
    • आसान frontend bugs पर बहुत tokens खर्च करके भी 4 घंटे लगने से रोकने को कहना आसान नहीं होगा
      जो अभी हो रहा है, वह बहुत लोगों को पहले से ही साफ़ दिख रहा था। जानबूझकर addict बनाने के लिए बनाए गए नए addicts से “थोड़ा ज़्यादा सोच-समझकर consume करो” कहना है, इसलिए यह शायद काम नहीं करेगा
    • आख़िर में ज़्यादा plausible यही नहीं लगता कि सब लोग 10x सस्ते Chinese models को स्वीकार कर लेंगे?

  • मुझे AI इस्तेमाल करना पसंद नहीं है, और न ही यह ख़ास मददगार लगता है
    लेकिन company इस्तेमाल करने पर मजबूर करती है और metrics track करती है, इसलिए मैं हर दिन बेकार के छोटे-मोटे काम इसमें फेंक देता हूँ ताकि लगे कि मैंने इसका उपयोग किया
    भले ही problems ठीक करने से ज़्यादा नई problems बना दूँ, metrics में मैं AI इस्तेमाल करने वाला इंसान दिखता हूँ

  • अगर कोई company announce करे कि वह token consumption को employee performance signal की तरह इस्तेमाल करती है, तो वह लगभग एक red flag है जिससे बचना चाहिए
    अच्छी engineering leadership वाली company को इसे ठीक-ठाक idea की तरह treat नहीं करना चाहिए

    • अगर business trip meal limit 100 dollar से ऊपर चली जाए, तो manager या finance team के साथ awkward बातचीत करनी पड़ती है
      लेकिन अगर आप AI tokens पर 500 dollar बेकार जला दें, तो company में आपको top-tier AI adopter माना जाता है — इस पर हम लोग अक्सर तंज कसते हैं
    • आपको हैरानी हो सकती है, लेकिन मैं कुछ ऐसे बड़े tech company developers को जानता हूँ जो FAANG में नहीं हैं, फिर भी सबके नाम सब जानते हैं, और उन सबके यहाँ किसी-न-किसी रूप में token leaderboard है
      कुछ companies तो developers से यह तक कहती हैं कि “अब हम नहीं चाहते कि आप code की एक भी line सीधे खुद लिखें”
      executive नज़रिये से शायद सोच यह है: अगर top 20% employees LLM से 80% code बनाते हैं और company फिर भी चल रही है, तो नीचे के 80% developers घटाकर cost बचाई जा सकती है
    • जिन companies में पहले sensible leadership थी, उन्होंने भी LLM AI आने के बाद जल्दीबाज़ी और questionable फैसले लेने शुरू कर दिए
      employee performance evaluation में token usage डालना बस उन्हीं में से एक है
    • tokens नए lines of code per engineer हैं। graph पर दिखाना आसान, और “manage” करना भी आसान
    • Meta यह करता है। हाल की layoffs के criteria में क्या-क्या रहा होगा, इसका अंदाज़ा लगा लो

  • आसमान में मौजूद उस विशाल fusion reactor के नीचे सच में बहुत कम चीज़ें नई होती हैं
    James Gleick की “The Information” में मैंने telegraph industry के tokenmaxxing जैसी चीज़ों के बारे में पढ़ा था
    telegrams में हर character पर charge लगता था, इसलिए भेजे जाने वाले text को घटाने वाली codebook market बहुत बड़ी थी। compression यानी सीधे पैसे की बचत, और telegraph companies इसे नापसंद करती थीं, लेकिन मानना पड़ता था
    telegraph code industry telegraph के commercial होने के शुरुआती दौर से शुरू होकर 1920s तक चली
    लेकिन इसकी cost भी थी। code redundancy को बहुत घटा देता था, इसलिए बहुत छोटी error भी बड़ी misunderstanding में बदल सकती थी
    Gleick के वर्णन के मुताबिक, यह उस तरीके के ठीक उलट था जिसमें African drum performance rhythm और drum जिस language की नकल करता है, उनके रिश्ते को मज़बूत करने के लिए redundancy बढ़ाई जाती थी

    • क्या यह tokenmaxxing के बिल्कुल उलट नहीं है? अगर telegraph analogy लेनी है, तो स्थिति ऐसी होनी चाहिए जहाँ telegraph operator का आकलन customer throughput से नहीं बल्कि इस बात से हो कि उसने दिन में line को कितनी देर तक occupy किया
      यानी सबसे ज़्यादा tokens या cost जलाने वाला जीतता, न कि features deliver करने वाला programmer
      आपने जो बताया वह token maximization नहीं, बल्कि token minimization के ज़्यादा क़रीब है
    • दिलचस्प है, लेकिन tokenmaxxing का मतलब token use efficiency को maximize करना नहीं, बल्कि usage को ही maximize करना है
    • आपने जो समझाया, वह असल में tokenmaxxing का उलटा है

  • LLM से पहले से ही software stack को लेकर एक सवाल हमेशा रहा है, और अब यह और भी प्रासंगिक लगता है
    Uber जैसी कंपनी आखिर कब “complete” होगी? यह 16 साल से software बना रही है
    यह drivers और riders को match करने वाली कंपनी है, और सिर्फ और software बनाने से इस बात की संभावना बहुत नहीं बढ़ती कि मैं bus या train की जगह Uber चुनूँगा
    क्या 20 साल बाद software खत्म हो जाएगा? या 80 साल बाद?

    • codebase का ज़्यादातर हिस्सा regional market-specific integrations है। उसका कुछ हिस्सा व्यवस्थित किया जा सकता है, लेकिन जटिलता का बड़ा भाग वहीं से आता है
    • अगर browser, Android, iOS 16 साल से ज़्यादा समय तक रुक जाएँ, तो शायद चीज़ें थोड़ी आसान हो जाएँ
      बदलता regulatory environment और नए products को भी नहीं भूलना चाहिए। सिर्फ यह देख लीजिए कि Uber Eats कब आया
      उन 16 सालों में Covid-19 आया, practical autonomous driving सामने आई, और Waymo के साथ partnership भी हुई
      network-connected mass-market apps बिना पूर्ण दूरदर्शिता के कभी “complete” नहीं हो सकते
      internal tech stack एक जीवित organism की तरह है, और ऊपर से न बदलने वाली दिखने वाली service को बनाए रखने में भी बहुत काम लगता है। scaling भी बहुत बड़ा काम है, और scaling और maintenance एक-दूसरे को लगातार बढ़ाते हैं
    • लगता है लोग international operations और optimization की जटिलता को कम आँकते हैं
      हर देश के अपने कानून हैं कि Uber क्या कर सकता है और क्या नहीं, और इन्हें code में formalize करना पड़ता है
      उदाहरण के लिए, कुछ जगहों पर Uber app से वास्तव में taxi बुलाई जाती है, और किराया भी fixed upfront amount की जगह per-mile हो सकता है
      इसके ऊपर city-level laws भी जुड़ जाते हैं। अगर आप अलग कानून वाले शहर A से शहर B तक Uber लेते हैं, तो क्या होना चाहिए? वकील जवाब जान सकता है, लेकिन app को उसका पालन करना होता है
      और कानून लगातार बदलते भी रहते हैं
      optimization का भी कोई अंत नहीं है। speed, cost, routing जैसी चीज़ों में हमेशा सुधार की गुंजाइश रहती है
      consumer के रूप में जो हिस्सा हम देखते हैं, वह ऐसी service को बनाते और चलाते समय पैदा होने वाली जटिलता का बहुत छोटा टुकड़ा भर है
    • लागू करने के लिए हमेशा नई technologies और techniques होती हैं। बेहतर algorithms, बड़े deployments, और अधिक reliability की भी ज़रूरत होती है
      लगभग हमेशा कुछ bugs भी होते हैं जिन्हें ठीक करना पड़ता है। और bugs वाकई बहुत होते हैं
    • क्या Uber खुद का autonomous driving भी करने की कोशिश नहीं कर रहा था?
      यह उस कंपनी की समस्या भी है जिसने भारी investment जुटाई है। Uber की valuation सिर्फ उसके आज के काम पर नहीं, बल्कि इस उम्मीद पर आधारित है कि वह personal car ownership या public transport जैसी अवधारणाओं को पुराना बना देगा
      यह अतिशयोक्ति है, लेकिन फिर भी जितनी लगती है उससे कम अतिशयोक्ति है

  • tokenmaxxing का कोई मतलब नहीं है। यह वैसा है जैसे जानबूझकर inefficient SQL/Spark jobs लिखना ताकि जितना हो सके उतना compute, memory और I/O खर्च हो
    यानी जानबूझकर Cartesian products, बेहद skewed datasets जैसी चीज़ें भर देना
    जब metric ही goal बन जाता है, तो हमेशा ऐसा होता है। कंपनियों को ऐसा माहौल बनाना चाहिए जहाँ AI का इस्तेमाल जितना हो सके उतना efficiently हो, और पहले यह पूछा जाना चाहिए कि “क्या इस काम के लिए सच में agent चाहिए?”
    अगर चाहिए, तो फिर यह तय होना चाहिए कि कौन-सा agent, कौन-सा model, और किस स्तर की reasoning चाहिए
    token बचत, cache hit rate बढ़ाना, और कम context में information इस्तेमाल की जा सके ऐसी information structuring को भी बढ़ावा देना चाहिए। knowledge graph इसमें काफ़ी अच्छा है

    • यह toddler-level logic है। “X का उपयोग करने से अच्छे परिणाम मिल सकते हैं। इसलिए अच्छे परिणाम अधिकतम करने के लिए X का अधिकतम उपयोग करना चाहिए” जैसी सोच
      यह race जीतने के लिए पेट्रोल पंप में आग लगा देने जैसा है
    • tokenmaxxing इसलिए मौजूद है क्योंकि executives को लगता है कि कर्मचारी बदलाव का विरोध कर रहे हैं
      यह सिर्फ़ कर्मचारियों को नई technology के साथ experiment करने के लिए प्रेरित या मजबूर करने का तरीका है
      जब यह मान लिया जाएगा कि सभी लोग AI का उपयोग कर रहे हैं, तो tokenmaxxing जैसी चीज़ें स्वाभाविक रूप से खत्म हो जाएँगी
    • tokenmaxxing के पक्ष में दी जाने वाली दलील आमतौर पर यह होती है कि इससे कर्मचारियों को AI-based workflows जैसी व्यापक और नई जगह को आज़ादी से explore करने की गुंजाइश मिलती है
      मैंने बहुत से ऐसे use cases देखे हैं जिनसे value बन रही है या नहीं, इस पर शक था, लेकिन मैंने ऐसी teams भी देखी हैं जिन्होंने agentic workflows से पुराने problems हल किए, जबकि cost review committee के सामने उन्हें justify करना मुश्किल होता
      token बचत, cache hit rate बढ़ाने, और कम context इस्तेमाल करने लायक information structuring का काम, मेरी समझ से, बड़ी tokenmaxxing कंपनियों में अक्सर अलग teams पीछे से करती हैं

  • समझ आता है कि कंपनियाँ AI-assisted development पर पैसा जला रही हैं। लेकिन कुल ROI क्या है? क्या यह वास्तव में उतना value दे रहा है जितना claimed efficiency gain कहा जाता है?
    AI boom में सचमुच दिलचस्प बात तो बस यही है, लेकिन पता नहीं कोई इस पर बात क्यों नहीं करता

    • शायद इसलिए कि बहुत कम लोग इसे ठीक से measure करना जानते हैं
      Claude के साथ आप एक दिन में 5 बेकार या खराब features बना सकते हैं, या दो दिन में 1 उपयोगी feature बना सकते हैं। ROI पर बेहतर असर किसका होगा?
      उदाहरण में यह आसान सवाल लगता है, लेकिन असल दुनिया में यह कहीं ज़्यादा subtle है और इसे measure करना भी बहुत कठिन है
      इसलिए लगता है कि बहुत-सी कंपनियाँ measurement छोड़कर hype के पीछे चलने वाला आसान विकल्प चुन लेती हैं

  • code review सहित सही तरीके से इस्तेमाल करने पर, AI से engineering productivity में टिकाऊ अधिकतम सुधार, पर्याप्त skill वाले senior engineer के लिए लगभग 20% है — इस पर मुझे भरोसा है
    किसी engineer का token budget इससे ज़्यादा नहीं होना चाहिए
    मुझे नहीं लगता कि tokenmaxxing करने वाले engineers सच में productive होते हैं, और मैंने इसका कोई सबूत भी नहीं देखा है। बल्कि सच्चाई शायद उलटी हो सकती है
    सही workflow और codebase knowledge हो, तो टिकाऊ effort level पर इतना सुधार संभव है — यह मैंने खुद महसूस किया है

  • लगता है engineering productivity के लिए AI को एक ऐसे magic button की तरह गलत समझा जा रहा है जो वही परिणाम ज़्यादा तेज़ और सस्ते में दे देता है
    अगर तर्क यही हो, तो कर्मचारियों पर tokenmaxxing थोपने का मन होना स्वाभाविक है। जब ज़्यादा output तेज़ और सस्ते में मिल सकता है, तो फिर क्यों न किया जाए?
    लेकिन बात इससे ज़्यादा nuanced है। AI roadmap को कुछ हद तक तेज़ी से हासिल करने में मदद करता है, लेकिन इससे वैसा technical debt भी बनता है जैसा किसी अस्थायी developer को रखकर features बनवाने से बनता है
    यह ज़रूरी नहीं कि team में कोई नया code वास्तव में समझने वाला भी बन जाए
    इसी तरह junior team members की skill growth भी कम होती है। पहले जैसा skill-wage spread arbitrage निकालना कठिन हो जाता है
    product भी अधिक complex हो सकता है। किसी feature के P2 होने की वजह होती है, लेकिन AI की वजह से कम marginal benefit वाले features भी शामिल होकर product को जटिल बना सकते हैं

  • यह सोचकर ही झटका लगता है कि किसी ने tokenmaxxing को अच्छा विचार माना
    AI maximalists अक्सर इस technology की तुलना electricity से करते हैं। ज़रा कल्पना कीजिए कि electrification के शुरुआती दौर में CEO कर्मचारियों को business outcomes देने वाले electric use cases खोजने के बजाय बिजली की खपत बढ़ाने पर reward देते
    उस दौर में mental illness के लक्षण दिखाने वाले लोगों को संस्थानों में बंद करना आम बात थी, इसलिए शायद उसका अंत वैसा ही होता

    • दिक्कत यह है कि व्यक्तिगत स्तर पर यह अच्छी strategy है। खराब management इसे productivity signal की तरह पढ़ती है