When AI reviews AI — the review we used to paste by hand

For a while, the way we reviewed AI-written code was to paste it into ChatGPT by hand. An AI wrote the design doc or the code; a person copied it into a review, read the comments that came back, and pasted them in again to make the fixes. It raised quality, but a person had to sit in the middle as connective tissue, each time.

Now, using a tool called Codex CLI, Claude Code — the AI that handles our design and implementation — can hand the review off to a separate AI on its own. Planning, review, and implementation run without a person shuttling between them. This is a first-hand account as of July 2026. AI moves quickly and the models keep changing, so take everything here as a snapshot of one moment.

Before — the review was pasted in by hand

The old way went like this. An AI wrote a design doc or code. A person copied it into ChatGPT and asked for a review. They read the comments, pasted them back to the AI, and fixed things. The round trip did keep quality up, but a person had to play courier for the copy-and-paste each time — a drag on both speed and effort.

On top of that, the AI of the day was good at writing code, but reading its own output back closely and pushing back on it — the work of a real review — was not yet at a level you could rely on in practice.

Now — one AI hands the review to another

This is where Codex CLI comes in. A CLI (command-line interface) is a tool you operate with typed commands rather than on-screen buttons. Codex CLI is OpenAI's coding AI that runs through those commands.

With it, Claude Code can call Codex as a separate reviewer AI, on its own initiative. Instead of a person pasting into ChatGPT, one AI asks another for a review, receives the comments, and makes the fixes — you tell it to run the review rather than copy-pasting each step yourself. The loop from plan to review to implementation now runs without a person relaying between them.

There is a second shift. The earlier AI was an agent that only wrote code. Now, by running the GPT-5.6 Sol model that Codex uses in ultra mode, Codex does more than read an implementation and push back on it — it reasons about whether the design and even the strategy are right. To be precise about the terms: Sol is the name of the model, and ultra is the name of an execution mode that runs several agents in parallel and integrates their output — two different things. Sol is the model OpenAI made generally available on July 9, 2026 (US time; July 10 in Japan).

For a small team, this is the whole point: quality stops depending on whether a strong reviewer happens to be free that day, and starts depending on how the work is run.

Getting started

To give a sense of how small a lift this is — you can start on your own, without a dedicated team — here is the short version. There are roughly two paths.

• The easiest is to let Claude Code handle it. Add the Codex plugin to Claude Code and type /codex setup; it checks whether Codex is installed and, if not, walks you through installing it. You never open a terminal yourself, and it works the same in the Claude Code desktop app for Windows.
• To install it yourself, run npm install -g @openai/codex in a terminal, launch it with codex, and sign in to your ChatGPT (OpenAI) account using codex login.

The full setup steps are in OpenAI's official repository (Codex CLI). After that, you tell Claude Code to ask Codex to review the implementation, and one AI hands the review to another and runs the loop.

Closing design gaps before anything ships

Here is a case where it paid off, with customer details removed. For a new feature, we ran three rounds of review on the access-control design — the rule that each participant should see only their own data — at the design stage, before a line of code was written.

The subject was not finished code but a design still to be built. So a comment here meant catching a problem before it ever took root. Each round the comments went deeper and then converged. For example: the permission condition was drawn too broadly, and as designed would have let one party see another's data. Images were being handled without first checking the consent state. Concurrent updates could collide and corrupt data. Every one of these could surface eventually if left alone, yet none of them show up in a plain-text search (grep) or a type check. You only see them by reading the meaning of the SQL, the behavior when several operations run at once, and the way the data connects.

What matters is that these were found at the design stage, before anything went out. It rests on running two gates: a design-consistency gate that checks whether the design meshes with the existing systems, and a second gate that reads the actual code and data structures and pushes back on them. One person sits outside those gates and makes only the final call. With one person and one AI, the author cannot catch their own blind spots — so a separate AI reads the design and the real code and pushes on it early. That is the division of labor.

"More dialogue raises accuracy" is still a hypothesis

The interesting part is that the more the agents went back and forth, the deeper the comments became. From that we draw a hypothesis: that the accumulation of dialogue and reasoning is what feeds review accuracy. But it is a hypothesis drawn from our own first-hand experience, not a proven cause-and-effect relationship.

In fairness, one more point. On public benchmarks, the detection rate of AI review is still limited, and on some tests a model other than the one we use scores better. So we do not read "the AI said nothing" as "this is safe." For changes that touch billing, permissions, or anything that can destroy data, we always pair AI review with automated tests and a human final check. AI review is one layer that catches what people miss — not a substitute for people or tests.

What it means for the business — building quality into the process

Translated into the language of management, it comes to this. Rather than resting quality on whether a strong reviewer happens to be on hand, you build it into how the work runs: put design and implementation through separate gates, and have the AIs review one another. Do that, and even a small team can keep quality high by design.

This is exactly what we care about when we help companies build in-house — binding several AIs together, each with a defined role, and building that review loop into everyday operations, so quality holds up as the work runs. More than flashy automation, it is this quiet pattern that keeps quality high for a small team. If you are weighing how to keep quality high in your own development, reach out through our contact page.