Uber ने Claude Code पर 2026 का पूरा AI बजट सिर्फ 4 महीनों में खर्च कर दिया

• Uber ने Claude Code और Cursor के बढ़ते उपयोग के कारण 2026 का पूरा AI बजट सिर्फ 4 महीनों में खर्च कर दिया, और प्रोडक्टिविटी प्रयोग तुरंत बजट की दोबारा समीक्षा के मुद्दे में बदल गया
• Uber के CTO ने बताया कि प्रति engineer मासिक API लागत 500~2,000 डॉलर के स्तर पर थी, और engineers में से 95% हर महीने AI tools का उपयोग कर रहे हैं
• Uber में commit किए गए code का 70% AI से आया, जिससे AI coding tools engineering काम के मुख्य workflow का हिस्सा बन गए हैं
• Claude Code को 2025 के दिसंबर में engineering team में deploy किया गया था, और multi-step task क्षमता की पुष्टि होने के बाद 2026 के फरवरी तक इसका उपयोग दोगुना हो गया; अप्रैल तक इसने वार्षिक बजट पूरा खर्च कर दिया
• Cursor के उपयोग में बढ़ोतरी ठहर गई, जबकि Claude Code प्रमुख tool बन गया, और Uber अब अपने 3.4 अरब डॉलर के वार्षिक R&D खर्च के भीतर AI coding tools की लागत की फिर से गणना करने की स्थिति में है

---

अपनाने का विस्तार और बजट की दोबारा समीक्षा

• Uber में Claude Code और Cursor का उपयोग तेजी से बढ़ा, और लागत में उछाल के बावजूद engineers इन दोनों tools की value को इतना ऊंचा मानने लगे कि उनका उपयोग रोकना मुश्किल हो गया
• 2025 के दिसंबर में engineering team को Claude Code access दिया गया, और multi-step task क्षमता की पुष्टि होने के बाद 2026 के फरवरी तक इसका उपयोग दोगुना हो गया
• 2026 के अप्रैल में लागत ने पूरे वार्षिक AI बजट को खत्म कर दिया, जिससे leadership को ऐसा फैसला लेना पड़ा जिसकी उसने पहले कल्पना नहीं की थी
• Uber के CTO ने कहा कि कंपनी को AI budget planning में फिर से “back to the drawing board” पर लौटना पड़ा

टूल के अनुसार उपयोग में बदलाव

• Cursor अपनाने की दौड़ में एक और प्रमुख tool था, लेकिन उसके उपयोग में वृद्धि ठहर गई
• Claude Code engineering workflow में प्रमुख tool बन गया
• प्रोडक्टिविटी प्रयोग के रूप में शुरू हुई तैनाती तेजी से फैल गई, और कंपनी के अंदर engineering काम में AI tools का उपयोग पूरी तरह से शुरू हो गया

लागत के दबाव का मतलब

• Uber का अप्रत्याशित बजट खत्म होना दिखाता है कि engineering productivity में AI tools को कितना मूल्यवान माना जा रहा है
• AI tools की भूमिका इतनी बढ़ गई है कि उनकी पहुंच सीमित करना उल्टा गैर-उत्पादक लगने लगा है
• जैसे-जैसे अधिक developers Claude Code अपना रहे हैं, वैसी ही स्थिति दूसरी कंपनियों में भी हो सकती है
• software कंपनियों पर development speed बनाए रखते हुए लागत को संभालने का दबाव बढ़ेगा
• अगर developer productivity tools इतने मूल्यवान साबित हो रहे हैं कि engineers सिर्फ 4 महीनों में पूरा बजट खर्च कर दें, तो निष्कर्ष यह निकलता है कि समस्या tools में नहीं, बल्कि इस बात में है कि adoption curve का अनुमान लगाने के लिए बजट बहुत जल्दी तय कर दिया गया था

[picopress]

पैसे उड़ाने का मज़ा

[GN⁺]

Hacker News की राय

