There are now engineers at some of the largest software companies in the world who worry about whether they are consuming enough AI. Not whether they are solving the right problem, not whether their code holds up, but whether their token consumption looks high enough on the internal dashboard. One of them put it plainly to The Pragmatic Engineer: he is conscious of not wanting to be seen as someone who "uses too little AI," and is not ashamed to say he does tokenmaxxing to avoid it[1].
The phenomenon has a name and a definition: tokenmaxxing is the practice of maximizing one's AI usage, specifically through autonomous agents, with "ultra-high AI utilization treated as a signal of productivity, regardless of the output"[2]. Companies are building dashboards that track token usage and the share of AI-generated code; at Meta, an internal leaderboard ranks the company's heaviest AI users[1].
Anyone currently building such a dashboard will not enjoy what follows: the evidence lines up against it with unusual clarity. Tokenmaxxing is not a new measurement problem but a very old one in new clothes, and the alternative is not rocket science but what good engineering organizations do anyway: measure results instead of effort. Call it valuemaxxing. This piece traces why input measurement fails, what it costs, and what belongs in its place.
An old measurement error in new clothes
The software industry has had this debate before. Whoever measured productivity in lines of code written got more lines of code, but not more working software. That is exactly where this road leads back to: tokenmaxxing is "going back to the pre-DORA era, to the era of measuring lines of code"[3]. Except that a line of code costs nothing today but electricity, while every token shows up on an API bill.
The mechanism of failure is the same as back then, sharpened by the cost component. The Pragmatic Engineer puts it bluntly: there are very few rational reasons why incentivizing tokenmaxxing makes sense for any company. It increases AI spend, by a lot, in return for little to no value, because the number of tokens a developer generates can easily be gamed, and if this metric is measured, developers will indeed game it, with a massive AI bill as the side effect[1]. This is Goodhart's law with a price tag: as soon as the metric becomes the target, it stops measuring anything and starts burning money.
Even the sober documentation of the term notes that the practice "may cause additional token costs, worker burnout, or actually create more bloated code of lower quality"[4]. The root error is always the same: an input, whether lines of code, hours worked, or tokens, is treated as a proxy for an output, meaning working software and solved business problems. Developers whose token consumption is measured will optimize token consumption. Whether the generated code ever ships, works, or solves the right problem does not appear in the metric.
The math does not work out so far
One could object: if AI tools genuinely accelerate development, then high consumption is a signal after all. The problem is that the economic evidence does not support this reading so far.
On the cost side, organizations optimizing for output volume trade predictable labor costs for volatile, growing API expenditures. The Innovation Dispatch's analysis sharpens the point: this pursuit of code output transforms engineering teams "into high-cost AI consumption centers"[5]. At the same time, internal AI productivity budgets are doubling year over year, and some companies plan to hire less in order to spend more on AI tools[6].
On the return side, little verifiable value stands against this. According to the Gartner CIO survey cited in industry benchmarks, many engineering leaders cannot quantify the ROI of their AI investments; at best they break even, or they lose money[7]. That is remarkable: a technology whose productivity effect is supposedly so obvious that its consumption is elevated to a KPI simultaneously and stubbornly resists showing up in the profit and loss statement.
The connection between these two findings is no accident. Whoever measures token consumption and generated lines of code has no visibility into whether that output translates into shipped features, shorter cycle times, or better business outcomes[6]. Organizations that did not articulate what engineering performance means for them before rolling out AI find it almost impossible afterwards to measure AI impact beyond surface-level metrics like lines of code or acceptance rate[6]. The measurement gap is not a consequence of AI adoption; it is the precondition for tokenmaxxing looking plausible as a metric in the first place.
Shipping faster, rolling back more often
Beyond the cost question sits the quality question, and here the data is less flattering than the tool vendors make it sound.
The 2025 DORA State of DevOps Report shows a pattern familiar to anyone who has scaled speed without governance: teams using AI coding tools increased their deployment frequency, but their change failure rate rose in parallel[8]. More throughput, more failures, and the documented cases identify the root cause not as poorer engineering performance but as a mismatch between code generation speed and human review capacity[8].
The code turnover rate sends the same signal. It measures the share of code that is reverted, deleted, or substantially rewritten shortly after being merged, and AI-generated code turns over at higher rates than code written by humans[9]. Part of the apparent productivity gain is therefore work done twice, once by the machine and once by the human cleaning up afterwards. Developers themselves describe the core problem precisely; their most common complaint about AI tools is that the solution is "almost right, but not quite," and only a minority highly trusts the output[10]. In academic benchmarks, only a small share of AI-generated code compiled at all, failing mostly on unknown symbols[11].
This produces the real bottleneck of AI-accelerated development, and it is not in the writing. When AI tools increase code output, review workload grows proportionally, but review capacity does not scale at the same rate[7]. Teams spend growing shares of their sprints waiting, on reviews and on CI pipelines[8]. Whoever keeps incentivizing token consumption upward in this situation enlarges exactly the pile that real value creation is stuck behind. You measure the inflow and celebrate it while the outflow is clogged.
The developer role is shifting
Beneath the metrics debate lies a deeper shift, and understanding it explains why input metrics are so misleading right now of all times.
As AI takes over more code generation, the developer's role moves toward orchestration and specification[7]. Microsoft observes a new phenomenon at the same time: roles that previously did not involve programming are starting to write code because the cognitive barrier to entry has dropped significantly[12]. That sounds like democratization, and partly it is. But it creates a paradox: the cheaper producing code becomes, the more expensive and important the judgment about whether that code is right.
Because the trust problem is real and well founded. Developers openly admit they do not fully trust AI-generated code, and precisely this gap creates a new operating model: AI increases implementation speed while senior engineers become more critical as architectural authorities and validation gates[13]. AI handles repetitive, well-defined work effectively but struggles with complex architectural decisions, security-sensitive code, and system-level design[13]. And in practice, developers often spend more time fine-tuning AI-generated code than they would writing the piece from scratch[14].
The difference between teams that profit from this and teams that pay for it lies in structure. High-performing teams treat AI as an acceleration layer inside experienced, architect-led workflows, with clear usage guidelines, validation checkpoints, and restrictions on AI code in security-sensitive modules. Weaker implementations use AI ad hoc, without system boundaries or review workflows, gain speed initially, and pay for it later with defects, security gaps, and design inconsistencies that are significantly more expensive to correct[13].
Against this backdrop, it becomes clear what tokenmaxxing actually rewards: the activity that is currently becoming a commodity. The best summary comes, once again, from The Pragmatic Engineer: the best developers are not necessarily those who write the most code; they are the ones who solve hard problems for the business quickly and reliably, with or without code[1].
What to measure instead: valuemaxxing in practice
Nobody has to invent a new framework for the alternative. The tools exist; they just have to be used as a system.
The DORA metrics, meaning deployment frequency, lead time, change failure rate, and time to restore, remain relevant for assessing AI impact, and the SPACE framework adds the qualitative dimension from satisfaction to efficiency; this is confirmed by no less than DORA co-creator Dr. Nicole Forsgren[15]. The system idea is what matters: DORA metrics were never designed to evaluate individual developer output. They work as a set, because gaming one metric shows up in the others[3]. Exactly this self-correction is what the lonely token metric lacks.
For the AI share of the work, this means concretely: outcomes over attributions. Connect AI-generated code to actual outcomes, to cycle time, revert rate, throughput, and review burden[16]. Two metrics deserve particular attention. The code turnover rate is the most direct quality indicator for AI code because it measures how much of it disappears again shortly after merging[9]. And the change failure rate is the leading signal that AI throughput is outpacing review governance[8].
The rest is organizational work. Define what engineering performance means for your company before scaling AI usage, otherwise you will inevitably end up measuring surface metrics[6]. Scale review capacity in proportion to generation speed instead of ignoring the bottleneck[7]. And calculate ROI honestly, including API costs, rework, and review investment, against actual delivery outcomes rather than code volume[5].
What a dashboard that measures value could look like
At this point the practical question reliably arrives: fine, but what do we put on the screen now? And can't this become a score? Up front: a single score is exactly the simplification this piece warns about, and even a well-built score becomes a target the moment it influences promotions. If it has to be one number anyway, because executive boards simply want one number, then under two rules: the score always pairs speed metrics with quality metrics, so that manipulating one metric shows up in the others[3]. And it is never displayed without its components.
The ingredients come from two sources. GitHub knows the delivery and quality side: merges and deployments, the time from opened pull request to merge, reverts and hotfixes, review latencies. Agent telemetry and the API bill know the AI side: what share of merged code comes from agents, how long that code survives, and what it cost. Combined, this yields a compact metric set:
| Metric | Source | Good is | Role in the score |
|---|---|---|---|
| Deployment frequency | GitHub (merges, deploys) | higher | Delivery |
| Lead time (PR to merge) | GitHub | lower | Delivery |
| Change failure rate | GitHub (reverts, rollbacks, hotfixes) | lower | Quality and cap |
| Code turnover after 30 days, AI vs. human | GitHub plus agent telemetry | lower | Quality |
| Review latency on AI pull requests | GitHub plus agent telemetry | lower | Quality |
| AI cost per merged change | API bill divided by merges | lower | Efficiency |
| AI share of merged code | Agent telemetry | neutral | Context only, no score effect |
Two things stand out. Token consumption appears nowhere, not even as an efficiency denominator; what counts is what arrives, not what is consumed[16]. And the AI share of code is deliberately neutral: it is context you want to know, but neither a goal nor a merit.
From these building blocks, a deliberately simple score can be built. Each metric is not judged in absolute terms but relative to the team's own baseline over the last 90 days, because what matters is the direction, not the industry comparison:
norm(x) = x relative to the team's 90-day baseline,
clamped to 0.5–1.5 and scaled to 0–1
Delivery = mean of norm(deployment frequency) and norm(1 / lead time)
Quality = mean of norm(1 / CFR), norm(1 / turnover), norm(1 / review latency)
Efficiency = norm(merged changes per euro of AI spend)
Value Score = 100 × (0.4 × Delivery + 0.4 × Quality + 0.2 × Efficiency)
Governance cap: if the change failure rate sits more than 20% above
the baseline, the score is capped at 60, however good the rest looks.
The cap is the most important part of the formula. It translates the central DORA finding, that rising throughput with a rising failure rate is not progress, into a hard rule: no team can earn a good score through speed while quality runs away[8]. The weights are starting values, not truth; what matters is only that delivery and quality weigh equally.
This is what the simplified view could look like, with fictional numbers:
ENGINEERING VALUE SCORE Team view, rolling 90 days
──────────────────────────────────────────────────────────────────
Score 78 / 100 (+4 vs. last quarter) Governance cap: off
Delivery 0.82 · Quality 0.74 · Efficiency 0.71
──────────────────────────────────────────────────────────────────
Deployment frequency 12 / week ▲ Baseline 9
Lead time PR to merge 26 h ▼ Baseline 31 h
Change failure rate 8.1% ▲! Baseline 6.9%
Code turnover 30 days AI 19% ▲! Human 9%
Review latency AI PRs 9 h ▲ Human PRs 6 h
AI cost per change €4.10 ▼ Baseline €5.60
──────────────────────────────────────────────────────────────────
Context: AI share of merged code 46% (no score effect)
▲! = warning signal: throughput growing faster than governance
Read it like a cockpit, not like a report card. The score on top is the conversation opener; the rows below are the conversation. In this fictional team you would see immediately: the pace is right, costs are falling, but the two warning signals tell the familiar story, AI code disappears twice as fast as human code[9], and the failure rate is picking up while frequency rises. The right reaction would not be to celebrate the score but to build review capacity before scaling further[7].
One final caveat belongs here: this score ages too. Baselines shift, teams learn its mechanics, and at that point it needs maintenance like any other measuring instrument. Whoever treats it as truth rather than as a compressed summary of six honest metrics has merely built a new tokenmaxxing, only with the sign flipped.
What the evidence does not support
Here too, honesty requires naming the limits of the findings. Tokenmaxxing is a young phenomenon; it emerged in 2024 and 2025. Peer-reviewed longitudinal research on it barely exists; the best available evidence comes from industry reports, platform data, and practitioner accounts, and several central claims rest on single sources. That is a thinner base than one would wish for on an organizational question of this weight.
It is also conceivable that individual organizations with strong governance achieve genuine productivity gains that exceed the costs and quality risks. The evidence suggests that precisely this governance is the precondition, not the high consumption[13]. But the full picture across many organizations is missing, and the tools, cost structures, and practices are changing fast. Whoever measures today should be prepared to adjust tomorrow, and should treat productivity promises without data from their own organization as a hypothesis, not a finding.
What decision-makers should take from this
First: do not build token dashboards or leaderboards. What you measure gets gamed, and with this particular metric you additionally pay for the gaming in API costs[1]. If you already have such dashboards, they are a good candidate for the next spring cleaning.
Second: define what success means before you scale AI usage. DORA as a system, SPACE as a complement, plus cycle time, revert rate, and review burden for the AI share[15][16]. An organization that cannot say what "better" means will justify every AI investment in the wrong place.
Third: treat review capacity as what it is, the bottleneck of the system. A rising change failure rate alongside rising deployment frequency is the signal to strengthen governance and review processes before generating even more code[8].
Fourth: draw boundaries for AI code in security-sensitive modules and set validation checkpoints, as the high-performing teams do[13]. And invest in senior capacity: the more code the machine writes, the more valuable the human who can judge whether it is right.
Fifth: demand evidence. A large part of the AI productivity discourse rests on anecdotes and vendor promises. Measure outcomes in your own organization, calculate the full costs, and distrust every metric that sells effort as achievement.
The punchline of the whole debate is reassuringly old-fashioned in the end: the best developers were never the ones with the most lines of code, and they are not the ones with the most tokens either. They are the ones who solve hard problems quickly and reliably, with or without code[1]. A metric that does not capture that is not measuring productivity. It is measuring busyness.
