Software production is booming. Who is checking it?

1. The two halves of the job

Writing code and checking code have always been done by the same people, roughly in proportion. One of those two activities has recently become very fast. The other has not.

That much is uncontroversial and mostly anecdotal. What follows is the part that is not: four groups have now measured pieces of the consequence, none of them was looking at the others, and the pieces fit together more cleanly than any of them claims on its own.

We ran none of these studies and cannot reproduce them. What this note contributes is the juxtaposition, the arithmetic that is safe to do across them, and an explicit statement of the arithmetic that is not.

2. What this is and is not

This is a note about five published measurements, not a study. It has no dataset of its own, no hypothesis it set out to test, and no control. Every figure below is attributed on the figure itself, and the reference list at the end names each report, its year and its scope.

Where a number in the prose is derived rather than published, it says so. The figures are generated from a single data file in this site’s repository in which every entry carries a publisher, a report, a year and a URL, and a test fails the build if a percentage appears in the text without appearing in that file.

3. Production

GitHub publishes an annual census of its own platform. The twelve months to October 2025 were the largest in its history by every measure it reports.

Three of those four lines are the ordinary shape of a growing platform accelerating. The fourth is a different kind of number. Repositories importing a model SDK grew 178 percent, to 1.1 million: that is not developers using AI to write code, which the other three lines already contain. It is developers shipping products that are themselves built on models, and it is a second wave standing on the first.

One further figure from the same report bears on the question this note is asking. Between May and September 2025, more than a million pull requests were opened on the platform by its own coding agent, as the author rather than as an assistant to one.

4. Maintenance

Volume alone establishes nothing about quality. The second question is whether the code arriving shows the marks of being looked after, which is measurable from the shape of the commits without asking anybody their opinion. GitClear does this across 623 million changed lines spanning 2023 to 2026.

The signals separate cleanly, and they separate in opposite directions.

Above the axis is what a system produces when it is very good at generating a plausible block of code and holds no memory of the last block it generated. Duplication is up 81 percent. Copy and paste within a single commit is up 41 percent. Constructs that swallow errors rather than handle them are up 47 percent, which is the shape of code written to make a check pass.

Below the axis is the harder finding. Moved lines are the measurable trace of refactoring: the act of noticing that two things are the same and making them one thing. Moved lines have fallen 70 percent, from 21 percent of all changed lines in 2022 to 3.8 percent in 2026. Edits to code more than twelve months old are down 74 percent. Cross-file calls, which is what reuse looks like when counted, are down 35 percent.

The claim this supports is narrow and worth stating exactly. It is not that models write bad code. It is that the work which happens around code, the going back, is not keeping pace with the writing, and that this is visible in the commits rather than inferred from them.

5. Adoption and trust

The people doing this do not believe the output. Two surveys ran in 2025 with different populations, different instruments and no connection to each other, and found the same thing.

Ninety percent adoption against twenty-four percent trust is the widest gap in this note. Reproduced across two populations, it is difficult to read as an artefact of either instrument.

The Stack Overflow results indicate where the distrust comes from. Sixty-six percent name a single frustration above all others: output that is almost right, but not quite. Forty-five percent report that debugging generated code takes them longer than writing it would have. Adoption in the same survey rose from 76 percent the previous year while trust fell, so the two are moving in opposite directions in the same population.

Almost right is the expensive failure. Code that is obviously wrong costs a minute. Code that is wrong on one branch, at one screen size, for one class of user, costs whatever it costs to find, and the reliable way to find it is for something to use the product.

6. Where checking fails

One study measures, at scale, what gets through. Veracode ran over a hundred models against eighty curated tasks in four languages, each task admitting a known-secure and a known- insecure completion, and recorded which the model produced.

The reported headline is that 56 percent of tasks passed, effectively unchanged in a year. That average is the least informative statistic in the dataset.

Disaggregated, the failure is not distributed. Cryptography passes 87 percent of the time and SQL injection 83 percent. Cross-site scripting passes 15 percent, meaning 85 percent of tasks touching user-facing output produced an injectable flaw.

That distribution is legible. The two classes handled well are those with a local right answer that looks like a right answer: call this library, use this parameterised form. The class that fails is the one where correctness depends on where a value is eventually rendered, in a file the model was not attending to. It is a whole-program property, and the model is not reading the whole program.

Neither is the reviewer of the pull request.

7. The review gap

Taken together the five results describe one thing.

Output is rising by roughly a quarter a year and accelerating. The share of that output which anyone returns to has fallen by two thirds or more. The people who would perform the checking use the tool at ninety percent and trust it at twenty-four, and identify the most common failure as the kind that takes longest to find. And the one defect class measured properly passes five times in six.

Review capacity is a human number. It did not change. Everything on the other side of it multiplied. The gap is not the result of a decision anybody made.

This is a company blog and the following should be discounted accordingly, but the shape of the implication seems clear from the five results above. If production is machine-scale, a first pass has to be machine-scale or it does not occur. And given the 66 percent figure, that first pass cannot be a second model reading the code and forming an opinion, because reading is what produced the problem. Something has to open the product, use it, and return with a reproduction, because almost right is invisible in a diff and obvious the moment the button is pressed. That is the position this company has taken, and what it does is documented separately.

8. Limitations

Each of the five results is weaker on its own than the juxtaposition suggests, and the weaknesses do not cancel.

• The platform census is self-reported by the platform being measured, and one platform is not the industry. Growth in repository counts also includes repositories that are forks, exercises and abandoned starts.
• The corpus study measures commit shape, not quality. Fewer moved lines is consistent with less refactoring and also with code that needed less of it. The study cannot separate the two, and neither can we.
• Both surveys are self-selected and measure reported behaviour and stated belief, not behaviour. The Stack Overflow population skews toward people who read Stack Overflow.
• The security study measures a curated task set, not code in production. Eighty tasks across four vulnerability classes is a benchmark, and a benchmark result is a claim about the benchmark.
• None of the five was designed to be read with the others. They cover overlapping but not identical periods and populations. No causal claim survives that, and we make none: what is asserted here is co-occurrence, which is weaker and still worth knowing.

9. The quantity nobody has measured

The sentence this note is reaching for is of the form N billion lines of unreviewed code shipped last year. It does not appear above because nobody has measured it.

Producing it would require multiplying a repository count by an estimate of size and an estimate of review coverage, and then reporting the product as a finding. Every figure in this note is a rate or a share that somebody published with a method attached. What none of them combine into is the total, and we are not going to supply one.

References

1. GitHub. Octoverse 2025. Platform-wide activity, twelve months to October 2025.
2. GitClear. The Maintainability Gap: 2026 AI Code Quality Research. 623 million changed lines, 2023 to 2026, private repositories and large open source projects.
3. Google Cloud / DORA. State of AI-assisted Software Development 2025. Nearly 5,000 technology professionals surveyed, plus over 100 hours of qualitative data.
4. Stack Overflow. Developer Survey 2025. Over 49,000 respondents.
5. Veracode. 2026 GenAI Code Security Report. Over 100 models across 80 curated tasks in four languages.