The coding-agent adoption number your board loves stops being free on June 1

There is a slide in a lot of board decks this quarter with one proud number on it: the percentage of engineers actively using the coding agent. It went from single digits to most of the team in under a year, and it photographs beautifully next to a velocity chart. On June 1, GitHub flips Copilot off flat per-seat pricing and onto token-metered AI Credits, and that quiet billing change is about to make that proud number mean something different than it did last month.

The myth

The myth is that the adoption percentage going up is, all by itself, the win. More engineers on the agent, more leverage, more shipped. Push it from 70 percent to 95 percent and the org gets correspondingly faster and the board gets a cleaner story.

I understand why it lives on the slide. It is the easiest harness metric to pull, it always moves in the flattering direction, and it lets a leadership team say “we are an AI-native engineering org” with a straight face. The trouble is that the meaning of that number depends entirely on what each active seat costs, and that cost is about to stop being a constant.

Why it sounds right

For most of the last two years, the myth was true enough to be harmless. Pricing was flat. A seat was a seat. An engineer who barely touched the agent cost the same as one running it all day, so the rational move was to hand a license to everyone and let usage sort itself out. Wider adoption was a free bet with real upside and almost no marginal downside.

That world had a comforting property: the cost line did not care how the agent was used. You bought 200 seats, you paid for 200 seats, and the finance conversation was over before it started. In that world, “drive adoption up” really was a strategy, because the only variable that moved was value.

The flat seat is what is ending. Once cost tracks usage instead of headcount, the logic that made wide adoption free quietly stops holding, and most adoption slides have not caught up to that yet.

What the evidence says

Two things landed this week that change the arithmetic.

The first is the pricing mechanics. Writing on May 27, engineer Bart Wullems laid out what the June 1 switch actually does: Copilot Business stays 19 dollars a month and Enterprise stays 39, but the headline price now just buys a pool of credits where one credit equals one cent, and an agent-mode session or a code review can burn ten to fifty or more credits at a time. His practical advice to individual users was to keep a 10 to 20 dollar buffer on hand, because a single heavy session can walk a power user straight through a month’s included pool. The seat did not get more expensive. The seat got a meter.

The second is what real usage looks like once a big org actually leans in. Reporting on May 29, Let’s Data Science put numbers on the rollout that everyone has been whispering about:

That same report pegged monthly cost at 150 to 250 dollars per engineer on average, and 500 to 2,000 dollars for heavy users, with about 11 percent of live backend updates shipping with no human in the loop. Read those two facts together and the whole point arrives. The adoption curve and the cost curve climbed in the same two months, on the same engineers, for the same reason.

Under flat seats, that adoption jump would have been pure good news on a fixed bill. Under a meter, the jump from 32 to 84 percent is also a jump in the invoice, and nobody put the second curve on the slide next to the first.

The reframe

Here is the shift in one line. Adoption percentage was a sensible headline metric in a world where the cost of a seat was fixed. It becomes a misleading one the moment cost tracks usage, because a higher adoption number now describes a higher bill just as faithfully as it describes higher value.

This is not an argument against adoption. It is an argument against treating the adoption percentage as the scoreboard. The 84 percent is only good news if the value those active engineers return clears what their tokens cost, and right now most orgs cannot say whether it does, because they were never asked to. Flat pricing let everyone skip the question.

Companies that bought a productivity tool are discovering, one invoice at a time, that they bought a metered utility instead.

So what

Three moves are worth making before the next push to widen adoption, and none of them require slowing anything down.

First, set a per-engineer monthly ceiling now and wire the budget controls, the pooled credits, the caps at the org and user level, before the first metered bill lands rather than after. The admins who do this in the last week of May will have a very different June than the ones who find out by surprise.

Second, replace the adoption percentage on the leadership slide with a value-per-active-engineer number: verified merged output, or shipped work that survived review, set against the token spend that produced it. Keep the adoption figure if it helps, but stop letting it stand in for value.

Third, separate the heavy users from the average ones in the reporting, because the 500-to-2,000-dollar engineers are where both the leverage and the runaway cost live, and they deserve a closer look than a single org-wide average can give them.

June 1 is not a cliff. It is a useful forcing function. The orgs that come out ahead will not be the ones with the highest adoption number. They will be the ones who already knew what each active seat was worth before the meter started telling them what it cost.