Live data from Hacker News

Uber torches 2026 AI budget on Claude Code in four months

briefs.co

281–290 of 498 posts

Re: Uber torches 2026 AI budget on Claude Code in four months

#281
post #204

Earlier quoted context omitted.

First: There's the obvious "If the company is letting me do it, I'll be wasteful." This includes not clearing/compacting the context often. Opus now has a 1M context window, and quality is good to at least 200K. So each query is burning a lot of tokens until you clear/compact. People have already mentioned the size/complexity of the codebase. I'm new to my team and the codebase isn't huge, but it's large enough that…

> This includes not clearing/compacting the context often. Opus now has a 1M context window, and quality is good to at least 200K. So each query is burning a lot of tokens until you clear/compact. I see this repeated by others, including coworkers. It completely ignores caching. Caching itself is complicated, but the "longer context window = more expensive" is not 100% true and you are hampering yourself if you're no…

You still pay for cache hits and refreshes, but the cost is lower.

The default Claude cache expires in 5 minutes. If you take a short break to review the code, talk to someone, or do anything other than continuously interact with the session it's going to get evicted and start over.

You can opt in to a 1-hour cache at a higher rate https://platform.claude.com/docs/en/build-with-claude/prompt...

Also anecdotally, caching has just been broken at times for me. I've had active conversations where turns less than 5 minutes apart were consuming so much quota that I doubt anything was being billed at the cache rate.

Re: Uber torches 2026 AI budget on Claude Code in four months

#282

Earlier quoted context omitted.

Begs the question if we should move on to minimal microservices so that whole project lives in context of llm. I hardly have to do anything when I'm working with small project with llm.

I've done the opposite, moving multiple tightly coupled repos into a single monorepo. Saves the step of the llm realizing there's a bigger context, finding the repo, then also scanning/searching it. Especially for fixes that are simply one line each in two repos.

I'm a fan of the monorepo in general, even before LLMs. If using git it leverages git's best feature IMO, the commit as a snapshot of the entire repo. I've worked on so many projects where tightly coupled things are split across repos because it's thought of as a best practice, and it just makes it more difficult to figure out what code you are running.

Re: Uber torches 2026 AI budget on Claude Code in four months

#283
It's wild that the article frames this as

> what started as an experiment in productivity became a runaway success

and

> figuring out if the company can afford this level of productivity at scale

It seems like they're equating "developers are spending a ton of money on this" with "this is creating a ton of value".

I'm not saying that AI tools aren't valuable, but the article doesn't question this equivalence at all.

Re: Uber torches 2026 AI budget on Claude Code in four months

#284

> 95% of Uber engineers now use AI tools monthly with 70% of committed code originating from AI. Well, that’s to be expected when using AI tools becomes relevant in your performance evaluation.

It's actually incredible the extent to which non devs imposing KPIs on devs underestimate how badly this will get gamed, whether it's AIs, PR/line counting or whatever.

Exactly. At Cerebras I know of several people who burn tokens on completely USELESS tasks (randomly changing pixels in an image) just to keep them high up on the token leaderboard.

I suspect the other tokenboard leaders are doing the same. They made the metric "token usage" (which is just a proxy for LOC) so that's what they're gonna get.

Re: Uber torches 2026 AI budget on Claude Code in four months

#285

Earlier quoted context omitted.

> have claude read all your emails every day But that is exactly what it is sold to people to do as a panacea: consume all the data, produce insights. Nobody is being instructed to be judicious. Everyone is being instructed to use it as much as possible for all problem areas.

If you make 500k and aren't spending 250k in token, you should get fired.

I can't even tell whether this comment is serious or not.

Re: Uber torches 2026 AI budget on Claude Code in four months

#286

Earlier quoted context omitted.

> If it was actually productive, then the revenue would increase and affordability wouldn't be a question. Revenue has increased. Have you seen Meta's latest earnings? +33% revenue - in this economy. Affordability is not a question. There is a reason companies like Meta have no issue with their engineers spending $1k/day on tokens. It's just not that much compared to how much they make per employee.

How can that be attributed to any code an LLM wrote? >$8 billion of net income was the result of a tax benefit the company realized in the first quarter of the year. So exactly how much of their revenue is because of any code LLMs wrote vs. just structural tail winds?

You can always say "it's not because of LLMs", that's nearly unfalsifiable.

But if all of your peers are saying LLMs are more productive, if you're building things faster than ever before, the macro picture speaks for itself.

Re: Uber torches 2026 AI budget on Claude Code in four months

#287

Earlier quoted context omitted.

The problem with HN is that everyone here thinks like an engineer, not like a business owner. $10k a month on tokens is just not that much when you're already making $2M per engineer. If their productivity has increased even 10% then the spend was well worth it. Case in point, Meta made 33% more revenue this earnings report. Now you can nitpick and ask for attribution down to the dollar, but macro trends speak for th…

Go look up a multi-year chart of their revenue and find the inflection point where the AI made it go up faster (there isn't). In fact revenue growth used to be higher pre-2023.

They were also a lot smaller pre-2023, 33% growth for a company of their size is simply insane. It is entirely likely that 33% simply wouldn't have happened without AI.

Re: Uber torches 2026 AI budget on Claude Code in four months

#288

Earlier quoted context omitted.

> If it was actually productive, then the revenue would increase and affordability wouldn't be a question. Revenue has increased. Have you seen Meta's latest earnings? +33% revenue - in this economy. Affordability is not a question. There is a reason companies like Meta have no issue with their engineers spending $1k/day on tokens. It's just not that much compared to how much they make per employee.

How can that be attributed to any code an LLM wrote? >$8 billion of net income was the result of a tax benefit the company realized in the first quarter of the year. So exactly how much of their revenue is because of any code LLMs wrote vs. just structural tail winds?

I agree that you can't draw any conclusions about AI, but their revenue increased by 33% percent. That's just straight income before any taxes or costs are applied.

Re: Uber torches 2026 AI budget on Claude Code in four months

#289
post #283

It's wild that the article frames this as > what started as an experiment in productivity became a runaway success and > figuring out if the company can afford this level of productivity at scale It seems like they're equating "developers are spending a ton of money on this" with "this is creating a ton of value". I'm not saying that AI tools aren't valuable, but the article doesn't question this equivalence at all.

Bizarrely I feel like that reflects how a lot of tech leadership are viewing it? I can't explain this behavior but this is the first time I've seen this inversion: leaders believing money spent on something is itself value. I have dev friends who are legitimately under an edict to burn more tokens! It's freakish.

Re: Uber torches 2026 AI budget on Claude Code in four months

#290
post #78

I love how these articles drop, and all of a sudden HN is filled with people who think engineering productivity is simple to measure. Yes, productivity implies revenue (or cost reduction), and revenue is measurable. However: 1. You spend money today to build features that drive revenue in the future, so when expenses go up rapidly today, you don’t yet have the revenue to measure. 2. It’s inherently a counterfactual c…

> HN is filled with people who think engineering productivity is simple to measure. I think the prevailing (correct) consensus is that developer productivity is actually very hard to measure, and every time it is attempted the measure is immediately made a target making the whole thing pointless even if it had been a solid measurement- which it wasn't. IDK where you're getting the idea here that measuring productivit…

Is it easy to measure a factory worker's productivity? It would seem surprising and interesting if every job's productivity is hard to measure except for one particular kind.
Post reply on HN