Before I accept AI-produced code, I ask who checked it, and whether they had any stake in it being right.
When a person writes code and then reviews their own code, they find the bugs they were already worried about and miss the ones they never considered. A language model is worse at this, not better. It produced the work from a single chain of reasoning, and when you ask it to review that work, it re-runs much the same chain and arrives, reassuringly, at the same place. Self-review by a model is a mirror, not an audit.
So at SeraphimGate Systems we stopped allowing it. For about a year now, substantive code written with one AI model has been reviewed by a different model, from a different vendor, before it is called complete, pushed, merged, or deployed. Code drafted with Anthropic's Claude is reviewed by OpenAI's Codex. Code drafted with Codex is reviewed by Claude.
How the review gate works
The reviewer is read-only. It can inspect the change and run things, but it cannot edit. The author remains the only writer, which means the author has to answer the review rather than quietly patch around it. Each review returns one of three verdicts: approve, concerns, or blocked. The verdict is recorded as a receipt bound to the exact set of changes it looked at, so if a single line moves after the review, the receipt goes stale and no longer counts. A release gate refuses to proceed on anything but a current approval. Documentation, generated files, and purely mechanical edits are exempt. Everything else goes through.
Static review is not a substitute for tests, and we say so in the tool's own documentation. It is a second pair of eyes that did not write the thing and does not share its author's assumptions.
Two models from the same family, trained on overlapping data with overlapping blind spots, will often agree with each other for the wrong reasons. A model from a different lineage disagrees in more useful ways.
What it has caught
When we hardened our own public-facing infrastructure earlier this year, we ran the second model over about five repositories. It raised roughly two dozen findings. Nearly every one was real. Among them: a rate limiter that, sitting behind a tunnel, saw every visitor arriving from the same address and had quietly collapsed into a single global bucket, so one careless client could throttle everyone. A container that published a port on every interface when it should have been reachable only through the tunnel. Personal data landing in request logs. A request-origin check that could be bypassed simply by omitting the header it was checking. None of these were exotic. All of them had survived the original author's review, and the original author in each case was a capable model that had been told to be careful.
A separate release of our orchestration tooling went through six rounds of substantive review. The review found four real defects, two legitimate concerns, and one place where we had misdeclared the scope. We disproved one additional claim with evidence. Every one of the four defects lived in the guard code, the part of the system whose entire job is to stop bad things from happening. A piece of valid but unexpected input crashed a hook that was supposed to block an unsafe stop. A cleanup block deleted the only copies of files it had just overwritten, after a rollback had failed partway. These are the failures that matter most and that an author is least likely to find, because the author was thinking about the happy path when they wrote the guard.
A scanner that was supposed to stop secrets from leaking into a review packet had been tested against a single-file change, where it worked. Against a multi-file change, it failed open and let everything through. One model wrote it, tested it, and shipped it. The other model asked what happened with two files. The fix took ten minutes.
The reviewer is wrong sometimes too
The second model once flagged a file as truncated and therefore unsafe. It was reading the edge of the diff context window, not the edge of the file. We showed it the whole file parsing cleanly, four times, and the concern was withdrawn. That exchange led us to narrow how much surrounding context a reviewer sees, which cut false alarms without cutting catches.
In our reviews, the model usually identifies real defects but often overstates their severity. It flags defensively, because it has no deployment context. It does not know that the port it is worried about sits behind a firewall, or that the input it fears is impossible given what produces it. Severity ranking stays a human job.
Where we got it wrong
Declare the stop condition before the round starts. One release went through four review rounds. They found a settings-preservation bug, a path grammar bug, a spelling mismatch in a detection string, and a preflight check nobody had asked for. The findings were valid, but the process ran too long, and I stopped it by hand. Now every round has a declared exit: approve or concerns ends the loop, and a fresh block goes to a person rather than automatically triggering another pass. Small changes close fast. A one-line fix recently cleared in a single round.
A receipt that says "infrastructure failure" can be hiding something else. Twice we mistook a review failure for a capacity problem and prepared to retry with a smaller scope. In one case, our own validator had rejected a completed review's legitimate blocked verdict because of how its findings were ranked. In the other, the reviewer's configured default model had been changed under us to one our account could not use, so the review never ran at all. In both cases the large change made "too big" sound plausible, and we nearly shrank a review that had nothing wrong with its size. We now reproduce the underlying call directly before concluding anything about capacity.
Tie the receipt to the protocol, not just the code. A receipt recorded which lines were reviewed but not what the reviewer had been shown. When we improved the review packet, receipts produced by the weaker older packet still read as current. The fix was to version the protocol itself, so any change to what a reviewer sees invalidates every receipt in every project at once.
Why a business should care
If you are hiring anyone, human or otherwise, to build something your operation will depend on, the question of who checked the work is not a technicality. The review process is part of what you are buying. A convincing explanation is not evidence. A green test suite is evidence about the cases someone thought to test. An independent reviewer with no stake in the original being right is a different kind of evidence.
If you commission an AI-produced system, ask who reviewed it and what they found. Talk with us about applying this review process to your project.