Nobody Asked You to Read It
I went looking for the rule that says a human has to read the code before it ships. It does not exist.
The implementation took an afternoon. The review took most of a week. I have stopped being surprised by that ratio and started being annoyed by the reason we all give for it. Someone has to be accountable. A human has to look at it and say the words. That is the rule, and the rule is why work now sits in review longer than it took to build.
I went looking for the rule. It does not exist, not in the form anybody means. There is no statute, standard, or framework in general commercial software development that requires a human being to read the lines of a change before it ships. What the regimes that actually bind you ask for is something narrower and much cheaper to provide: a documented control that operated, and a named person answerable for the outcome. We have been paying for the expensive version of a requirement nobody made.
Does the EU AI Act require human code review?
The EU AI Act comes up first in every one of these conversations. Its human-oversight duty is Article 14 (opens in a new tab). It binds high-risk AI systems, and what it asks is that a person can oversee such a system while it runs, understand its output, override it and stop it. It has nothing to say about using a coding assistant to write an ordinary service. If you are building a system that screens job applicants, you are in scope for what that system does. You are not in scope for how you typed it.
The high-risk obligations are also not live yet. The Digital Omnibus on AI (opens in a new tab), adopted in July 2026, moved Article 14 and the rest of the high-risk requirements out to December 2027 for standalone high-risk systems and August 2028 for the ones embedded in regulated products. The stated reason was that the standards and the national authorities were both late.
Two provisions come close. Paragraph 5 of Article 14 does mandate human verification, but only for remote biometric identification, where at least two trained people have to separately confirm a match before anyone acts on it. Unless it is a policing or border case, where the law can decide that is disproportionate. And Article 17 (opens in a new tab) requires a quality management system covering design control, design verification and development, for high-risk systems only. That one makes your verification process an auditable artifact. Neither provision says a human must read the code.
The new Product Liability Directive (opens in a new tab) is the better guess and it is still the wrong one. For products placed on the market from 9 December 2026, software is explicitly a product and whoever develops it can be treated as a manufacturer. That sounds like it lands squarely on this argument until you notice it is strict liability. Defect, damage and causation are the elements a claimant has to prove. Negligence is not one of them, so nobody needs to show your team was careless.
Your review practice still does evidential work on whether the product was defective, but you are not liable for the practice itself. And the damage anyone can actually recover stops at death, injury, physical property and data you were not using for work. That leaves out pure economic loss, which is most of what software failure costs.
So the two instruments everyone reaches for are the wrong ones. The regimes that do set a standard for process turn out to be on your side.
What PCI DSS and SOC 2 require
PCI DSS (opens in a new tab) requires that bespoke and custom software be reviewed before release. Requirement 6.2.3 also says those reviews may be performed using manual or automated processes, or both. The additional conditions about a reviewer who is not the author, plus management approval, hang off 6.2.3.1 and the manual path specifically. A mainstream compliance regime, in force today, already accepts automated inspection plus a documented named approver in place of a human reading the code.
A SOC 2 auditor does not read every change. They request the population and sample it (opens in a new tab), sized to how often the control runs and how big the population is, which for something as constant as change management runs to a few dozen items. No standard sets that number, which is its own tell. Then they test whether the control you described actually operated on the ones they picked. The object of proof is the control, not the code.
Intercom did the sensible thing and asked before scaling rather than after. They engaged their auditors early, across SOC 2, HIPAA, ISO 27001 and ISO 42001, and published what they were told (opens in a new tab): the evidence an auditor expects to see is the same whether a human or an AI approved the change.
The product changes that caused outages in their past were all reviewed and approved by humans. Human review was never a guarantee of safety. It was a guarantee of attribution.
How the Linux kernel handles AI-assisted patches
The Linux kernel is not an organisation anyone accuses of moving fast or trusting machines. Agreed at the 2025 Maintainers Summit and merged in January 2026, its convention for AI-assisted contributions (opens in a new tab) is one line long, and it is the cleanest thing anyone has written about this.
An Assisted-by: trailer discloses that a model helped write the patch. The human still adds their
own sign-off, because only a human can certify the Developer Certificate of Origin, and the human
takes full responsibility for the contribution. The
original proposal used Co-developed-by (opens in a new tab), and the maintainers
replaced it, because that tag implies a collaboration between authors and this is assistance. Tools
are disclosed, not credited.
They went further in 2026 and
stopped recording which model was used (opens in a new tab)
at all, on the stated grounds that naming it hands free advertising to proprietary vendors while
adding nothing useful. The trailer is now just Assisted-by: LLM. I find that more interesting than
the original rule. What they wanted was the fact of assistance and a human willing to sign. The
identity of the tool turned out to be noise.
Authorship became machine-readable. Accountability stayed human. The most conservative review culture in software worked out those are two different properties and wrote it down in a paragraph.
Does human code review actually catch bugs?
If the law does not require line-by-line reading, the fair question is whether it works anyway. Meta published the largest answer anyone has put numbers to, in May 2026.
Their system auto-approves low-risk changes behind a risk score, hard exclusions, and a model reviewer that has to state its own confidence (opens in a new tab), and at its peak it handled twenty-five thousand changes a day.
The rate comparisons are the weaker half of that. The system takes the lowest-risk slice by design, so of course the diffs it handles go wrong less often. The finding no comparison group can rescue is about the incidents that did get through:
All PIs were manually reviewed by domain experts and none were deemed to have been detected by a human reviewer.
Examined afterwards by the people best placed to judge, no incident would have been caught by the reviewer whose approval everyone was waiting for. The paper never says how many incidents that was, which is the one number I wanted and could not get.
Bacchelli and Bird (opens in a new tab) saw the same gap at Microsoft in 2013, well before any of this. They watched seventeen developers across sixteen product teams, then hand-classified five hundred and seventy comments drawn from reviews across dozens of Microsoft products. Developers named finding defects as review’s purpose. Defects came fourth out of nine categories. What dominated was code improvements, and after that, people asking what the change was even for.
I used to read that as an indictment, and I now think that is the wrong reading. Those comments are not a failed search for bugs. They are somebody holding a codebase together and teaching the person who wrote the change, and the paper says so directly, listing knowledge transfer and alternative solutions among the outcomes it actually observed. AI did not break code review. It raised the volume until the pretence that review is a defect filter became too expensive to maintain.
When you do still need a human reviewer
In April 2026 the FDA issued a warning letter (opens in a new tab) to a drug manufacturer that had used AI agents to draft specifications, procedures and master production records without qualified review. Challenged on distributing product without validation, the firm explained that the AI agent never told them validation was required. The FDA rejected that outright, and said any output from an AI agent has to be reviewed and cleared by an authorised human in the quality unit.
Under DO-178C (opens in a new tab), review of source code is a certification objective rather than a preference. At the highest assurance level, three of the six source-code review objectives have to be met with independence, meaning somebody other than the author, and one of those still applies a level down. Then there is the part I did not expect. The standard’s own definition of independence lets a tool stand in for the human. Qualify the tool and it counts. So even in avionics, the requirement is separation of responsibility rather than human eyes, and AI-generated code gets no special treatment in either direction.
So the boundary runs between compliance regimes, which have always tested controls and are comfortable with this, and safety regimes, which mandate inspection and show no sign of moving. If you build avionics or drug manufacturing systems, stop here. Everything above is for someone else.
Where auto-approval fails: new joiners and slow rot
Review is not only a filter. It’s a conversation. Why did you do it this way. Did you know we already have a library for that. This is a hand-rolled version of something the framework does out of the box. A senior reading a diff diagonally, at speed, catches a wrong pattern before it takes root. None of that is defect detection or shows up in a revert rate, and none of it means the reading skill stopped mattering. It is the judgment you only get from having survived your own outages, and it is the scarcest thing the team owns.
The trouble with Meta’s numbers is what they cannot see. Reverts and production incidents are fast signals. Rot is a slow one. It does not arrive as a revert, it arrives eighteen months later as a codebase where every change costs more than it should, and no instrument in any study I found can see it. The strongest numbers in this post are silent on the strongest argument against it.
A new joiner does not mainly need their code checked for bugs. They need to be told how we do things here, and review is where that happens. Auto-approving their work would be the most expensive item on this whole list, because you would save a review and buy a year of drift.
The answer is not to go back to reading everything. If judgment is too scarce to spend evenly across changes, it is also too scarce to spend evenly across people. A senior reading a dependency bump at the same depth as a change to the money path is not being rigorous, and the same waste applies to reading a tenth patch from somebody reliable at the same depth as a first one from somebody new. Tier on the author, not only on the diff. Somebody with no track record in this codebase gets read, every time.
For rot, the mechanism is sampling, and it is what auditors already do. Nobody reads every change. Somebody senior reads a random slice, diagonally, looking for drift rather than defects. Unlike a gate it blocks nothing while they get to it. The gate was always a poor instrument for this anyway, because somebody looking at one diff cannot see drift. Reading five unrelated diffs on a Friday afternoon can.
What happens when review thins out
The best-designed study in the field partly contradicts me. Researchers at Carnegie Mellon and Stanford followed 802 developers and 196,212 pull requests (opens in a new tab) at a company that mandated doubling merged changes per engineer. Throughput reached 2.09 times baseline and the load on each reviewer doubled with it.
The reading disappeared. The rubber stamp did not.
Out of every 100 pull requests, what kind of human attention it got before it merged.
The system thinned review out and nothing visibly broke, which is either reassuring or the most worrying sentence in the dataset depending on how much you trust reverts as a proxy for harm. Look at which band moved. Silent approval did not budge. Nobody gave up the habit of waving things through. What the mandate squeezed out was the half of review where somebody actually said something, and where it went was to changes no human opened at all.
Steve Fenton offers a test that will falsify this post for most readers (opens in a new tab) in thirty seconds: count the changes that have passed review but are not yet deployed and enabled for users. If that number is large, your constraint is downstream and none of this is your problem. I suspect that describes more readers than would care to admit it.
METR’s 2025 finding, that experienced open-source developers were 19 percent slower with AI (opens in a new tab) while believing they were 20 percent faster, is the number everybody still quotes. METR have retired it. Their 2026 follow-up (opens in a new tab) has confidence intervals that include zero, because enough developers declined to submit tasks rather than do them without AI, and the authors’ own reading is that AI helps more now than it did then. It settles nothing about review.
Simon Willison (opens in a new tab) got here first, and his framing is the one I keep returning to. The skill is being able to instruct an agent confidently and then verify confidently that the change was made correctly. Sometimes that means reading every line. Often it does not, because eyeballing every line of code has never been the most effective way to validate a change to a piece of software.
How to tell whether your own review gate is leaking
Latency is the wrong first metric. It is the one that will send you hiring. Look at these instead, per reviewer, over time, and look at them together.
- Approval rate. Rising is the warning sign, not the reassurance.
- Comments per review, normalised for change size. Falling while approvals rise is the leak.
- Share of changes merged with no review at all. Faros found this rising 31 percent (opens in a new tab) as teams moved from their lowest to their highest AI adoption.
- Size distribution at the 90th percentile, not the median. The median will tell you everything is fine.
- Time from approval to deploy. If this is your biggest number, stop here and go fix that instead.
- Recall, not precision, on any review tool you buy. On the one benchmark built from 118 real production bugs (opens in a new tab), the best tool caught 48 percent and the weakest 18. It was run by one of the vendors in it, and that vendor won.
The part I cannot answer
Peter Naur argued in 1985 that the durable artifact of programming is not the program but the theory of it (opens in a new tab) held by the people who built it. The uncomfortable part is what he says next. Reading the program text is explicitly not how that theory transfers. It passes between people who work in close contact, which means the gate was never the mechanism we told ourselves it was. Sampling keeps the theory alive in somebody. At three in the morning six months later, the person on call is whoever is on call, not whoever happened to draw the lucky diff.
The people in the most pain went the other way entirely. Facing a flood of machine-generated contributions, open-source maintainers throttled arrivals instead of relocating the gate. Daniel Stenberg closed curl’s bug bounty (opens in a new tab) after nearly seven years. GitHub shipped limits on open pull requests per user (opens in a new tab). They asked for fewer arrivals and more funding, not for a smarter gate.
If Naur is right, what replaces the gate is contact rather than inspection, and a change reviewed as it is written by somebody sitting alongside has no queue to sit in at all. I cannot point you at a study proving that works in the agent era. I looked.
Tie the approval to the on-call pager
The law never asked you to read it. It asked you to be answerable for it. For thirty years, reading was the cheapest way to be answerable.
The most useful mechanism I found is one clause in Meta’s eligibility rules (opens in a new tab). Automated approval requires that the author have an associated operational on-call rotation. The machine may approve your change only if you are the person who gets paged when it breaks.
Everything else in this debate tiers on properties of the change. Size, path, risk score, blast radius. That one tiers on a property of the human, specifically whether they are exposed to the consequences. If review’s real product is accountability rather than defect detection, a second pair of eyes is a remarkably indirect way to buy it and the pager is a direct one. It also answers the FDA’s implicit question better than any attestation format, because “the agent never told us” is a defence only available to someone insulated from what happens next.
What to have in place
- Write the exclusions as code, not as culture. Auth, secrets, tenant boundaries, money, and migrations always get a human. Everything else earns its tier.
- Name the approver in the record, every time, whether the approval came from a person or a system. Attribution is the thing auditors sample for.
- Disclose machine authorship in the commit trail. The kernel’s one-line trailer is the pattern.
- Gate the automated path on the author carrying the pager for what they just shipped.
- Tier on the author as well as the change. No track record in this codebase means a human reads it.
- Sample. Somebody senior reads a random slice of merged diffs, looking for drift rather than bugs.
- Ask your auditor before you scale, not after. Intercom’s whole advantage was sequencing.
- Put recall next to every precision figure a vendor shows you. These are filters, not substitutes.
- Keep a human reading anything irreversible. Rollback substitutes for review right up until the money has moved.