From tokenmaxxing to token rationing: the CTO's next mistake

Many engineering leaders treated AI usage as a key progress metric over the past year. Uber, for instance, ran an internal leaderboard ranking teams by total AI tool usage. However, it exhausted its entire 2026 AI coding budget in 4 months.

Then came the shift from "tokenmaxxing" to cost control. By June, Uber had capped employee spending on AI coding tools at $1,500 a month per tool. Asked about the change in direction, Uber's president and COO Andrew Macdonald said the link between rising Claude Code usage and features that customers can see "is not there yet."

Maximizing tokens and rationing them are the same mistake in opposite directions. Both manage consumption, risking wasted spend on one end and missed value on the other.

The better question is where AI spend produces a measurable improvement in engineering performance and business outcomes, and where it doesn't. While blanket caps are tempting, CTOs must move toward a more deliberate way of deciding which AI investments to protect, scrutinize, or stop.

Consumption was never the signal

Finance has a legitimate case for controlling token spend. It brings costs under control and improves predictability. But controlling consumption doesn't tell CTOs where that spend is being wasted versus genuinely producing impact.

In a July 2025 study, METR reported the results of a randomized controlled trial involving 16 developers working through 246 real issues from repositories they knew well. The developers predicted AI would speed them up by 24% but ended up 19% slower. The sample was small, the developers knew their codebases unusually well, and the tools were early-2025 versions. In a February 2026 follow-up, METR reported indications of improved productivity with newer tools, although selection effects made the results unreliable. The broader lesson remains: perceived benefits of AI usage don't necessarily match measured outcomes.

But that doesn't mean AI consumption is the problem. Plandek's 2026 Engineering Productivity Benchmarks found that bottom-quartile teams using AI had nearly 50% shorter Lead Time to Value than comparable teams without AI, while top-quartile teams saw improvements of 10–15%.

More recently, Plandek's Q4 2026 AI Adoption & Impact Benchmarks, drawing on data from more than 2,500 engineering teams, found that token consumption had increased approximately 10–13x since January 2025. Yet among agentic teams, a 16% reduction in Cycle Time translated into only around a 4% improvement in Lead Time to Value.

AI amplifies the engineering system it lands in. Where workflows are healthy and constraints are addressed, it can accelerate delivery. But where review, codebase readiness, or other parts of the SDLC are constrained, faster coding doesn't necessarily translate into better engineering performance or business results.

Token count alone can't explain these diverging results.

Token rationing controls access, not value

When a bill arrives without context for the meaningful work it enabled, the instinct is to cap consumption immediately. But blanket caps don't look at where value is being created, and can even create new problems.

For example, usage can move out of sight. Srinivas Chippagiri, Senior Member of Technical Staff at Salesforce, saw a blanket per-seat cap push engineers toward free personal accounts and make people hoard requests for work they considered important. "The workaround behavior was the real cost," he says. "We lost visibility, which is the opposite of what governance is for."

Also, a blanket cap rations everyone equally when actual spend is almost never distributed equally. Carlos Benavides, Founder of Barlo Digital, broke his agency's AI bill down by job instead of by month and found a single content process consuming 43% of every token the fleet spent.

It's worth understanding where spend is concentrated before restricting AI usage, and whether those use cases create enough impact to justify the cost. Eshaan Jain, Senior Product Manager at T-Mobile, advises CTOs under cost pressure to "stop rationing tokens blindly and start rationing by business value." That shifts the decision from controlling access to actively managing the return on AI investment.

The CTO's allocation test

Governing allocation means varying spend by use case instead of setting one limit for everyone. You can make better budget decisions by considering 4 key questions for each AI use case.

1. What constraint are we improving?

AI can raise coding output, and Plandek's benchmarks show why that isn't enough on its own. Bottom-quartile teams take more than 35 hours on average to merge a pull request, against under 21 hours for top performers. If coding gets faster while review remains constrained, it moves the bottleneck further into the lifecycle instead of removing it.

A good place to start is naming the engineering constraint you want AI to improve. This is central to the Constraints stage of Plandek's RACER™ Framework for AI-augmented engineering: identifying and removing the barriers that prevent AI gains from translating into wider engineering impact. Identify and categorize the bottleneck first, and then check that the workflow you're funding actually addresses it.

2. What evidence would show it helped?

It's also important to agree on what counts as evidence of AI's value before allocating the budget. Otherwise, it becomes too easy to reverse-engineer preferred data points, like seat counts and acceptance rates, just to justify the expense. In reality, usage metrics like these don't show real-world impact.

Plandek's Four Pillars of Engineering Productivity (Focus, Speed, Predictability, and Quality) offer a practical framework for assessing whether AI is improving the engineering system, through questions such as:

• Is more capacity reaching roadmap work?

• Is Lead Time to Value falling or rising?

• Is sprint completion more reliable?

• Are change failure and rework flat or falling?

These outcomes matter, but CTOs also need leading indicators that help explain why performance is changing. AI adoption depth, working practices, repository readiness, and review friction can reveal whether an investment is likely to deliver value, or whether constraints need attention before spending more.

That said, even positive outcome signals need further scrutiny. For instance, AI-generated test suites can pass cleanly while the service they cover fails, because the tests checked the mocks and not the behavior. A green pipeline is easy to present as evidence, but until someone reads the tests, it proves little about whether the intended results were actually achieved.