• अगर कंपनी के खर्चों को महीने में एक बार भी देखो, तो यह देखकर उलझन होती है कि धीरे-धीरे ज़्यादा लोग हर महीने $1k token cost खर्च कर रहे हैं — आखिर यह संभव कैसे है
  मैं रोज़ LLM इस्तेमाल करता हूँ, और सबसे महंगे model के साथ deep thinking mode भी चलाऊँ तो आम तौर पर $200~$400 ही ऊपरी सीमा होती है। मैं इस्तेमाल का विरोध करने वाला luddite नहीं हूँ; मतलब सिर्फ इतना है कि ज़िम्मेदारी से हर महीने इतना पैसा कैसे जलाया जा सकता है, यह समझना मुश्किल है। जो लोग हर महीने $5k~$10k खर्च करते हैं, काश वे दिखाएँ कि वह कैसे $50k~$100k की value में बदलता है। कंपनी के नज़रिए से देखें तो सालाना $100k token spend को justify करने से बेहतर शायद यह होगा कि $100~$200/माह खर्च करके productivity देने वाला कोई junior engineer रख लिया जाए

  • ज़िम्मेदारी से इतना पैसा जलाने के ज़्यादातर तीन ही तरीके दिखते हैं। beginner लोग लंबी conversations का reuse करते रहते हैं, इसलिए context compression या summary checkpoints नहीं बनाते, और एक विशाल single conversation को इसलिए घसीटते रहते हैं क्योंकि उन्हें लगता है कि agent “trained” हो गया है
    intermediate लोग “5 sub-agents चलाओ, अलग-अलग angles से समाधान analyze कराओ और summary बनवाओ” जैसी patterns सीखने के बाद आसानी से इसके आदी हो जाते हैं। यह अपने-आप में बुरी आदत नहीं है, लेकिन सावधानी न रखी जाए तो credits बहुत ज़्यादा उड़ जाते हैं। experienced लोग 10 task trees को लगातार parallel में चलाते रहते हैं और agent responses के बीच आना-जाना करते हुए बहुत extreme multitasking करते हैं, जिससे लागत exponential तरीके से बढ़ सकती है
  • पहली वजह तो वही सीधी है: “कंपनी इजाज़त दे रही है तो बर्बादी होगी।” इसमें context को बार-बार clear या compress न करना भी शामिल है। Opus की 1M context window अब मौजूद है, और 200K तक quality भी ठीक रहती है, इसलिए clear करने से पहले हर query पर बहुत tokens जलते हैं
    बड़ा codebase या complex problem भी एक बड़ा factor है। अगर आप टीम में नए आए हैं और कई हिस्से नहीं जानते, तो काम मिलने पर Claude से related code ढूँढवाना, मौजूदा flow समझवाना, और उसके बाद ही changes करवाने की कोशिश करना स्वाभाविक हो जाता है। इससे domain expertise कम बनती है, लेकिन Claude की मदद से 5 दिन का काम 1 दिन में हो सकता है, और अगर सब ऐसा कर रहे हों तो पीछे नहीं रह सकते। इसलिए मैं बीच का रास्ता लेता हूँ: 1 दिन की जगह 2~3 दिन में खत्म करना, और code खुद भी थोड़ा देखना। खासकर AI की वजह से code change की speed बहुत बढ़ गई है, इसलिए हमने ऐसा tool भी बनाया जो pull requests को LLM से गहराई से explain करवाता है। यह reviewer के लिए नहीं, बल्कि टीम के काम के साथ बने रहने के लिए है। मैंने अभी तक LLM को और बेहतर कैसे इस्तेमाल करना है, इस पर भी ज़्यादा नहीं सोचा है, और अगर codebase से पहले से परिचित होता तो शायद और भी ज़्यादा इस्तेमाल करता। bottleneck अभी भी proper testing और review ही है। कम महत्वपूर्ण internal code या personal code में तो लगता है कि ज़्यादातर काम लगभग पूरा AI को ही दे देता हूँ, और “superpowers” skill इस्तेमाल करो तो basic functionality पर भी बहुत tokens जलते हैं। आम तौर पर 20~40K tokens से शुरू होता है और अंत तक 80~90K tokens पर पहुँच जाता है, इसलिए completion से ठीक पहले वाली कई requests में लगभग 80K tokens भेजे जा रहे होते हैं। यह waste है, लेकिन जब कोई और pay कर रहा हो तो ऐसा ही होता है
  • मैंने Claude Code को समस्याओं के लिए बेहद token-inefficient solutions चुनते देखा है। मैंने एक complex machine learning/prediction problem को कई agents में बाँटा, और हर agent Jupyter notebook इस्तेमाल कर रहा था, चला रहा था, और पढ़ भी रहा था
    शुरुआत में ठीक था, लेकिन एक agent ने cell output में सैकड़ों हज़ार lines लिख दीं और 500MB की ipynb file बना दी, फिर Claude उसे कई बार पढ़ने की कोशिश करता रहा और पूरी context limit उड़ा दी। इसका समाधान यह था कि CLI analysis scripts और research results storage folders के साथ बेहतर work structure तय किया जाए, लेकिन operator होने के नाते planning और design मुझे ही करनी पड़ी। जो लोग हर महीने $10k tokens खर्च करते हैं, उन्हें देखकर यही लगता है कि वे Claude Code नाम की महंगी हथौड़ी से आलस में हर समस्या पर प्रहार कर रहे हैं। जैसे कि Claude से रोज़ सारे emails पढ़वाना — जबकि ज़्यादा समझदारी वाला समाधान यह होगा कि पहले email body HTML से noise हटा दिया जाए
  • यह काफी हद तक इस पर निर्भर करता है कि आप किस repository पर काम कर रहे हैं। अगर वह बहुत बड़ी है, और खासकर उसमें custom framework और API docs जैसे ढेर सारे tools का reference लेना पड़ता है, तो बड़ी context window की ज़रूरत पड़ती है और tokens बहुत तेज़ी से खत्म होते हैं
    दूसरी ओर, अगर repo छोटी है या model जिन सामान्य frameworks पर trained है वही इस्तेमाल हो रहे हैं, तो छोटी context window से भी बहुत काम हो जाता है और token usage भी बहुत कम रहता है
  • cost की तरह quota वाली बात भी मेरी समझ से बाहर है। मेरे पास 200 euro वाला ChatGPT plan है, तो शायद वही highest quota होगा, लेकिन सबसे महंगे model, highest reasoning और fast mode के साथ दिन भर लगभग सिर्फ agent programming करने पर भी limit के आसपास नहीं पहुँचता
    coding agents इस्तेमाल शुरू करने के बाद मैं limit के करीब सिर्फ एक बार पहुँचा, जब cross-platform development एक ही समय पर 3 computers पर उन्हीं settings के साथ कर रहा था, और तब भी बस weekly limit के करीब गया था। आम तौर पर usage लगभग 20% limit तक जाता है, लेकिन उससे नीचे शायद ही कभी जाता है। मज़े के लिए बहुत prompts और queries भी फेंकता रहता हूँ, फिर भी समझ नहीं आता कि लोग इससे ज़्यादा कैसे खर्च कर लेते हैं

• मुझे पता है कि मैं अभी AI को जवाब दे रहा हूँ, लेकिन “क्या कंपनी इस स्तर की productivity को scale पर afford कर सकती है, यह समझने की कोशिश कर रही है” — यह अजीब लगता है। अगर यह सचमुच productive है, तो revenue बढ़ेगा, और फिर afford कर पाने का सवाल ही नहीं उठना चाहिए

  • सही बात। productivity की परिभाषा ही है कि वह कुछ पैदा करे, और बेहतर हो तो कुछ valuable पैदा करे। देखना यह चाहिए कि chatbot पर आने वाली अतिरिक्त लागत उतनी value दे भी रही है या नहीं। सवाल यह है कि क्या Uber इस भारी budget overrun की वजह से नाटकीय रूप से ज़्यादा efficient और effective हुआ, या लोगों को बस वही काम करने का एक चमकदार और महंगा नया तरीका दे दिया गया
  • revenue बढ़ा है। Meta की हाल की earnings देखें तो इस economy में भी revenue +33% है। afford कर पाना मुद्दा नहीं है, और Meta जैसी कंपनियाँ इसीलिए engineer के token पर दिन का $1k खर्च होने पर बहुत परेशान नहीं होतीं। employee per revenue के मुकाबले यह उतनी बड़ी रकम नहीं है
  • developers जो हर बदलाव करते हैं, वे revenue नहीं बढ़ाते, और जो बदलाव revenue बढ़ाते हैं उनमें भी अक्सर time lag होता है
  • अगर सामने वाली दलील को सबसे अच्छे रूप में देखें, तो इसका counterexample यह हो सकता है कि competitors भी वही tools इस्तेमाल करके वही productivity gains पा रहे हों
  • सही तरीके से इस्तेमाल करो तो यह सच में बेहद productive है। यहाँ तक कि अगले साल तक ऐसे AI models कितने समझदार हो जाएँगे, यह सोचकर चिंता होती है

