Guides / Building software with AI agents

Why we use two AI models to build and review each other's work

One model reviewing its own work misses things. We had Claude and Codex check each other's work and batched the owner's decisions to what matters.

Engineering note

By Steven Michael Barber · Published October 19, 2026 · Updated November 3, 2026 · 6 min read

Since October 18, 2026, we have used Claude, made by Anthropic, and Codex, made by OpenAI, in the same repository, with one writing changes and the other reviewing them. Steve sets priorities and retains production deployment and the decisions that need the business owner. This guide explains why we set it up that way. The initial setup, the first rule changes and the early results record how the arrangement developed.

A model reviewing its own work

An agent that wrote a change and then reviews it brings the same assumptions to both jobs. If it misread the requirement, it reads the requirement the same way when it checks. If it did not know about some part of the system, it does not know about it during the review either. Asking it to "check carefully" helps with typos and small slips. It does little for the mistakes that come from what the author believed in the first place.

We use a second model to challenge the author's assumptions. It has found useful problems in our changes, including the example below. We have not measured whether using different models is better than using separate sessions of the same model, and two models can still share the same blind spots.

Tests do not replace this. Tests check what someone thought to test. A reviewer asks whether the change does what it says, whether the documentation now tells the truth, and whether the tests check the right thing.

What outside reads had already shown us

Before Codex had access to the repository, the owner sometimes pasted a document into ChatGPT and brought the answer back. These outside reads challenged our documents and even our responses to earlier reviews: one found that a guide still listed an unreleased product under "Try it". That was a concrete statement we could check and correct.

Those reads were useful, but slow and manual. The outside model saw only what was pasted, could not open the code, and its answer had to be carried back by hand. Connecting Codex to the repository turned that occasional outside read into a normal step that every change goes through.

The owner's time is the scarce part

Agents work around the clock and in parallel. The owner does not. Before the change, every merge, every signature on a release record and every production deploy waited for the owner. On a busy day that is dozens of small interruptions, each needing a context switch, and agents sitting idle until the owner gets to them.

Two things reduce that load without removing the owner from the decisions that need an owner.

• Batch the questions. Agents collect questions, options and recommendations into a QnA MD file, and the owner answers them in one sitting. On October 16 the owner worked through 123 questions; the answer log runs from 3:25 to 3:40 p.m. EDT. Our batch questions guide explains the preparation and read-back process.
• Let routine approvals go to the other model. If an independent model has reviewed a routine change and the tests pass, the owner does not need to click merge. That frees the owner's time for the questions only the owner can answer.

With two models the batching matters more, because both of them raise questions. On October 19 one file held seven questions: five about a sign-in design Codex had written, one about file storage that Codex had raised in its handoff report, and one about which to build first. Claude compiled them, and the owner answered all seven within about two minutes by the file's own log.

What stays with the owner

Handing approvals to the other model is only safe if some decisions never move. The owner's written directive lists what agents must escalate, and the delegation rules list what they may never sign, merge or deploy:

• Business ambiguity. When the right answer depends on what the business wants, a model asks. It does not pick the likely option and move on.
• Infrastructure, permissions, secrets and DNS. Changes to cloud resources, access rights, stored credentials or domain records go to the owner, however small.
• Launches and pricing. Making a product public, parking it, or changing a price or plan.
• Legal and policy text. Terms, privacy statements and similar pages.
• Running out of quota. If a model hits its usage limit, work pauses and the owner is told. Nobody quietly switches to a shortcut.
• Mixed releases. A release that contains code from both models has no independent party left to approve it, so it goes to the owner.

When an agent is unsure whether a change falls into one of these, it treats it as the owner's.

Worked example: the first large cross-review

Late on October 18, US Eastern time, Codex opened a pull request that changed 55 files. It added session renewal for signed-in users, cleaned up the public product catalog, and added the automation that would later let the two models review each other without a person starting each review. Claude reviewed it a few hours later and requested changes, with seven numbered findings. Three were marked blocking, three "should fix", and one was a recommendation.

Three of them show the range:

• How the other vendor's API behaves. The automation calls both companies' models. On the Anthropic side, Claude pointed out that the requested reply format was only described in the prompt instead of being enforced through the API's structured output option, that the output budget was too small for a long review, and that a refused request would have been reported as running out of quota, which tells the owner the wrong remedy. That is knowledge about Claude's own platform, and Claude was the one placed to supply it.
• A sign-in edge case. The renewal change rejected any session cookie stamped even one second in the future. If two servers' clocks differed slightly, a user signed in by the faster one could be signed out by the slower one. The fix allows a 60-second difference, with tests at exactly 60 and at 61 seconds.
• Silent failures. Several error paths in the review job would have stopped it without labeling the pull request or leaving a comment, so nobody would have known why a review never arrived.

The review also listed what Claude had checked and found sound, so the author knew which parts did not need another look. About an hour later Claude re-reviewed the new head. Six findings were fixed. The seventh, a recommendation to split the change into three smaller ones, was not taken up, and Claude noted it as non-blocking. The owner merged the result, because it changed release automation, which stays in the owner's hands.

No single finding here was dramatic. The value is in the pattern: the author built carefully, and a reader with different knowledge still found things the author had not seen.

What this does not solve

Two models can share a blind spot, and a review can only cover what is in the change. Review does not replace tests, and tests do not replace review. An independent reviewer also adds steps and some waiting. We accept that because the waiting is now mostly on machines, not on the owner. Whether the trade pays off is a question for data, and we report the early numbers, with their limits, in the results guide.