The part of building software that got cheap is the part that was never the bottleneck. Writing the code was rarely the hard bit; deciding what should exist and confirming that what exists is right — those were the hard bits, and neither of them got faster. So the queue moved. Everything downstream of the keyboard is now the constraint, and the first thing downstream of the keyboard is review.
What interests me is not that there is more to review. It is that the thing arriving at the gate changed shape, and the reviewing skill that worked on the old shape does not transfer cleanly. This is a note about what actually changed and what I do about it.
The finding I cannot stop thinking about
In June, a group of researchers published a longitudinal study of how humans review pull requests submitted by AI coding agents. They tracked 400 repeat reviewers across 11,429 reviews over seven months, and asked a simple question: does scrutiny hold up over time?
It does not. Approval rates rose from 30.1% to 36.8%. Inline comments — the direct measure of how much reviewers actually engaged with the code — fell 22%. Review latency increased three and a half times. And the effect intensified with exposure: comparing reviewers in the first decile of experience with AI-generated pull requests to those in the tenth, approval rates differed by 14.5 percentage points.1
The obvious charitable reading is that reviewers learned the code was usually fine and calibrated accordingly. The authors considered it and rejected it. Their conclusion is that the combination of rising approval, declining comment effort and increasing queue time is "most consistent with reflexive habituation under growing workload rather than rational trust calibration alone."1
Habituation, not calibration. Reviewers did not conclude the code was good. They got tired, the queue got longer, and approving became the path of least resistance. The waiting went up three and a half times while the looking went down — which is the signature of a queue, not of learning.
I take this personally rather than as an industry statistic, because I have no reason to think I am exempt. Nothing in that study describes a failure of diligence. It describes what happens to ordinary conscientious people when volume rises and the thing in front of them looks fine.
Why this is a different skill
When I review a colleague's pull request, I am not really reviewing code. I am reviewing a person's reasoning, and I have a model of that person. I know what they are careless about at the end of a long week. I know which parts they will have thought hard about and which they will have copied from the file next door. Crucially, their mistakes are correlated — with their experience, their fatigue, their familiarity with that subsystem. And the code carries signals: hesitation in the naming, an over-complicated branch, a comment that sounds unsure. Sloppiness is legible, and legible sloppiness tells me where to look.
Generated code strips all of that out. There is no mind behind it to model, no fatigue curve, no subsystem it is less comfortable in. The output arrives uniformly confident and uniformly well-formatted, which means the surface signal I spent fifteen years learning to read is simply absent. Bad generated code and good generated code look the same.
The errors are also differently shaped. The characteristic failure is not a typo or an off-by-one; it is something locally impeccable and globally wrong — a function that does exactly what it says while being the wrong function to have written, an abstraction that duplicates one three directories away, a plausible handling of a case that cannot occur alongside silence about the case that can. These are not defects you catch by reading more carefully. They are defects you catch by holding more context than the diff contains.
What the codebases show
The aggregate evidence matches the shape of that claim. GitClear's analysis of 623 million code changes from 2023 to 2026 tracks maintainability signals across the period AI-assisted commits went from marginal to roughly a quarter of all commits.2 Duplicated code — five or more consecutive repeated meaningful lines — is up 81% against pre-AI levels. Code movement, the signal that someone edited what already existed rather than adding beside it, is down 70%. Refactoring of legacy code, meaning anything untouched for a year or more, is down 74%. Functional connectivity, how much new code calls existing code, has fallen 35%.
And the one I find most pointed for a discussion of review: error masking is up 47%, measured as rescue and catch blocks, safe-navigation operators and stubbed methods.2 Code that quietly swallows its own failures. That is the exact category of defect a reviewer is supposed to exist to catch, and it is rising.
Here is the connection that matters. Every one of those signals is invisible in the diff that creates it. A duplicated block looks like perfectly good new code in the pull request that introduces it — the duplication only exists in relation to a file nobody opened. A missing call to an existing helper is an absence, and absences do not appear in diffs. Legacy code not being refactored is, by definition, code that is not in the change.
The failure modes of generated code are cross-file and cross-time. Review is per-diff and per-moment. That mismatch is the structural problem, and no amount of reviewing harder inside the diff will close it.
The number that should worry you most
DORA's 2025 report, drawing on nearly 5,000 technology professionals, found something that had changed since the previous year and something that had not. What changed: the relationship between AI adoption and delivery throughput, negative in 2024, turned positive. Teams learned to use the tools. What did not change: AI adoption continues to have a negative relationship with delivery stability.3
Throughput caught up. Stability did not. And stability — change failure rate, time to restore — is precisely the thing the review gate exists to protect. DORA's own explanation is that acceleration exposes weaknesses downstream, and that organisations without strong automated testing, mature version control and fast feedback loops find that more change volume simply produces more instability.3
Which is a polite way of saying: the gate is where the acceleration is being paid for.
What I actually do
Six things, and the first three are changes in what I read for rather than how hard I read.
Review intent before implementation. The first question is no longer "is this correct?" but "should this exist, in this shape, here?" Correctness is the thing generation is best at and the thing the tests can partly cover. Whether a thing should exist at all is the thing generation has no opinion about, because it was not in the room when the decision was made.
Read the seams, not the centre. Interfaces, error paths, deletions, configuration, anything touching a boundary between two systems. The middle of a generated function is usually fine. The place where it meets everything else is where the model was working from the least context — and where I am working from the most.
Distrust tests that came from the same process as the code. A test written alongside the implementation by the same generator tends to encode the implementation's assumptions rather than the requirement's. It will pass. It will also pass if the implementation is wrong in the way the generator was wrong, because the error is in both. Circular verification is not verification, and this is the same structural problem I wrote about in prompt injection — you cannot use a system to check the thing that system produced.
Grep for the masking patterns. Empty catch blocks, broad exception swallowing, safe-navigation operators sprinkled where a null should be impossible, methods stubbed and forgotten. That 47% figure is a list of things a machine can find in seconds and a human will skim past at eleven at night.
Give the cross-file problems to machines and keep the per-diff judgement. This is the split I would defend hardest. Duplication detection, dead-code analysis, dependency and connectivity checks, coverage of changed lines — these are exactly the cross-file, cross-time properties human review is structurally bad at, and exactly what static analysis is good at. Conversely, "should this exist" is not automatable and never will be. Most teams have this backwards: humans grinding through mechanical checks in a diff view while nothing at all is looking at the shape of the codebase.
Fight habituation structurally, because willpower will lose. This follows directly from the study. If declining scrutiny is a workload effect rather than a character flaw, then resolving to concentrate harder is not a control. Capping how much any one person reviews in a sitting is a control. Rotating who reviews which subsystem is a control. Sampling merged changes for a proper second look, after the queue pressure is gone, is a control. Designing the queue so it does not grow unboundedly is the best control, and the least popular, because it means generating less.
[ PLACEHOLDER: your actual review policy at Gigabit — what gets human eyes, what gets automated gates, what the merge requirements are, and what you have been burned by. The "what we got wrong" specific is the one that will make this land; a policy without a scar reads like a blog post. ]
The cost, stated honestly
Reviewing well is now slower per unit of code than it was, and I think that is correct rather than a problem to optimise away. If your team's generation throughput went up several-fold and your review time did not go up at all, nothing has been reviewed — the work has just moved from a place where it was visible to a place where it is not, which is production.
This is also the honest answer to the question I get from clients about whether AI-native delivery means lower quality. It does not have to. But the quality has to be bought somewhere, and the place it gets bought is here, at the gate, in the least glamorous part of the process. Any shop claiming several-fold output with an unchanged review process is describing a debt, not a capability.
Review is where taste stops being an abstraction and becomes a decision with a timestamp. Ten plausible implementations arrive; the judgement about which one belongs in the codebase is the same judgement I wrote about there, exercised under time pressure, in public, on someone else's schedule. That is a demanding place to keep your standards. It is also the only place they are actually visible.
The honest caveat: the habituation study is a single seven-month observation of open-source repositories, not a controlled trial, and open-source review culture is not enterprise review culture — the finding is strong and it is one finding. The GitClear metrics are correlational across a period in which many things changed besides AI adoption, and the firm publishing them sells tooling in the space, which is worth knowing even though the methodology is public and the dataset is large. I have cited them because they point the same direction as what I see, and I would rather say that plainly than pretend a coincidence of evidence and experience is proof. What I am confident about is narrower: the gate is where the acceleration gets paid for, and most teams have not yet raised the price.