• “अब Uber के 95% engineers हर महीने AI tools इस्तेमाल कर रहे हैं, और committed code का 70% AI से आता है” — यह तो अपेक्षित ही है। अगर AI tool usage को performance review में शामिल कर दिया जाए, तो यही होगा

  • यह देखकर हैरानी होती है कि non-developers जब developers पर KPI थोपते हैं, तो लोग उसे कितनी आसानी से game कर सकते हैं — इसे कितनी कम आंका जाता है। AI हो, या pull request/line count, बात एक ही है
  • जिस क्षण KPI “क्या ship किया” से बदलकर “AI कितना इस्तेमाल किया” हो जाता है, budget blowout उसके पीछे-पीछे आना ही है। लोग numbers hit करने की कोशिश करेंगे
  • जब managers और VPs सब कहें कि “AI इस्तेमाल नहीं किया तो यहाँ काम नहीं कर पाओगे,” तो लोग इस्तेमाल करेंगे ही
  • मुझे यह आलोचना पूरी तरह समझ नहीं आती। क्या नौकरी का मतलब मूलतः वही काम करना नहीं है जो कंपनी चाहती है और जिसे कंपनी productive मानती है? और क्या लोग यह मानकर चल रहे हैं कि AI-generated code पूरा का पूरा बेकार है?

