Two of your three AI review layers only read the code

A feature ships with everything green. The code health score is fine, the test suite passes, a second AI agent read the diff and flagged nothing for a human. The feature also does the wrong thing, because the instruction behind it was ambiguous and everything built from that instruction resolved the ambiguity the same way. Nothing failed. Each gate did exactly what it was built to do.

Coding agents do the whole job in one pass now. You describe a feature, the agent writes the implementation and the tests together, and a pull request arrives with a checkmark on it. On August 10, the Thoughtworks software writer Martin Fowler published an evaluation of what changes when you instruct that agent to work test-first. Test-driven development means writing the expected behavior as a failing test before writing any code to satisfy it. Fowler’s answer came back conditional. The discipline pays off when the tests are written without the implementation in view. When a single agent produces both from one context, he writes, “code and tests derived from the same ambiguous instruction may agree on the same wrong behavior.” A July 2026 preprint supports the requirement: tests generated from a task description, with the implementation kept out of context, detect significantly more faults than tests co-generated beside it.

If you’re merging agent-written code at any volume, you’ve likely assembled some version of the default stack. Three layers. A codebase health gate, from the code-analysis vendor CodeScene: keep the maintainability score above 9.5 out of 10, because below that line the same vendor’s data shows agent-assisted work producing 41% more defects. A test discipline, from Kent Beck, the programmer who codified test-driven development: write the expected outputs first and you get a specification the agent can’t quietly rewrite, which took agent-introduced regressions from 6.08% to 1.82%. And an agent-to-agent review layer, documented by the analytics company PostHog: a separate reviewing agent inspects what the generating agent produced, and only changes touching complexity, architectural scope, or security surface get escalated to a person. It reads as depth. Three checks, each catching what the last one missed.

Verification is independent only as far as its context is. Layers one and three both read the implementation, so the most either can tell you is whether the code is well built. Layer two was the only one that ever encoded what the code was supposed to do, and Fowler’s finding is that it does that job only when it’s written blind to the implementation. In an agent loop, nothing gets written blind unless someone builds the loop that way.

Start with how the two failure modes differ. Beck named an adversarial one: agents delete or rewrite failing tests instead of fixing the logic underneath. Test-first answers that structurally, putting the expected behavior in a contract outside the agent’s edit scope, one that takes deliberate human intervention to change. Fowler’s failure mode never needs the fight. The test already ratifies the bug, and no agent has a reason to touch a test that agrees with it.

The property that made the contract worth having now runs the other way. An immutable specification encoding the wrong behavior is harder to dislodge than a soft one, because changing it takes a human deciding to. The suite is green, so nobody gets handed that reason.

Layer three is where I’d push this further than Fowler did, and that step is mine, not his: he tested test-first discipline inside the agent loop, never agent-to-agent review. But his mechanism is about what sits in the context, and PostHog’s second agent is defined by what it reads: whatever the generating agent produced. That gives you independence of instance: a fresh model, a clean conversation, no memory of writing the code. The implementation is still the whole context, and whatever assumption produced it is sitting there.

A reviewing agent holding the diff can absolutely catch bad code, and bad code is what it’s tuned for. The criteria that escalate a change to a person are complexity, architectural scope, and security surface, all properties of the code’s structure. None of them says anything about whether the behavior is the behavior you asked for. To check that, the reviewer needs a statement of intended behavior, and the only one available is the same ambiguous instruction. Nobody writing this pattern up specifies whether the reviewing agent even receives the original task description, and everything turns on that. It’s the difference between a second boundary and a second look at the same document.

Now walk a wrong-behavior defect through all three. Misunderstood intent leaves the structure clean, so layer one passes. The tests came from the same context as the code, so they encode the misunderstanding and pass. The reviewing agent reads tidy, well-factored code, so none of its criteria fire. Then PostHog’s third mechanism runs as designed: non-flagged changes bypass human review entirely. Ship. Every gate green, and green precisely because the code was clean.

The stack isn’t theater, and the case for it is stronger than this makes it sound. Starting-state code health really does predict how much mess an agent leaves behind. Agents really do rewrite tests to reach green, which is what Beck’s contract prevents. A reviewing agent really does catch architectural sprawl that a person skimming forty diffs a day waves through. All three do real work. They just do the same kind of work, and each does it by reading the code the agent produced.

Beck’s number deserves the same care. 6.08% to 1.82% is the strongest quantified result anywhere in this area, and it counts regressions, meaning behavior that used to be right and became wrong. Code that was wrong at its first commit never regressed. That’s the class Fowler’s shared-assumption mechanism produces, so Beck’s number can be completely true and still say nothing about what Fowler found.

Which leaves the measurement nobody has taken. Aggregate defect rates keep arriving, and they pool both failure classes into one figure. The useful cut is provenance: split agentic changes by whether the test-writing context held the implementation, then count spec-misunderstanding defects separately from bad-code ones. The question queued ahead of it is what instructed test-first costs in latency and tokens, since it takes an instruct, verify, correct loop rather than one pass. Nobody has measured that either. Ask it first and you price the discipline before the failure it prevents, which usually ends with the discipline getting cut. The cut version is the one-pass version that agrees with its own bug.

One test is worth running on your own pipeline before any of that data exists. Name the layer in it that reads the specification rather than the code. If the answer is layer two, when isolated, then you have one specification check, it’s conditional, and the condition is the path your tooling doesn’t take by default. What’s left is one piece of code, inspected three times, and a merge that never reaches a person.