What AI code costs you after it is written

I no longer write most of the code for this site myself. An agent proposes, I read it back, and six checks sit between that proposal and the deploy. None of those checks was added as a precaution. Every one of them exists because something slipped through first.

That writing got faster is settled. The question missing from most arguments is what happens afterwards, in the hours nobody counts because they are scattered across review, debugging, and next month’s incidents.

A handful of measurements now look at exactly that. I pulled all four from the source rather than from the research summaries I was handed, because those summaries have reversed an author’s meaning on me before.

The measurement everyone quotes, and what came after it

In the first half of 2025, METR ran a randomised trial with 16 experienced open-source developers. They worked on 246 real tasks in their own repositories, roughly two hours each, and every task was randomly assigned to allow or forbid AI tooling. The headline travelled everywhere: tasks took 19 percent longer with AI, while the same people believed afterwards that they had been 20 percent faster.

What rarely travels with it is what METR published themselves in February 2026. They started a new experiment in August 2025 with newer models and a larger pool, and the results point the other way. For participants from the original group the estimate is now 18 percent faster, with a confidence interval running from 38 percent faster to 9 percent slower. For newly recruited developers it is 4 percent faster, between 15 percent faster and 9 percent slower. METR add themselves that selection effects make this only very weak evidence for a speedup, which is why they are changing the design.

Anyone still swinging the 19 percent as a club is quoting tooling from February to June 2025 and ignoring what the researchers wrote next. A narrower use of that study is the honest one. It shows that developers cannot reliably judge their own speed, in either direction.

Where the time moves to

The more interesting numbers come from telemetry rather than a questionnaire. Faros AI published a 2026 report based on measurement data from roughly 22,000 developers, comparing teams with high AI adoption against teams with little.

The gain is real, and it is not small:

And in the same dataset, for the same teams:

AI moves the bottleneck to where the humans are. Writing got cheap, reading did not, and review is the last point in the chain where somebody still understands what is happening.

Two things to hold alongside this. It is telemetry from a vendor selling review tooling, not a controlled experiment, so causality here is an interpretation rather than a measurement. And one of the most dramatic figures in the report, a 480.4 percent increase in lead time from commit to production, is measured on only 10 percent of the dataset by the report’s own note. That is why it is not in the table.

What changes in the code itself

In 2025 Veracode had more than 100 language models complete the same programming tasks in Java, Python, C# and JavaScript, then tested the output for security. In 45 percent of cases the generated code introduced a vulnerability from the OWASP Top 10. Java fared worst with a 72 percent failure rate, JavaScript 43, C# 45 and Python 38. For cross-site scripting, 86 percent of the relevant samples failed.

An important qualifier: this measures what models produce from a bare prompt, not what survives review and reaches production. It describes the raw material, not the finished product. Which is exactly why whatever sits between the two matters.

GitClear looked at the code itself, across five years and 211 million changed lines from repositories owned by Google, Microsoft, Meta and enterprise firms. Cloned blocks rose sharply, and in 2024 copied code exceeded moved code for the first time. That second point tells me the most: moving code means somebody reused what already existed, copying means a second instance now has to be maintained separately. The link to AI here is inferred from timing rather than from a controlled comparison.

The caveat

The saving and the bill land in different budgets. Time won while writing is visible, falls in the same week, and belongs to the same person. Time lost lands on a reviewer, on whoever handles the incident, and on whoever has to work out a year from now why something was built this way. Measure only the first and you will measure yourself rich.

Review is a human activity facing a machine-scale supply. The arithmetic no longer works: more pull requests, larger, produced faster, reviewed by the same number of people. That 31 percent more changes merge without any review is probably not a decision but a consequence. Nobody chose to leave the gate open.

What drains away from the developer is the reading. Code that reads fluently and passes the existing tests looks finished when it is not. That is a different class of failure from a syntax error, because a syntax error falls over. This one waits.

What I do myself

Six checks block the deploy on this site, and all of them were written after a mistake. One arrived after an article had passed the entire editorial chain and still carried four patterns a regular expression could have caught. Another after three review rounds turned up the same class of problem each time: a plausible number with nothing behind it.

That is the shape that works for me. An instruction gets forgotten, a gate does not. And every gate stays small, because a check you cannot explain is a check you will eventually switch off.

Beyond that I keep changes deliberately small. Not because small changes are better, but because I can still read them. The moment I start skimming a proposal instead of reading it, the gain is already gone and I have not noticed.

Frequently asked questions

Does this mean AI tooling makes developers slower?

No, and that is the trap in the best-known measurement. The 19 percent slowdown at METR covers tooling from early 2025, and the same researchers now measure a speedup with newer models, while calling their own evidence for it weak. What stays consistent across every measurement is that the gain sits in the writing and the cost sits in the reviewing.

How do I tell whether this is happening on my team?

Look at the lead time of a pull request rather than the count. Two numbers are enough to start: how long between opening a change and a reviewer’s first response, and what share merges without anyone looking at it. If the first climbs while the number of changes climbs too, the load is shifting exactly as it does in the telemetry above.

What is the cheapest countermeasure?

Smaller changes, plus an automated check for the things you inspect every time anyway. The second costs work once and saves attention on every review afterwards, and attention is the scarce resource now, not time.

Sources

• METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 10 July 2025, and its accompanying paper.
• METR, “We are Changing our Developer Productivity Experiment Design”, 24 February 2026.
• Faros AI, “AI Engineering Report 2026: The Acceleration Whiplash”, 2026.
• Veracode, “2025 GenAI Code Security Report”, blog summary of 30 July 2025.
• GitClear, “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data”, covering 211 million changed lines from 2020 through 2024.

Checked on 21 August 2026. Every figure above I read at the source rather than taking it from a summary. What I could not verify and therefore left out: Apiiro’s numbers on vulnerabilities in AI-written code, whose page returned a 403, and the gross-margin figures for AI-native companies, which I only saw through secondary sources. Two of the four sources are vendors selling tooling in this space, and that interest is worth weighing: their telemetry is real, their choice of which slice to publish is not neutral.