AI Broke Code Review. Both Fixes Still Look at the Code.

There's a debate playing out among experienced engineers right now, and it's a good one, because both sides are arguing from the same honest premise: AI-generated code has broken code review, and pretending otherwise is no longer tenable. The numbers make the case better than any opinion could. The 2026 DORA report finds that 90% of developers now use AI at work, and that they're merging 98% more pull requests than in the pre-AI era. Meanwhile one analysis of ten thousand developers found incidents per pull request up 243%, and bugs per developer up 54%. More code, arriving faster, breaking more.

The diagnosis that follows is one we've made ourselves: human code review has quietly become theater. No reviewer can meaningfully audit a forty-thousand-line, agent-generated pull request. They weren't part of the reasoning that produced it, they can't hold all of what it changes in their head, and the approval they give is, increasingly, a polite fiction. When the person closest to the problem admits the review is a rubber stamp, the review is a rubber stamp.

So the debate has moved on to the interesting question: if human review is broken, what replaces it? And this is where two credible camps have formed. One says the answer is better human process. The other says move the quality gate off the human's desk and into the delivery pipeline — policy-as-code rules that every deployment is automatically checked against, so humans only handle the exceptions. It's a genuinely useful idea, and a real improvement over pretending the rubber stamp means something.

But step back and look at where the entire debate is standing, and something becomes clear. Both answers are looking at the code.

Two ways to inspect the answer

Human review and verified pipelines are, underneath, the same kind of thing: a mechanism for inspecting code after it has been generated, to decide whether it's allowed through. One uses a person, the other uses a policy engine. One is overwhelmed and the other scales — which is exactly why the pipeline is the better of the two. But both operate at the same moment in the lifecycle: after the code exists, checking the code against a set of rules.

That's fine for the class of problem they're built for. A verified pipeline is excellent at catching \"this code violates a deployment standard,\" \"this introduces a known vulnerability,\" \"this doesn't meet the coverage threshold.\" Those are real defects and catching them automatically is a clear win. If your problem is that bad code is reaching production, a policy pipeline is a better answer than a tired human, and the debate is right to land there.

The trouble is that the most expensive failure in AI-native software isn't bad code. It's perfect code for the wrong thing.

The question neither fix asks

Consider the forty-thousand-line pull request again. Suppose it's clean. It passes every policy-as-code rule. It meets the coverage bar, introduces no known vulnerability, violates no deployment standard. The pipeline goes green. By the terms of the entire human-versus-pipeline debate, this is a success — the gate did its job, no human had to rubber-stamp anything, the code is verified.

And it can still be completely wrong. It can be a flawless implementation of a feature the business never prioritised, built against a requirement that architecture and security never reconciled, satisfying an assumption nobody actually agreed to. The pipeline verified that the code obeys your rules. It said nothing about whether the code obeys your intent — because your intent was never captured as anything a pipeline could check against. Policy-as-code knows your deployment standards. It does not know what your organisation agreed to build, because that agreement lives in meetings, decks, and memories, not in a rule the pipeline can evaluate.

This is the blind spot the whole debate shares. Human review couldn't catch \"we built the wrong thing\" — a reviewer approving a diff has no view of what was agreed upstream. And the verified pipeline can't catch it either, for the same reason: it's checking the code against rules, and \"is this what we agreed to build\" was never one of the rules, because nobody wrote the agreement down in a form a gate could read. We moved the quality check from an overwhelmed human to a tireless pipeline and kept it aimed at exactly the same target: the code, after the fact, against the rules. We never moved it to the target that actually broke.

The gate that belongs upstream

The reason code review broke isn't really that humans got overwhelmed, though they did. It's that AI severed the last connection between the code and the reasoning behind it. When a human wrote code slowly, the review was also, quietly, a check on intent — the reviewer engaged with the requirement deeply enough to notice if it made no sense. Generation removed that. Now the code arrives with no human having reasoned about whether it should exist, and both proposed fixes inspect it without restoring that missing question.

The check that's actually missing is not downstream of the code. It's upstream of it. Before the agent generates forty thousand lines, there is a question that determines whether any of them should be written: has the organisation agreed, and recorded, what this is supposed to be? Not the deployment rules — the intent. What the business decided, what constraints security and legal set, what was actually committed to, and by whom. If that agreement exists as a real, canonical artifact, then the build can be held against it, and \"this is a perfect implementation of something nobody agreed to\" becomes catchable — at the point of generation, before the expensive run, rather than after it's passed every downstream gate.

That's a different layer than the one the debate is fighting over. Policy-as-code verifies the code against the rules, and it should — keep it, it's the better answer to the question it addresses. But above it sits the question it can't reach: does this match what we agreed to build? Verifying the code against the agreement, not just against the deployment standards, is the gate that actually addresses why review broke — because it restores the check on intent that generation removed.

Have the debate. Then look up.

The human-versus-pipeline debate is worth having, and the pipeline side is largely right within its own terms. If you're choosing between a rubber-stamp review and a verified delivery pipeline, choose the pipeline. But don't mistake winning that argument for solving the problem. Both options are ways of inspecting the code, and the code was never where the expensive AI-era failure lived. The expensive failure is the wrong thing, built perfectly, and you cannot catch the wrong thing by looking harder at the code — with a human or a policy engine. You catch it by checking the code against the agreement, which means having an agreement worth checking against in the first place. That's the gate the whole debate is standing one floor beneath.