Ask an AI agent to fix a bug and it will usually fix it. Then it will tell you it’s fixed, and that the tests pass. Most of the time that’s true.
Most of the time isn’t good enough for software a business runs on. The question a client should ask isn’t whether AI wrote the code. It’s who checked it, and whether that check could be fooled by the same mistake that made the bug.
At Moonfive the answer is a rule we don’t bend: the agent that builds a change never reviews it.
One night, 23 batches of work
Most of our engineering work is now built by AI agents. An agent picks up a written-up issue, works on the code, runs the tests and opens a change for review. That’s a lot of work moving quickly, and it needs a gate that moves just as quickly without becoming a rubber stamp.
On one night in October we gave agents 23 batches of internal work to build and review on their own. The logs from that night show what the gate does. In 12 of the 23 batches, the reviewer found something that had to be fixed and reviewed again. In one more, it stopped the work outright.
That stop was a layout problem on a password reset page. The fix looked simple, but the cause sat in a shared component library that several of our products use. Patching it in one product would have hidden the real problem in all the others, so the reviewer didn’t pass it. It handed the decision back to a person, and the whole feature waited for that call.
Why “check your own work” doesn’t work
The obvious shortcut is to ask the building agent to review its own change before handing it over. It’s cheaper and faster. It also misses the mistakes that matter most.
An agent checking its own work brings the same assumptions that produced the work. If it misread the issue, it reads the code against the same misreading and finds nothing wrong. Its summary of what it did is a claim, and a claim checked by the author is still just a claim.
So the reviewer starts fresh. It shares none of the builder’s working context. It gets the issue, the change and the code, and it reads what’s actually there rather than the builder’s account of it.
What every change has to get past
- A separate reviewer for every change. A fresh agent reviews each change against the issue it’s meant to close. Often a smaller model builds and a stronger one reviews, so the more expensive judgement goes where mistakes are caught.
- Tests that prove they test something. A passing test isn’t enough on its own. For a bug fix, the reviewer checks that the new test fails when the fix is taken out. On that October night one change was meant to stop two saves overwriting the same record. The first review found that nothing tested the protection: remove it and every test still passed. A test was added, and the second review confirmed it now failed without the fix.
- Test results the agent can’t write. Our test runner keeps its own record of every full run, tied to the exact code it ran against. The reviewer cites that record. It never takes the builder’s word that the tests passed.
- A verdict that covers one exact version. If anything changes after a review, even a one-line fix, the old verdict no longer counts and the change is reviewed again.
- Proof in the real app. Where a change affects what a user sees, the reviewer runs the app and goes through the actual screen instead of assuming the tests cover it.
- A person at the end. The review stops at “ready to merge”. Agents don’t merge into the main code, deploy or touch a client’s live system. Each of those needs a person to say yes, for that change and that site. Approval for one site never carries over to another.
What review costs, and why we pay it
Review costs something. Every change gets read twice, and on that October night about half the batches had something sent back. We kept it because what it catches is the expensive kind of mistake: a fix that looks right, passes its tests and protects nothing.
It also changes what a client is trusting. You don’t need to trust that an AI agent got it right. You need to trust the gate, which is a fixed set of checks that runs the same way on every change, plus a person who decides what goes live and when.
Cheap code needs more checking, not less
AI hasn’t changed what makes software safe to put live. It’s still independent review, tests that would catch the bug coming back, and someone accountable for the release. What it has changed is how cheap the first draft is. When building gets that cheap, checking is where the time should go.
Ready to talk about the software your business runs on?
If you’re relying on a system nobody independently checks before changes go live, that’s worth a conversation before something breaks rather than after.