2026-11-03
November 3, 2026
Token spend is the loudest number in your engineering budget, and the least useful one to manage first.
Engineering leaders have spent the last six months arguing about the wrong variable. The Pragmatic Engineer's Gergely Orosz reported in May that some mid-sized and large companies were starting to cap agent spend with per-engineer monthly budgets, and the Pulse's "tokenmaxxing" coverage described engineers burning tokens to hit internal usage targets. Both stories treat tokens as the thing to ration or to maximize. Neither asks where the output of all those tokens goes next.
The most useful data point of the year comes from Jellyfish's H1 2026 report on AI in software engineering. At the 90th percentile, the share of pull requests opened by autonomous agents rose from about 2% a year earlier to 35% by April. The median stayed near 2%. Spend per user at the median company rose about 16x in ten months. And the report finds steeply diminishing returns: the first million tokens yield roughly 11 merged PRs, later increments yield far less, and one quarter was slightly negative. That is not a cost curve. It is a signature of a system with a bottleneck downstream of the thing you are paying for.
Eliyahu Goldratt spent a career on exactly this situation. Add capacity anywhere except the constraint and you get more inventory, not more throughput. Agents made code generation cheap. They did not make review, integration, design judgment, or release confidence cheap. So the interesting question for a TPM or a CTO is not "how many tokens per engineer?" It is "what is the constraint now, and are we feeding it or flooding it?"
Start with what the data actually says, because it is more interesting than the headlines. Jellyfish found that 84% of active users run only one or two agents at a time, and attributes the ceiling mainly to human attention. In the longest sessions, lightly supervised runs produced about 11x the net lines of code of heavily supervised ones. Read those together: the humans are the limiter, and the more you take them out of the loop the more raw output you get. Raw output is precisely what you do not want to optimize.
Now add the spend side. Jellyfish reports that heavy token spend pays off when a merged PR is worth roughly $69 to $100 or more, and that at $15 per PR the heaviest-spend quintile has negative net value. Cache reads and writes make up about 83% of the bill. In other words, most of what you pay for is agents re-reading context, which is a function of how legible your codebase and harness are, not how clever your engineers are. The same report finds that engineers who invest heavily in context gain about 2.3 merged PRs per week versus about 0.7 for light investors, and that AI returns about 4x in centralized or balanced codebases but only 0.9x in the most fragmented ones.
Three governance moves follow, and none of them is a per-seat cap.
First, measure throughput at the constraint, not activity at the source. Merged PRs per week that survive to production, review latency, and queue age tell you more than tokens consumed. If PR volume at your P90 teams tripled and reviewer capacity did not, you did not gain throughput. You built a queue.
Second, price work by value, not by seat. DX's survey of engineering leaders found that 86% are uncertain which tools deliver the most benefit and 40% lack the adoption and impact data to build an ROI case. Leaders also told DX they want limits by team or job title, which most usage-based enterprise plans do not yet offer. Until they do, the lever you control is the work itself: route cheap, high-volume, well-specified tasks (test scaffolding, migrations, dependency bumps) to agents with budgets sized to the task's value, and keep ambiguous design work human-led.
Third, treat context as infrastructure. If cache traffic is most of the bill and context investment is the strongest predictor of payoff, then documentation, module boundaries, and repo conventions are a cost-control program. A TPM who gets a platform team to consolidate a fragmented repo layout may do more for AI ROI than any procurement negotiation.
The uncomfortable implication for leaders is that "adopt AI faster" and "spend less on AI" are the same bad framing. Both ignore flow. Run the system, find the choke point, and spend where it unblocks work.
Try this week. Pull the last 30 days of merged PRs for one team that uses agents heavily. Plot median time from PR opened to PR merged, and count PRs waiting on review longer than two days. If that queue is growing while agent-authored PRs rise, stop discussing token budgets and put the next hour into reviewer capacity or PR size limits for that team.
What it is. The core process of Goldratt's Theory of Constraints: a loop for improving a system by repeatedly finding and managing its single most limiting step.
When to use it. When a local improvement (a faster tool, more headcount, a new AI agent) does not move end-to-end delivery, or when work-in-progress piles up in front of one team or stage.
How to run it:
When NOT to use it. In systems with no stable bottleneck or where the real problem is quality or direction rather than flow.
Example: a team's agents open 40 PRs a week against reviewers who clear 25. Step three says cap agent PRs at 25 and spend the saved effort on step four.
State of AI in Software Engineering, H1 2026 (Jellyfish) — The best public dataset on agent adoption and cost curves; the diminishing-returns and concurrency findings are worth reading in full before your next budget conversation.
How are engineering leaders approaching 2026 AI tooling budgets? (DX) — Benchmarks for how much leaders reserve for AI tools, and a candid look at the ROI-measurement gap.
The Pulse: a trend of trying to cut back on AI spend within eng departments? (The Pragmatic Engineer) — Orosz on top-down and bottom-up efforts to rein in agent spend; the full piece is paywalled, but the framing is useful.
"Tell me how you measure me, and I will tell you how I will behave."
— Eliyahu Goldratt
Don't miss what's next. Subscribe to Critical Path: