Stop Reviewing the Code. Nobody Changed the Spec.

Walk into any mature engineering organisation and you will find an elaborate, well-defended apparatus for protecting quality. Pull requests require approvals. Linters block on style violations. CI runs the test suite before anything merges. Two reviewers, sometimes three, read the diff and leave comments. Enormous care, enormous discipline, all of it pointed at one target: the correctness of the code.

Now ask a question that the apparatus never asks of itself. The specification that all this code implements — the requirement the reviewers are checking the code against — who reviewed that? When was it versioned? Who signed off on it? Where is the record of the agreement it represents?

For almost every organisation, the answer is a shrug. The spec arrived as a ticket, or a paragraph in a document, or a sentence in a stand-up. Nobody reviewed it with anything like the rigour applied to the code that implements it. We inspect the answer obsessively and never check the question.

The thing code review cannot catch

This asymmetry was always a little strange, but it was tolerable, because when humans wrote the code slowly, the act of implementation was itself a kind of spec review. A developer building a feature by hand would routinely notice that the requirement made no sense, contradicted something else, or couldn't mean what it appeared to mean. The slowness of construction forced a human to engage with the specification deeply enough to catch its flaws. Spec review happened — informally, invisibly, as a side effect of the labour of building.

AI removed the side effect. An agent does not pause at an incoherent requirement and raise an eyebrow. It builds exactly what the specification says, flawlessly, at full speed — including when the specification is wrong. And here is the part that should genuinely worry anyone who trusts code review: when the agent produces clean, correct, well-structured code for the wrong requirement, every reviewer approves it. Of course they do. The code is correct. It does precisely what the spec asked. The linter is happy, the tests pass, the two reviewers sign off. The entire quality apparatus gives a green light to a feature that should never have been built — because the apparatus was only ever inspecting the implementation, and the implementation was perfect. It was the agreement that was broken, and the agreement was the one thing nobody was reviewing.

We protected the cheap thing and ignored the expensive one

Step back and the misallocation is almost comical. We built rigorous, automated, multi-reviewer governance around the code — the artifact that AI can now regenerate in minutes, the artifact that became cheap. And we built essentially no governance around the specification — the artifact that determines whether any of the code should exist at all, the artifact that became, by comparison, the entire ballgame. We armoured the derivative and left the source exposed.

Consider the failure in concrete terms — illustrative, but recognisable to anyone who has shipped at scale. A requirement is written that quietly contradicts a constraint another team is operating under. It's clear, it's specific, it's wrong. An agent builds it perfectly. It sails through review because there is nothing wrong with the code. It ships. The contradiction surfaces in production, or in an audit, or in a furious message from the other team. The post-mortem asks how this got through review. The honest answer is that it got through code review flawlessly, because code review was never capable of catching it. The defect was upstream, in a specification that no review process ever touched.

Review the agreement, not just the implementation

The conclusion is not, of course, to literally stop reviewing code — the title is a provocation, and code review catches real defects. The point is that code review is now protecting the cheaper half of the problem, and the expensive half has no protection at all. As AI makes implementation reliable, the marginal value of inspecting the implementation falls, and the marginal value of inspecting the specification — the agreement, the requirement, the thing that decides what should be built — rises sharply. The governance has to move upstream to where the consequential errors now live.

That means giving the agreement the things we currently reserve for code: a version history, so you can see how the requirement changed and why. A sign-off, so there's a record of who actually agreed to it. A review, so a wrong requirement gets caught before an agent faithfully builds it. This is the entire idea behind treating the agreement as a first-class artifact, and it's what we built Propel to make routine — to put the spec under the same discipline as the code it generates, so that the question gets checked, not just the answer.

You can keep reviewing the code. Just understand what your reviews can and can't catch. A perfect review of a perfect implementation of the wrong requirement still ships the wrong thing — and no number of approvals on the diff will save you, because nobody changed the spec.

What each kind of review can and cannot catch

• Human code review. Catches a bad implementation. Cannot catch a correct implementation of a wrong requirement.
• AI code review. CodeRabbit and its peers have the same blind spot, faster: they read the diff, not the intent.
• Tests and CI. Prove the code does what it was told. They never ask whether it was told the right thing.
• Spec review. The only one that catches a wrong requirement before an agent faithfully builds it — and the only one most teams do not do.