AI coding costs land in review, not on the invoice

The AI coding bill is still a small share of an engineer's pay

Per engineer, the AI coding bill is small, though the invoice is where most of the worry sits. Anthropic's figures for enterprise use of its coding agent² and DX's all-in estimate of seat plus token spend³ both come to a modest monthly sum per engineer.

Levels.fyi's 2025 report puts a US software engineer's total yearly pay at about 226 thousand dollars⁴. Against that, a year at the top of the vendor's average range is a little over one percent, and a year at the top of DX's range about three percent.

That is our arithmetic on total pay rather than loaded cost, so the true share is lower still. The vendor figure is an aggregate with no sample size, so treat both shares as rough; even rough, the bill is nowhere near the cost of the person.

Caps may come, and a few heavy users can surprise you. At Acme, though, the token line for the payment-retry change is a rounding error on the month's invoice. On our arithmetic over a full working year, a whole active day of agent use at the vendor's average² costs less than one hour of the engineer's pay at Levels.fyi's figure⁴.

More code arrives, but company delivery often does not move

The bill buys more code, but the evidence that it moves company delivery is thinner than the dashboards suggest. In a telemetry study of over ten thousand developers, Faros AI found that gains in team behavior do not scale when aggregated to the company¹. Across more than 400 organizations, DX found a median PR throughput gain of 7.76%³: a real gain, and a modest one.

LinearB's 2026 benchmarks point to wasted output: AI-generated pull requests are accepted far less often than manual ones⁶. Code that never merges costs review time and ships nothing.

Not every study agrees. DORA's 2025 survey finds a positive link between AI adoption and delivery throughput⁷; the section on tests below covers what DORA says the return depends on.

Back at Acme, the agent opens the payment-retry PR the same afternoon, and the dashboard counts a pull request, though nothing has shipped yet.

The extra output piles up in review, on your senior engineers

The extra output stalls in review. In Faros AI's data, PRs grew 154% larger on average¹, and review time rose with them.

In LinearB's separate data, AI pull requests wait 4.6x longer before anyone picks them up, though they are reviewed 2x faster once someone does⁶. Addy Osmani, who spent over 14 years leading developer experience at Google and became a director at Google Cloud AI⁸, named the limit in a January 2026 essay.

PR volume rises at companies your size too: Synthesia's 118 engineers went all in on AI coding tools in November 2025¹⁰. Its CTO, Peter Hill, told IEEE Spectrum that pull requests had risen 120 percent year over year¹⁰. He gave the volume entering review but not the hours it took.

Faros AI's head of product marketing, Naomi Lurie, argues that senior engineers absorb the review load because they catch what AI gets subtly wrong¹¹. Cui and colleagues recorded seniority in the Microsoft experiment. They found the AI assistant significantly raised task completion for recent hires and juniors, but not for senior, long-tenured developers¹². If those PRs go to seniors for review, the juniors' extra output becomes the seniors' extra review; that step is our reading, not something either study measured.

None of this is on the invoice, and no study we found prices it. Price it yourself: one hour of your staff engineer against the agent's whole token line. At Acme, the payment-retry PR is far larger than the change needed. It waits days, then lands on the one staff engineer who knows the payment flow, the same person whose juniors fill her queue.

More code merges unreviewed, and adoption tracks with less stable delivery

Under high AI adoption, more pull requests merge with nobody looking, and DORA links adoption to less stable delivery. Faros AI's 2026 report found 31% more PRs merged with no review at all under high AI adoption¹¹. Faros does not say whether that is a count of merges or a share of them. On our reading, each unreviewed merge can move cost from today's reviewer to whoever handles the next incident.

DORA's 2025 survey finds AI adoption still has a negative relationship with delivery stability⁷. DORA reports the link, not its cause.

GitClear's analysis of changed lines shows a longer trend: refactoring shrank over the years AI tools spread¹³. The timing matches adoption, but GitClear does not show that AI caused it.

The evidence is mixed. Jellyfish, looking at bug tickets and reverts, found no significant relationship with AI adoption¹⁴. The studies measure different things in different ways, and we do not know why their results differ.

At Acme, under deadline, the second review on the payment-retry PR is waved through. A retry loop double-charges a handful of customers on a Friday. The rework and the incident are part of what the change cost.

Without tests and fast feedback, more code turns into instability

DORA's 2025 report says that without strong automated testing, mature version control and fast feedback loops, more change volume leads to instability⁷. DORA draws that from its survey, not from a controlled trial.

DORA adds that the greatest return comes from internal platforms, clear workflows and aligned teams rather than from the tools themselves⁷.

Jellyfish's Nicholas Arcolano runs research at a vendor that sells engineering measurement. In a talk on his firm's data, he compared teams by how their code is spread across repos.

Treat the size of any gain with care. Pooled field experiments at three companies found a 26.08% rise in completed tasks, with a standard error of 10.3%, so the true gain could be small¹².

So measure the return where it is decided. One vendor defines the unit as total fully loaded AI cost over a period, divided by the PRs that merged and survived. Survived means not reverted or substantially rewritten inside a churn window¹⁵. Put review hours inside that cost; our next post takes the metric apart.

Acme puts a size limit and a test gate in front of review, and sets a pickup target for agent PRs. It starts dividing all AI cost, review hours included, by changes that merged and stayed merged. The payment-retry change now reaches its staff engineer small, tested and on time.

What to do on Monday

1. Write down the share. Put last quarter's AI spend for each engineer beside your loaded pay. It is your baseline, and it is probably small.
2. Split the review clock. Pull review pickup time and time in review for the last month, AI-assisted PRs apart from the rest.
3. Gate before a person. Set a size limit and a pickup target for agent PRs, and make tests pass before anyone reviews.
4. Count reviews by name. Count the reviews each senior engineer did last month. If one name carries the load, spread it.
5. Start cost per merged change. All AI cost plus review hours, divided by changes that merged and were not reverted within a month.

The companion, The AI-ready engineering team playbook, is free with your work email.