Why your harness adoption rate stopped being a real number on June 1

In December, Uber gave its roughly 5,000 engineers Claude Code and Cursor, then did something that felt like good management at the time: it put teams on a leaderboard ranked by how much they used the tools. Adoption climbed fast. By March, 84 percent of those engineers counted as agentic coding users, a figure first reported by The Information. Four months into the year the entire 2026 AI tools budget was gone, and Uber capped spending at 1,500 dollars per engineer, per tool.

Here is the belief that leaderboard was built on, and it is the one most boards are still running on: adoption rate is the number that proves the AI coding investment is working. Get more engineers actively using the harness, watch the percentage climb, report it upward. That is the myth.

Why harness adoption rate sounded like proof of value

It sounds right because for fifteen years it was right. Software came as a seat. A seat cost the same whether someone lived in the tool or opened it twice a month, so every additional active user was pure upside, free optionality already paid for. Under that math a usage leaderboard is not reckless. It is just sweating an asset the company already bought.

The trend line makes adoption feel like the safest possible thing to measure. A press release this week, announcing governed app creation across Codex, Claude Code, and Cursor, quoted Gartner’s projection on where all of this is heading.

When nearly every engineer will be using these tools inside two years, a high adoption rate feels like proof of being early to the inevitable. The trouble is that a number everyone will soon score ninety on cannot tell anyone which spend was smart.

What metered Claude Code and Cursor billing reveals about adoption

Look again at what actually happened at Uber, because it is the cleanest case study the year has produced. The leaderboard worked exactly as designed. It maximized adoption. It also maximized the wrong variable, because under these tools usage volume is cost, not value. Some engineers were running 500 to 2,000 dollars a month in tokens. Simon Willison ran the arithmetic this week that every CFO is about to run: two tools at Uber’s cap is 36,000 dollars per engineer per year, around 11 percent of the company’s median engineering compensation. Adoption went up and to the right while finance pulled the emergency brake. Those two lines are supposed to agree. They pointed in opposite directions.

This is not an Uber problem. On June 1 GitHub Copilot switched from a flat seat to a token meter, and the same gap landed on individual invoices within hours. Developers reported a single change request costing more than six dollars, one session burning sixteen percent of a month’s credits, a single file review with no code changes eating a fifth of the monthly allowance. The engineering write-ups that followed, including a sharp one from the team at Kilo, all converged on the same advice: set hard caps, match cheaper models to simpler tasks, watch real usage. None of them said drive more adoption. When every active user is a variable cost, adoption stops being free optionality and becomes the line item to budget.

Underneath all of it is a gap Anthropic named in its own agentic coding report earlier this year. Developers now use AI in roughly 60 percent of their work, the report found, while saying they can fully delegate only 0 to 20 percent of their tasks. High usage, low handoff. Adoption was never the same thing as value realized. The meter just moved that gap from a research slide onto the bill.

The reframe: report value per active engineer over cost

So replace the adoption slide. The number that survives a metered world is value per active engineer over cost per active engineer, and as of this month both halves are measurable to the cent. Three moves make it real.

First, set a per-engineer monthly token ceiling and a pooled budget cap before the first metered bill lands, and switch off any leaderboard that ranks raw usage. It manufactures cost and calls it progress.

Second, report verified, shipped output per active engineer against that engineer’s token spend, not the percentage of people with the tool open.

Third, split heavy users from average users in the reporting. Under a meter the distribution is where both the money and the value hide, and the headline average says almost nothing.

Adoption rate had a good run as a proxy. June 1 ended that era quietly.

What engineering leaders should report to the board now

Here is what changes Monday. The adoption percentage is not wrong, it just got demoted. It is an input to a cost line now, not a proof of value, and reporting it as proof is how a leader ends up explaining a budget overrun to a board that thought things were going great. I have watched enough dashboards to believe the calm people in the next quarterly review will not be the ones with the highest adoption. They will be the ones who already swapped that slide for a value-over-cost line and named the person who owns the ceiling. That is not a harder number to produce than adoption rate. It is just an honest one, and the meter finally made honesty cheap.