• “कंपनी इस स्तर की productivity को scale पर afford कर सकती है या नहीं, यह समझना” — यह हिस्सा मुझे समझ नहीं आता। budget खर्च हो चुका है और 4 months of data भी है; अब असली सवाल यह है कि दिखाने लायक result क्या है
  मैं न AI-hater हूँ, न luddite, और $200 Max plan इस्तेमाल करता हूँ। लेकिन क्या Uber ने यह tool सबके लिए खोल दिया, सबको इस्तेमाल करने को कहा, और जब यह काम करने लगा तो अब समझ नहीं आ रहा कि क्या हो गया? यह अलग बात है कि कोई तय करे कि AI cost के मुकाबले पर्याप्त productive नहीं है। कभी-कभी तो लगता है, क्या अब बनाने के लिए अगली चीज़ ही ख़त्म हो गई है?

  • personal Max और Teams plans, Enterprise के API metered pricing के मुकाबले हैरतअंगेज़ deal हैं। शायद उन्हें Enterprise features की ज़रूरत रही होगी। नहीं तो users से कह देते कि $200 Max subscription expense claim कर लो। corporations आखिर corporations की तरह ही व्यवहार करती हैं
  • अभी शायद बाहर से कुछ दिख ही नहीं रहा होगा। क्योंकि जो बड़े बदलाव external users तक दिखते हैं, उन्हें व्यापक rollout तक पहुँचने में बहुत ज़्यादा समय लगता है। अंदरूनी तौर पर कई features शायद तेज़ी से आगे बढ़े होंगे
    Salesforce में भी मैंने ऐसा बदलाव देखा है जहाँ कुछ हफ्तों का काम कुछ दिनों में होता दिखता है। यह तुरंत पैसे में convert नहीं होता, लेकिन पैसे कमाने की potential ज़रूर बढ़ाता है
  • यह पूछना भी ठीक है कि Uber अगला क्या बनाएगा। ride-hailing platform है और चल भी रहा है। food, grocery, और “जो कुछ भी car में जा सकता है” delivery तक expansion भी हो चुका है। जहाँ कोई इंसान car चला रहा है, उस domain में अब और क्या बचता है, समझ नहीं आता
  • समझ नहीं आता कि जब spend controls मौजूद थे तो hard cap क्यों नहीं लगाई गई। engineers से उस spend को justify करने को कहा जा सकता था
    पूछा जाना चाहिए कि इतने tokens की ज़रूरत क्यों है, और बदले में क्या मिल रहा है। अगर यह AWS होता, तो सब उँगली उठाकर कहते, “महीने का spend देखा ही नहीं?”
  • लगता है AI discussion अब उस मुकाम पर पहुँच गया है जहाँ किसी भी आलोचना को विधर्म न समझा जाए, इसके लिए पहले कहना पड़ता है, “मैं भी इस पंथ का ही सदस्य हूँ, अविश्वासी नहीं”

• ऐसे लेख आते ही अचानक बहुत लोग सोचने लगते हैं कि developer productivity को मापना आसान है। यह सही है कि productivity revenue या cost savings में बदल सकती है, और revenue measurable है, लेकिन बात इतनी simple नहीं है
  आज पैसा खर्च करके ऐसे features बनाए जाते हैं जो future revenue लाएँगे, इसलिए आज cost spike हो सकती है जबकि revenue अभी न दिखे। अगर AI की वजह से feature आज पूरा हुआ, तो इससे तुरंत यह नहीं कहा जा सकता कि AI productive है या नहीं; यह भी estimate करना पड़ेगा कि AI के बिना कितना होता और revenue तब कैसा होता। business अक्सर Red Queen race जैसा होता है — अगर आप improve नहीं करते, तो competitors से पीछे छूटकर revenue भी खो सकते हैं। AI usage में ज़रूरी काम और “अब आसान है तो चलो यह भी आज़मा लेते हैं” वाला काम दोनों मिला-जुला होने की संभावना है, इसलिए असली productivity gain मापने के लिए पहले वाले को बनाए रखना और दूसरे वाले से बचना सीखना होगा। यह AI के पक्ष-विपक्ष की बात नहीं, बस इतना कि “अगर productive है तो measurable होगा” जैसी आलसी बात नहीं करनी चाहिए

  • मुझे तो मुख्य consensus उल्टा यही लगता है कि developer productivity measurement बहुत कठिन है। जब भी आप कोई metric बनाते हो, वही metric जल्दी ही target बन जाता है, और फिर चाहे वह शुरू में कितना भी robust क्यों न रहा हो, अर्थहीन हो जाता है
    factory workers के अलावा बाकी लोगों की productivity मापना आसान है — यह विचार लोगों को आया कहाँ से, समझ नहीं आता
  • नहीं लगता कि नए features या बेहतर software से Uber का revenue/profit बहुत बढ़ जाएगा
  • विकल्प सिर्फ zero productivity और some productivity का नहीं है; negative productivity भी हो सकती है। Claude Code के साथ अपने अनुभव के आधार पर, मुझे शक है कि organization में इतने tokens झोंकना सिर्फ unproductive नहीं, बल्कि सक्रिय रूप से harmful भी हो सकता है
  • छोटी productivity changes मापना कठिन है, लेकिन बड़े jumps तो साफ दिख जाते। अगर AI productivity को प्रभावित कर रहा है, तो शायद असर बहुत मामूली है
  • अगर 10x productivity होती, तो उसे indirect तरीके से भी मापा जा सकता था — बल्कि उससे बचना मुश्किल होता। शुरुआती दावे साफ़ तौर पर गलत थे; असली research question यह है कि क्या यह 1.0x से बड़ा है
    उस हिस्से पर मैं सहमत हूँ कि इसे मापना बेहद मुश्किल है। लेकिन इस cost को देखते हुए इसका जवाब देना ज़रूरी होना चाहिए, और multiplier इतना होना चाहिए कि लागत justify हो सके

