AI tools are priced like enterprise software. They may be replacing it too.

According to The Information, Uber's CTO Praveen Neppalli Naga disclosed in April that the company had already spent its 2026 Claude Code budget, four months into the year. By June, Bloomberg had confirmed that Uber's response was a US$1,500 monthly cap per AI coding tool per employee, applied separately to each tool.

At two tools per engineer (say Cursor and Claude Code), Bloomberg's US$1,500 figure works out to US$36,000 a year per person at the cap. According to salary data from levels.fyi, Uber's median software engineer earns US$330,000 in total compensation. That ceiling is roughly 11% of median compensation. Reporting by Briefs put monthly API costs per engineer at between US$500 and US$2,000 before the cap was introduced, with 95% of engineers using AI tools monthly and 70% of committed code originating from AI.

Uber set the cap at a defined amount per employee, per tool, per year. Enterprise software licences typically work the same way. A typical team software subscription at US$30 a month per seat does not require the same approval process. At US$36,000 a year per person across two tools, the spend is in the range that would typically require formal procurement approval in most organisations.

Cursor, for example, offers an individual monthly subscription. Enterprise access through API billing has no equivalent ceiling. When active developers use API-billed access heavily, they can push costs up quickly. According to one commenter in the Hacker News thread, most engineering teams had no per-developer breakdown, with spend included in a consolidated cloud bill and no per-person visibility. The engineer using the tool gets the benefit but the organisation pays the bill. Commentary on the story described that behaviour as tokenmaxxing, where engineers consume as much inference as possible because they pay nothing for their own usage. The organisation can use the cap to track cost per employee.

The Hacker News thread on the Bloomberg story attracted over 500 comments and the recurring question was what Uber had actually built with all that spend. A commenter described "a deafening silence when it comes to actual, demonstrated efficacy." Macdonald, speaking on the Rapid Response podcast in May, addressed the same question. He described the CTO's disclosure as a "head-exploding moment" that forced internal discussions about token consumption and the trade-offs linked to that spend, including on headcount. He said it was "very hard to draw a line between" the usage numbers and useful consumer features. Usage metrics were in place but outcome metrics were not, so engineers may have been getting useful results from the tools even though no direct connection had been established. Simon Willison, writing on his weblog in June, suggested the 2026 budget may simply have been under-estimated in 2025, rather than proof the spend was unjustified. Whether the spend was justified remains unclear.

If 70% of committed code originates from AI, the tools appear to be part of day-to-day engineering work rather than a separate experiment. Some AI coding tool functions may overlap with tools already in the development stack. Whether that overlap creates room to reduce other tooling costs is a separate question and one a PM could include in the cost review.

In most organisations, engineering typically owns tooling decisions and the PM typically owns cost baselines. The Uber story is specifically about developer tooling, but the same questions apply wherever AI tools are used on a project. For a 2026 project where developers, analysts, testers or others are using AI tools, three questions are worth checking. Is AI tool spend treated as a resource cost in the project budget, scoped and baselined like labour or software licences? Does the business case state what productivity improvement the tools are expected to deliver, and on what basis? Macdonald's problem was not that he lacked usage metrics but that he could not connect tool spend to project outcomes. If the project is partly a productivity pilot, that should appear in the business case as a secondary outcome. And which existing tools in the stack might the organisation reduce or replace? Tools worth examining for potential overlap include IDE extensions, code review tooling, QA automation, requirements and documentation tools and developer productivity platforms.