Two numbers out of the same dataset, both published in January 2026.
Heavy AI users are producing about 25 percent more code than their own past selves. Duplicated code is up 81 percent, from 40.3 duplicated lines per million changed lines to 73.0. GitClear pulled both out of 623 million code changes recorded between 2023 and 2026.
Volume rose a quarter. Copying rose four fifths. Copying is growing 3.2 times faster than the output it sits inside, which means the extra duplication is not a by-product of writing more. It is a change in what is being written.
The thesis
AI did not automate engineering. It automated production, left verification exactly where it was, and the cost of verification scales with how much code you already own. So the price of people who can produce code is falling towards the price of a subscription, and the price of people who can look at plausible code and say what is wrong with it is going up. Thirty years at a keyboard just became an appreciating asset.
That is contestable, and most of the market disagrees with me. The prevailing 2026 argument is that models now write senior-level code, so you need fewer seniors and more cheap operators driving agents.
The grid nobody reads as a grid
Stanford’s software engineering productivity programme, run by Yegor Denisov-Blanch, has measured nearly 100,000 engineers across more than 600 companies. Split the work four ways and the gains separate hard.
Greenfield, low complexity: 30 to 40 percent. Greenfield, high complexity: 10 to 15 percent. Brownfield, low complexity: 15 to 20 percent. Brownfield, high complexity: zero to 10 percent, with a material share of teams going net negative. Net of rework, across everything, the average lands around 15 to 20 percent.
Read that as a table and it is a productivity study. Read it as a grid and it is a depreciation schedule on your own estate. Every line of code your company already owns lowers the return on the next line a model writes for you. Not because the model is worse at old code. Because someone has to decide whether the new thing is consistent with the old thing, and that decision costs roughly the same whether the change took six hours to write or six seconds.
That is the whole move. Production time collapsed by an order of magnitude. Verification time did not move at all. When one side of a two-sided process gets 20 times cheaper, the other side becomes the entire cost, and whoever can do the other side becomes the entire constraint.
It gets worse with scale. The same programme reports models losing roughly half their performance at around 32,000 tokens of context. Your enterprise codebase is not 32,000 tokens. The context that decides whether a change is correct lives in people, in decisions made four years ago that were never written down, in the reason a function looks stupid.
What the numbers do next
GitClear’s Maintainability Gap research, January 2026. Refactoring fell to 3.8 percent of changed lines in 2026, from 21 percent in 2022. Copy and paste rose to 15.7 percent in the first half of 2026. Function reuse is down 35 percent since 2023. Long-term maintenance activity is down 74 percent since 2023. The supply of context maintenance collapsed at exactly the moment demand for context rose. That is the shape of a system where the cheap half got cheaper and the expensive half got skipped.
DORA published its ROI of AI-assisted Software Development report in May 2026, led by Nathen Harvey at Google Cloud, building on research covering close to 5,000 technology professionals. Their model for a 500-person engineering organisation at 176,000 dollars fully loaded: 8.4 million dollars of investment, 11.6 million dollars of first-year value, a 39 percent first-year return, payback around eight months. In the same model, moving change failure rate from 5 percent to 6 percent costs 344,000 dollars.
Run those two numbers against each other. 344,000 dollars is 3 percent of the entire first-year value, per single point of change failure. Ten points, which is not a wild outcome for a team merging on plausibility, costs 3.44 million on a straight line. That takes 11.6 million of value down to 8.16 million against 8.4 million of spend. The programme goes negative. The whole 39 percent return sits inside ten points of a metric most engineering organisations have never baselined.
Stack Overflow’s developer survey, fielded 29 May to 23 June 2025, 49,009 respondents. 84 percent use or plan to use AI tools. Trust in accuracy fell to 33 percent and only 3 percent trust the output highly. The single biggest frustration, at 66 percent, is “almost right, but not quite”. 45 percent say debugging AI code takes longer than expected. Near universal adoption, collapsing trust, and the top complaint is a category of error that only a person holding context can catch.
I have been writing software for 30 years. For most of that time the scarce thing in any delivery organisation was someone who could make the machine do the thing. That stopped being scarce, and I noticed it in my own week before I saw it in anyone’s dataset. Almost none of my hours now go on producing something that works. They go on deciding whether something that already works should exist in this system.
So I changed the first question I ask. Walking into a delivery organisation I no longer ask for velocity. I ask what share of merged changes last quarter had a reviewer who had touched that file before. Most places cannot answer it. The ones that can are the ones where AI is actually paying.
Where this breaks
METR ran a randomised controlled trial on experienced open-source developers working in repositories they knew well, published 10 July 2025. They were 19 percent slower with AI and believed they were 20 percent faster. That is the best argument against me on the table: the veteran is the person the tool slows down. METR’s follow-up, reported 24 February 2026 across 57 developers, 143 repositories and more than 800 tasks, measured minus 18 percent for returning participants and minus 4 percent for newly recruited ones. The slowdown concentrated in the people holding the most repository context. My reading is that they were slow because they were doing the verification, and elapsed task time does not price a defect that never shipped. That is a reading. It is not what the study measured.
Second, METR withdrew that design. They now say the data gives only very weak evidence on productivity, partly because 30 to 50 percent of developers declined to submit tasks they did not want to attempt without AI, and recruitment kept failing because people would not give up their tools at any offered price. I am leaning on a study whose own authors have told you to lean on it less.
Third, GitClear counts code, not outcomes. Duplication is a maintainability proxy. A product rewritten inside two years does not care about maintainability, and if your estate has a short half-life none of this applies to you.
Fourth, the ten-point extrapolation on DORA’s 344,000 dollars is mine, not theirs. They priced one point. Failure cost is almost certainly non-linear and I do not know in which direction.
Fifth and strongest: greenfield is real. A company whose entire codebase is eighteen months old sits in the 30 to 40 percent corner of that grid, and for them the right hire genuinely is a fast operator driving agents. My argument is about accumulated context. If you have not accumulated any, ignore it.
And one against my own vanity. Thirty years is not judgement. Plenty of long-tenured engineers hold deep context about exactly one system and nothing transferable to any other. Tenure is a proxy and a weak one. What is repricing is the ability to reject a plausible thing, and some people have that at twenty six.
What I would do on Monday
Place yourself on the grid before you sign the seat contract. Split last quarter’s merged changes into greenfield and brownfield, low and high complexity, then weight the Stanford ranges against your actual mix. Most enterprises will find the majority of their work in the bottom right corner, where measured gain is zero to 10 percent. Budget against that, not against the vendor deck.
Baseline change failure rate this week. It is the one number in DORA’s model that can take a 39 percent return negative, and you cannot reconstruct a clean pre-AI figure once the seats are live.
Track duplication growth as a ratio to output growth, monthly. If duplication is outrunning volume the way it did 3.2 to one in GitClear’s data, you are buying throughput and selling coherence, and that invoice arrives in eighteen months.
Fund review capacity as a role, not as an unpaid tax on the same three people. If verification is the bottleneck, staffing it as an afterthought is the same error as one tester per hundred engineers.
Change what you test for in interviews. Stop asking candidates to produce a correct function. Hand them a plausible 200-line diff against a system you briefed them on twenty minutes earlier and ask what is wrong with it. That separates people faster than any exercise I have used.
Close
Back to those two numbers. 25 percent more output. 81 percent more duplication.
One of them is what your AI budget was bought to produce. The other is what it gets judged on in three years. The gap between them is not a tooling problem, and no seat licence closes it.
It gets closed by someone who reads the diff and says no.
I spend most of my week inside delivery organisations working out which changes should have been stopped. If you are about to buy another thousand seats and nobody has baselined your change failure rate, book a call first.