• [1] के मुताबिक Uber engineering organization में लगभग 5,500 लोग हैं। अगर spend range का midpoint $1,250 मानें, तो engineering AI spend लगभग $6.8M बनता है, और range $2.75M~$12M होती है। लेख में R&D spend $3.4B बताया गया है
  यानी AI spend, R&D spend का बहुत बड़ा हिस्सा नहीं है। 4 महीने के हिसाब से लगभग 0.3%, annualized करें तो लगभग 1%। अगर plan में शामिल न हो तो budget के हिसाब से यह छोटी रकम नहीं है, लेकिन context में बहुत बड़ी भी नहीं। असली सवाल वही है: इस पैसे से मिला क्या? लेख दावा करता है कि code commits का 70% AI-generated है, तो शायद वह review और testing पास कर चुका होगा। क्या feature velocity बढ़ी, quality issues घटे, या कोई और फायदा हुआ — यही मायने रखता है। अफ़सोस, लेख spend increase के अलावा outcomes पर कुछ नहीं कहता। हो सकता है 4 महीने benefits evaluate करने के लिए बहुत कम समय हो। हालाँकि agile दुनिया में कुछ लोग इससे असहमत होंगे। [1] https://www.unifygtm.com/insights-headcount/uber

  • असली source https://www.theinformation.com/newsletters/applied-ai/uber-c... में लिखा है कि “backend systems के actual live code updates में लगभग 11% अब ऐसे AI agents द्वारा लिखे जा रहे हैं जो मुख्यतः Claude Code से बनाए गए हैं, जबकि 3 महीने पहले यह 1% से भी कम था”
    और यह भी कि “कंपनी ने अपने software budget या AI coding tools spend के सटीक आँकड़े सार्वजनिक नहीं किए”
  • इस लेख की हर बात पूरी तरह fake लगती है। numbers मेल नहीं खाते, reported information से भी नहीं, और यह बस मनगढ़ंत लगता है

