Change volume, stability and the limits of human review

What the measurements show

Honeycomb’s codebase doubled, from 0.97 million lines at the end of 2024 to 1.94 million in May 2026, and by June at least 82.6% of new lines were attributed to AI. Incidents rose with the volume: from about 18.5 a quarter to 32 in the first quarter of 2026 and 53 in the second, 2.9 times the baseline. No pull request was auto-approved. Honeycomb already had continuous integration, tests, observability and defensive controls, and the post describes other organisational changes over the same period. It is an observational account. It does not isolate AI’s effect, and it does not show that reviewers caused the additional incidents. The author’s own reading is that “AI amplifies your existing practices”.

Google’s DORA research points the same way at survey scale. The 2024 DORA report found that AI adoption was associated with lower software delivery stability and throughput. The 2025 DORA report, from nearly 5,000 respondents, found that AI adoption now has a positive relationship with software delivery throughput and “does continue to have a negative relationship with software delivery stability”. The report’s explanation is that without control systems such as strong automated testing, mature version control and fast feedback loops, “an increase in change volume leads to instability”. Its summary is that “AI doesn’t fix a team; it amplifies what’s already there”.

The developers doing the work describe what the instability feels like. In the 2025 Stack Overflow survey, more respondents distrust the accuracy of AI tools (46%) than trust it (33%). The frustration named most often, by 66%, is “AI solutions that are almost right, but not quite”, and 45.2% say debugging AI-generated code takes more time. These are reported attitudes, not measured outcomes. METR’s randomised study of July 2025 measured one outcome. Sixteen experienced open-source developers, working 246 real issues on repositories they knew well, took 19% longer with AI tools than without. They had expected to be 24% faster, and afterwards still believed they had been 20% faster. The gap between how fast the work felt and how fast it was went unnoticed by the people doing it.

Veracode tested more than a hundred models in 2025 on coding tasks with a security-relevant choice in them. 45% of the generated samples failed the security test with a weakness from the OWASP (Open Worldwide Application Security Project) Top 10. Java was worst at 72%, and “security performance remained flat, regardless of model size or training sophistication”. Code that runs is not thereby secure, and these flaws were found by a scanner, not by reading. The figure places separate observations about review and incidents beside practices we recommend from the evidence.

Where review reaches its limit

Human review is where organisations expect to absorb all of this, and the published practice is candid about its limits. Sourcegraph’s 2026 guidance on AI code review observes that “a tool that sees the diff produces diff-quality comments”: a forty-line edit can be pronounced clean while the contract it broke sits in another file. It warns that the cost of false positives is the team “learning to skip past every comment the tool ever leaves”, and it keeps the human reviewer as “the layer that catches ‘this is technically correct, but the wrong thing to build’”. These are warnings about review tools, rather than measured outcomes at Honeycomb.

A reviewer’s attention is a fixed resource, and Honeycomb’s record shows the flow of change into it more than doubling. Whatever the reviewer is asked to catch that a rule could have caught is attention taken from the judgement only a person can supply.

What follows for engineering teams

We draw four recommendations from these findings and the cited engineering guidance. The first follows from DORA’s control systems and Veracode’s scanner results. The other three are our synthesis from the guidance; the cited studies do not prescribe them.

Move the rule-shaped checks into the path. Security scanning, dependency policy, naming and structural rules, test coverage on new code: these can be stated as rules and run on every change before a person reads it. A reviewer should not be the first line against a cross-site scripting flaw that a scanner would have caught.

Set the depth of review by the risk of the change. A change to a log message and a change to an authorisation check should not receive the same review. Deriving the risk from the change itself, rather than from who wrote it, keeps routine work moving and risky work scrutinised.

Keep each change small enough to understand. Keeping changes small can make review more tractable, and the “almost right” code that two thirds of developers name as their biggest frustration is easier to see in a change one person can hold in mind. Reviewers still need checks against the requirements.

Attach the evidence to the change. The tests that ran, the commands and their output, the checks that passed and the ones set aside. A reviewer who can see what was verified reads for judgement instead of re-verifying.

DORA’s and Honeycomb’s findings point the same way: the tools amplify whatever surrounds them. Where the checks run, and how much arrives at once, is what a team can decide.