That's why Arjun Jaggi, Applied AI Researcher and Executive Advisor, measures AI spend by "cost per accepted outcome," not cost per token or per session. By that measure, a team whose AI-assisted commits keep getting reverted or heavily rewritten in review is spending a lot for very little progress.

3. What does human oversight actually cost?

AI-generated output still needs human review, and that review can have its own hidden costs.

Someone has to read the diffs, check descriptions, and verify that the output is fit for purpose. Increasing output makes the workload heavier, especially on a team that's already constrained. The authoring time saved for the developer could turn into extra minutes in review. In some cases, it just shifts that extra expense from writing to reviewing, where it's harder to track and easier to leave out of the costing model.

That doesn't mean that AI has failed to reduce costs. But you can't know whether it has without accounting for the human oversight its output needs. One way to fix this is to name a review owner for each use case, estimate the hours spent reviewing, and evaluate that figure alongside the token bill.

This is an important part of understanding AI tokenomics: what matters isn't just the cost of generating output, but the cost of getting useful, trusted work through the engineering system.

4. What would make us increase, adapt, or stop the investment?

This is where the first 3 answers turn into a budget decision. The thresholds should be set before the use case goes live so you have something concrete to judge the bill against later. In practice, that leaves CTOs with 3 budgeting decisions: to increase, adapt, or stop spending. Let's look at some examples of how these decisions might play out in the real world.

Increase

Imagine that a team applies an AI tool to test generation on a legacy service with minimal coverage. The constraint is a QA backlog blocking releases. The team pre-defines the metrics they consider as proof of progress: improved lead time to release without an increase in change failure rate.

Over 2 quarters, lead time falls, and the failure rate remains stable. Oversight costs a reviewer about an hour a week sampling generated tests. Overall, the use case has met the agreed criteria for scaling the investment. As Chippagiri puts it: "Protect the two or three workflows where you have evidence of impact and let the speculative usage take the reduction."

Adapt

An autonomous agent runs multi-step refactors against a codebase with substantial technical debt. The constraint is real, and there are early signs of value, but the agreed evidence hasn't fully materialized. Pull requests open faster, but review time per PR has roughly doubled, and much of that code gets heavily rewritten, so the cost per accepted outcome is high.

In this case, rather than abandoning the use case, you might narrow the scope and fund the next phase from an explicit experimentation budget while the team tests whether those gains can hold with less rework. "The learning is the asset," Chippagiri says, "so ration it deliberately instead of letting a finance cap kill it by accident."

Stop

Imagine a team that deploys an agent to draft PR descriptions and sprint summaries. Before the rollout, the team agrees the tool must show 2 things that quarter: less time spent on status admin and no drop in review quality. If neither result shows up, the spend stops.

By the end of the quarter, activity is high, but the time spent on roadmap work hasn't changed. Reviewers have also started ignoring the AI-written descriptions after finding a few that didn't match the diff. Despite being tied to an actual constraint, the agreed evidence never appeared, and the oversight cost remains.

Here, the decision is to stop the spend or move the task to a cheaper, rules-based tool. Remember that stopping is a budget decision, not a dismissal of AI in general.

Applying the allocation test at scale

A single use case is easy enough to assess, but a CTO has multiple AI investments running concurrently. The same tool can pay for itself in one team while producing a downstream bottleneck in another. Decisions at that level need more than AI vendor usage dashboards. CTOs need to connect adoption, engineering performance, and token spend to understand where AI is creating value, where gains are being lost, and where to act.

This is what Plandek's AIRadar™ is designed to help leaders manage. Built around the RACER Framework, AIRadar brings together leading indicators from across AI tools and the engineering system, connecting rollout and working practices with constraints, engineering impact, and results. It gives leaders one place to manage the AI transition, identify what's holding back performance, and improve the return on AI investment.

Importantly, AIRadar connects token and seat spend with engineering output, so leaders can assess the economics of AI adoption rather than treating consumption as a standalone measure. Within the same Plandek platform, ProductivityRadar™ provides a benchmarked view of underlying engineering productivity, helping teams understand where performance needs attention.

The allocation test doesn't change. What changes is the evidence leaders have to guide decisions: whether to invest more, address a constraint, change how teams use AI, or stop funding something that isn't delivering.

Making every token count

Tokenmaxxing treated consumption as proof of progress. Token rationing treats it as the thing to control. Both skip the question a CTO is accountable for: does this use case improve a constraint we're facing, deliver an outcome we can see, and do so at a cost we can justify?

When CTOs answer these questions for each use case, they can make budget decisions with real evidence. Leaders can then protect workflows with demonstrated impact, stop or redirect what can't justify itself, and fund experimentation with a defined scope, budget, and review date.

The AI operating model in enterprise engineering is still maturing. What's needed isn't another usage target or an arbitrary spending cap, but a way to actively manage the transition, improve the engineering system, and connect AI investment with business results.

The goal isn't to maximize or minimize token counts, but to make every token count.

Explore AIRadar to see how Plandek helps engineering leaders manage the AI transition, from rollout to results.

Contributors

• Srinivas Chippagiri, Senior Member of Technical Staff, Salesforce

• Carlos Benavides, Founder, Barlo Digital

• Eshaan Jain, Senior Product Manager, T-Mobile

• Arjun Jaggi, Applied AI Researcher and Executive Advisor