• bootstrap कर रहे व्यक्ति के तौर पर अक्सर बड़ी कंपनियों के engineers से ईर्ष्या होती है, लेकिन साथ ही यह चिंता भी होती है कि incentives टूट चुके हैं
  अगर मैं Uber engineer होता, तो छोटे से बदलाव के लिए भी prompt में gpt 5.5 pro @ very high thinking + fast mode न लिखने की कोई वजह नहीं होती। सबसे powerful, और इसलिए सबसे महंगा model, न इस्तेमाल करने की कोई incentive नहीं है। image→HTML conversion test के लिए मैंने एक ऐसा prompt चलाया था और एक single prompt का ही $40 लगा। अगर अपनी जेब से देना होता, तो मैं लगभग कभी यह setting इस्तेमाल नहीं करता, लेकिन बड़ी कंपनी में जब कोई और pay कर रहा हो, तो इसे बार-बार चलाने का मन होगा। output वाकई बेहतर था। engineer का आकलन इस बात पर होता है कि उसने क्या deliver किया, इस पर नहीं कि उस process की cost कितनी थी। सस्ता करने के तरीके हैं, लेकिन engineer के पास ऐसा करने की incentive नहीं है

  • software engineers महंगे होते हैं। median salary $133k है, और इसमें health insurance, payroll taxes वगैरह भी शामिल नहीं हैं। अगर $40 के LLM credits से 1 घंटे का development time बचता है, तो हिसाब से यह उसे न इस्तेमाल करने की तुलना में $26.50 सस्ता पड़ता है
    क्या असल दुनिया में ऐसा होता है, इस पर मैं अभी आश्वस्त नहीं हूँ, लेकिन सिद्धांत यही है। LLM cost कम करने की कोशिश भी दोधारी तलवार है। क्योंकि developer ने जितनी LLM cost बचाई, उससे ज़्यादा कंपनी उस developer पर खर्च करती है। अगर आप पूरा दिन लगाकर प्रति call $1 कम करते हैं, तो सिर्फ salary cost वसूलने में लगभग 2 साल लग जाएँगे। ऊपर से LLM इतनी तेज़ी से बदल रहे हैं कि भरोसा नहीं होता कि वह solution 2 साल में obsolete नहीं होगा। 2 साल बाद tool calls होंगे भी या नहीं, reasoning mode रहेगा भी या नहीं — शायद frontier providers खुद भी नहीं जानते
  • कंपनी पहले यह देखना चाह सकती है कि काम कितनी तेजी से scale हो सकता है, और बाद में efficiency के लिए उसे trim करना चाह सकती है
  • image→HTML काफ़ी complex काम है। यह लगभग frontend developer का काम है, और $40 में उनका 1 घंटा भी नहीं आता

• जैसे-जैसे executives यह मानने लगते हैं कि software engineering को agents से replace किया जा सकता है, मुझे हैरानी होती है कि कहीं वे average software engineer के बारे में अवास्तविक धारणाओं पर आधारित फैसले तो नहीं ले रहे
  एक ओर, इसमें “जितना डालोगे उतना निकलेगा” वाली बात है। कोई तेज़ CTO agent से होने वाले काम को देखकर बहुत उत्साहित हो सकता है और यह भ्रम पाल सकता है कि सभी engineers भी ऐसा ही कर पाएँगे। वास्तव में organization का average engineer शायद इतना creative भी न हो कि सोचे कहाँ काम कम किया जा सकता है। इसलिए agent usage को अनिवार्य करने से productivity बढ़े बिना AI cost ही बढ़ सकती है। दूसरी ओर, AI इस्तेमाल करने पर दो gaps और साफ़ दिखते हैं: agent को क्या करने को कहा जाएगा, और QA/review cycle को कैसे संभाला जाएगा। कई organizations में product लोग इतने technical नहीं होते कि LLM के लिए usable detailed specs या plans बना सकें, और assembly-line जैसे developers spec बनाना नहीं, सिर्फ implementation करना चाहते हैं। अगर agents इस्तेमाल करने वाले developers से ही implementation की उम्मीद की जाए, तो उल्टा ऐसे idle लोग बढ़ सकते हैं जो बस काम आने का इंतज़ार करते रहें। मौजूदा developers की speed और quality बढ़ाने वाले optional LLM adoption के मैं पक्ष में हूँ, लेकिन “पूरी organization को reorg कर दो” वाला रुझान खासकर small और mid-sized कंपनियों के लिए काफ़ी जोखिमभरा है

  • उससे भी बढ़कर, AI एक force amplifier है, और उसे इससे कोई फर्क नहीं पड़ता कि वह force positive है या negative। software engineering principles खराब रखने वाला व्यक्ति अगर AI इस्तेमाल करे, तो वह बहुत जल्दी पूरा mess बना सकता है
  • point 2 से जुड़ी बात: हमारी कंपनी developers को product mindset रखने और सिर्फ gears न बने रहने के लिए काफ़ी push करती है
    हो सकता है मैं पक्षपाती हूँ क्योंकि मेरा खुद का product mindset दूसरे developers से मज़बूत है, लेकिन मुझे लगता है कि ऐसे लोग agents के साथ ज़्यादा productive होने की अच्छी स्थिति में होते हैं। वे implementation के लिए enough technical भी होते हैं और यह भी समझते हैं कि क्या implement होना चाहिए। मुझे उम्मीद है कि दूसरी कंपनियाँ भी इसी दिशा में जाएँगी
  • आखिरकार बात बड़े पैमाने पर layoffs की ही हो रही है

