Agentic Engineering
Cross-model AI code review: who checks the AI's work?
By default, the model that wrote the code does not sign it off alone. A model from another provider reads the change, ranks what it finds, and a bug blocks the merge.
In plain English
Cross-model review means one AI writes the code and a different AI, from another provider, checks it. We do this on our own website and write down the result. The reviewers read the change. They do not edit it.
How deep the review goes depends on the risk. The ladder and the three review tiers are on how we work.
How a review runs
- An AI agent writes the change. Mostly Claude Code, sometimes Codex.
- A model from another provider reviews it. Codex on Claude-written work. GLM 5.3 is the standing second reviewer.
- Findings are ranked. BUG, RISK or NIT, so everyone sees what matters.
- Fixes are reviewed again. Each pass is a round. The trail records every round.
- A person decides. By default, the change merges only when no bug is open.
What the three labels mean
- BUG: the change does something wrong. It blocks the merge until we fix it or show that it is not a bug.
- RISK: something that could go wrong in ordinary use. We fix it, or the owner decides to accept it.
- NIT: a small point. It never blocks.
We review plans as well as code. For risky work, one reviewer is told to attack the plan before we build: how it fails, how it could be misused, how it could lose data, and whether we can roll it back. The steps are on how we work.
Anthropic's own Code Review for Claude Code (opens in a new tab) works the same way in one respect: it ranks bugs by severity and does not approve pull requests. That stays a human call.
What it looks like in numbers
47
pull requests reviewed and recorded in our repository, as of 2 November 2026
We counted the pull requests in our website repository that have a written review trail. Each counts once, however many rounds it took. Not every pull request has a trail. These 47 do. The trails live in our private repository.
What a review catches
In one recent review of our redirect change, Codex found two lines that would have failed our own local check. The AI that wrote the change had reported that check as passing without running it. The reviewer caught it before the merge.
A public review, mistakes included
You can check this one yourself. Pull request #355 (opens in a new tab) in Croftweaver's public repository rewrote a README. It was prose for people, so it got our light gate: Codex alone. The pull request records 201,518 tokens for the three rounds. That is one change, not a rate.
One public review, three rounds
- Round 1 1 bug, 3 risks, 1 nit. The bug is about the README's "by default" claim.
- Round 2 Clean.
- Round 3 The same bug again. The same code answered it again.
Gate: Light, Codex alone. 201,518 tokens, as the pull request records them.
The bug said the README overstated when it claimed the starter's tests
check every change by default, because the starter's CI skips changes that
only touch documentation. The reviewer was right about CI. It missed the hook. A plain
npm install also sets up a pre-push hook, and
that hook (opens in a new tab)
runs the check and the tests on every push that carries commits. It
checks the files in your working tree, not the commits being pushed. It
holds when the site is at the root of its own repository, the install
showed no hook warning and nobody passes --no-verify. For
an ordinary push, the README's claim stood.
We show it because it is not a clean story. A reviewer's finding is a claim to check, and here the hook's code answered it, twice.
A review is not a guarantee. Reviewers miss things, and a tool can fail: when a reviewer fails to run, we record it as failed, not as a review. Tests, a second reviewer, and an engineer on risky changes cover other gaps.
Agreement is not independence
Two reviewers that agree are weaker evidence than they sound if they miss the same things. Picture each reviewer's blind spots as a circle. What sits where the circles overlap, both reviewers miss.
Each reviewer's blind spots
Checks that depend on neither model
- Tests
- The written requirement
- A person who reads the code
Two overlapping circles. Each circle is one reviewer's blind spots. The overlap is what both miss. Beside them: tests, the written requirement and a person, which do not depend on either model.
Frequently asked questions
Why not let the same model review its own code?
A model that reads its own change back may follow the same reasoning that produced the mistake. A model from another provider was trained differently, so we expect it to read the change another way. That is our reasoning, not a measured result.
Does AI review replace a human code review?
No. It catches problems before a person looks, so the person can spend their time on design and risk. On risky changes an engineer still reads the code.
How long does a review round take?
In two page changes in November 2026, each reviewer took between half a minute and four minutes per round. Those changes needed three and four rounds before no bug was open.
Can two AI models miss the same bug?
Yes. Two models can share a blind spot, most of all when they are built and trained alike. We expect reviewers from different providers to overlap less. That is our reasoning, not a measured result.
What should overrule an AI reviewer?
A failing test, the written requirement, or an engineer who has read the code. A finding is a claim to check, not a verdict.
Related reading
How we work with AI agents, agentic engineering, not vibe coding, and a production-readiness audit for an app that AI built without this kind of review.