The AI Coding Bill Is a Headcount Problem in Disguise | Abhishek Shankar's Blog

&times;<br>Posts<br>Ideas<br>The Map<br>About<br>Subscribe

The math breaks because the headcount never moves<br>The cleanest articulation of the problem came not from Uber but from a chip company, which makes it hard to dismiss as the complaint of a firm that planned poorly. Bryan Catanzaro, Nvidia's VP of applied deep learning, told Axios in April that for his team, the cost of compute is now far beyond the cost of the employees using it. Read that twice. The marginal cost of the tool has exceeded the salary of the person operating the tool — and the person remains on the payroll, drawing that salary, while the tool bill runs alongside it.<br>This is the structural fact the dashboards obscure, and it is worth stating in its barest form. Enterprises are adding usage-based AI expenses on top of fixed payrolls without cutting headcount, creating a cost structure that only grows. Traditional enterprise software was a flat per-seat line you could plan a year around: a thousand engineers times a known license fee equals a number that doesn't move. Agentic coding tools are metered by consumption, and the consumption is not modest. Agentic workflows consume five to thirty times more tokens per task than standard chatbot queries, which means the unit of billing has quietly decoupled from anything a finance team previously knew how to forecast.<br>The promise that justified the spend, the slide in every internal deck that got these rollouts approved, was substitution. AI would do work that people used to do, and therefore the AI line item would be offset — eventually, partially, somehow — by a labor line item that shrank. What companies actually purchased was augmentation: a powerful tool layered on top of the existing workforce, billed by the token, with the full labor cost intact and undiminished. When the savings thesis rests on headcount reduction and the headcount does not reduce, the AI bill is not a substitution. It is pure addition. You are paying for the engineers and paying, sometimes more, for the tool the engineers use.<br>This is why the problem is not specific to Uber and not solved by Uber-specific fixes. The mismatch is built into the deployment model, not the spreadsheet.<br>Gamifying usage was the accelerant, not the engine<br>Uber did make the structural problem worse with a specific and now-infamous decision, and it deserves to be named because it is instructive about incentives, not because it is the root cause. Engineers were ranked on internal leaderboards by how much they used the tool — the more tokens consumed, the higher the score, which gave engineers every reason to use Claude Code aggressively and no reason to hold back. The dashboard rewarded raw consumption as a proxy for engagement and progress, so an engineer who used less of the tool looked, on the only metric leadership was watching, like an engineer who was falling behind.<br>But the leaderboard is a story about velocity, not direction. Strip it away entirely and the cost curve still bends upward, because the underlying incentive is laminated into the tooling itself, independent of any gamification a manager bolts on. The tools became so valuable that engineers couldn't stop using them despite the skyrocketing costs. The variance between engineers is enormous and has nothing to do with effort: a developer running basic autocomplete spends almost nothing, while one orchestrating parallel agents across a large codebase runs up thousands of dollars in the same window. Uber's average per-engineer spend ran between $150 and $250 a month, while heavy users hit $500 to $2,000. The leaderboard's effect was to push the whole distribution toward the heavy-user tail faster than it would have drifted on its own. It accelerated the spend. It did not create the range, and removing it would not have flattened the curve.<br>The deeper concession, the one that should keep boards awake, came from Uber's COO after he had talked to his senior engineering leaders. Andrew Macdonald said it is "very hard to draw a line" between AI-assisted code commits and shipping more useful consumer-facing features. Higher token consumption, he found, was not translating into a proportional increase in product value. The meter ran on inputs — tokens, commits, lines of code — while whatever value existed lived in outputs that nobody at the company could cleanly attribute to the spend. That gap between what you can measure and what you are paying for is the second half of the problem, and it is where the productivity data turns genuinely damning.<br>The productivity gains are real, individual, and organizationally invisible<br>The standard rebuttal to all of this is that the tools pay for themselves through productivity, so the rising bill is just the cost of a faster engineering organization. The telemetry does not support that rebuttal, and the way it fails to support it is specific and important.<br>The productivity gains at the...