• समझ नहीं आता Uber आखिर develop क्या कर रहा है। app है, vehicle dispatch backend है, और दोनों ठीक-ठाक चलते हैं। फिर इतना खर्च क्यों हो रहा है, यह सवाल है
  autonomous driving तो उन्होंने छोड़ दी है, तो वह कारण नहीं हो सकता

  • यह सचमुच कम आंका गया सवाल है। यह दिखाता है कि आधुनिक tech companies इतने सारे resources के साथ आखिर करती क्या हैं। Elon ने Twitter team का बड़ा हिस्सा कम कर दिया था, और शुरुआती भयानक trial-and-error के बाद भी क्या यह लगभग ठीक-ठाक नहीं चल रहा था, जबकि headcount 80% कम था?
  • काश “दोनों ठीक-ठाक चलते हैं” सच होता, लेकिन ऐसा नहीं है। matching algorithm optimization की वजह से user experience इतना खराब हो गया है कि अब मैं नियमित रूप से Lyft इस्तेमाल करता हूँ
  • “X तो बस Y है, फिर यह इतना complex क्यों है?” — इस तरह के comments HN पर सबसे घिसे-पिटे लगते हैं। जिस भी बड़ी कंपनी से लोग चिढ़ते हैं, उसके हर लेख पर ऐसा लिख देना आलसी और पढ़ने में उबाऊ है

• API tokens में, खासकर 1M context इस्तेमाल करते समय, अगर पुराने context को ध्यान से clear न करो तो एक session में सैकड़ों dollars उड़ाना बहुत आसान है
  वहीं subscriptions उसी तरह का usage महीने के कुछ सौ dollars में allow कर देती हैं। लगता है Anthropic या तो API users से बेहद महँगा वसूल रहा है, या subscriptions को भारी subsidy दे रहा है, या फिर दोनों

  • https://www.forbes.com/sites/annatong/2026/03/05/cursor-goes...
    “Cursor ने पिछले साल अनुमान लगाया था कि $200 monthly Claude Code subscription से अधिकतम $2,000 worth की computing इस्तेमाल की जा सकती है, जो Anthropic की बड़ी subsidy की ओर इशारा करता है। अब यह subsidy और भी आक्रामक दिखती है: $200 plan से लगभग $5,000 worth की computing consume की जा सकती है”
  • Anthropic का business model काफ़ी “दिलचस्प” है। जब तक employees 150 या उससे कम हों, तब तक subscription pricing मिलती है; लेकिन 151 होते ही पूरी company रातोंरात API pricing पर चली जाती है और total bill तुरंत कई गुना बढ़ जाता है
    मतलब पहले लोगों को सस्ते tokens का आदी बनाओ, और scale पर पहुँचते ही वसूली करो। Uber को list price से discount ज़रूर मिला होगा, लेकिन वह 150-seat subscription pricing के आसपास नहीं होगा
  • मैंने pricing देखी थी, लेकिन Team से Enterprise पर jump करना justify नहीं कर पाया। Enterprise पर जाते ही monthly subscription model पूरी तरह गायब हो जाता है और cost control की क्षमता खो जाती है
    per-user caps लगाए जा सकते हैं, लेकिन अगर monthly rolling cap न हो तो आख़िरकार टीम के किसी सदस्य से कहना पड़ सकता है, “इस महीने के बाकी दिनों के लिए AI बंद।” मौजूदा structure में यह मुझे काफ़ी risky deal लगती है