Claude Code Wrote It, Codex Reviewed It—and Nothing Shipped

One feature went through five specs and four RED audits

A solo Flutter developer built what looked like a sensible two-agent workflow. Claude Code wrote the specification and implemented a feature. Codex reviewed both, then returned GREEN, YELLOW, or RED. A RED went back to Claude for repair, and Codex audited the result again.

The system did catch mistakes. It also stopped shipping.

One difficult feature went through five versions of its specification and four RED audits in a single day. Some findings mattered: Claude had described behavior without checking the actual file. Others were smaller—a paragraph contradicted a table, an uncommon edge case was not fully explained, or the wording could be made stricter.

Every finding entered the same loop. Fix, reopen the whole review, discover something else, repeat.

The failure was not “Codex reviews too much” or “Claude writes bad code.” The workflow had no finite definition of done. It asked an auditor to keep finding problems and then treated every problem as a release decision.

Five to fifteen reviews—and eighteen hours with no target file

The same pattern appears in other developer accounts. One person running Codex reviews before and after Claude’s WordPress SEO changes reported five to ten review rounds on ordinary work and as many as fourteen or fifteen. Managing the review loop took more time than doing the SEO work.

Another developer repeatedly launched four Claude agents to perform a fresh, full end-to-end product audit. After eleven runs, critical, high, medium, and low findings still appeared. A critical finding could disappear in one pass and return in a later pass.

The most extreme account came from a developer who used Codex to coordinate Claude author and reviewer sessions. Their reported result was eighteen hours, thirty-nine commits, and zero target engine files. A planning document grew from 22,929 bytes to 176,520 bytes across five rejections.

The workflow measured revisions and commits, so it always looked active. The actual delivery metric—engine files produced—remained zero.

Cross-model review works best as a defect finder

There is a strong case for using a second model. A Claude Code user who opened the same repository in a fresh Codex context found incomplete implementations, missing edge cases, and weaker approaches that the implementing model had not challenged. Codex saw the repository and the written specification without inheriting Claude’s reasoning path.

That is useful separation. It is not a transfer of release authority.

A public six-project Claude Code and Codex comparison showed what evidence-based cross-review can look like. The author combined automated tests, builds, type checks, browser and server runs, adversarial probes, cross-review, self-review, and a final human judgment. Runtime-proven bugs outweighed unsupported concerns.

• A proposal was persisted to IndexedDB, but the main editor sometimes failed to open it.
• Concurrent writes produced one leaderboard score in memory and a different score after replaying the write-ahead log.
• An invalid product value bypassed business rules in an API.
• A regex engine with 100 comparison cases still disagreed with Python on basic alternation behavior.

These were not persuasive review paragraphs. They came with files, inputs, commands, and observable results. That is where a second model adds the most value: turning a suspicion into a testable claim.

Define release claims before asking for an audit

Before review begins, write a small, finite set of statements that must be true for this specific change to ship. Do not attach the entire company’s engineering wish list to every feature.

A RED finding must identify which claim it falsifies or leaves unsupported. If a finding does not affect any release claim, it can still be valid, but it belongs in YELLOW or NOTE rather than restarting the release audit.

“The reviewer found something real” and “the release must stop” are separate decisions.

Severity needs likelihood, impact, and evidence

Labels such as security, data, and performance sound serious, but the label alone does not establish risk. Ask whether the path can occur in this product, whether it is common or theoretical, whether it stops one recoverable operation or exposes another user’s data, and whether the damage persists.

A documentation contradiction can be RED when it changes the contract or makes acceptance impossible to verify. A wording improvement is not RED merely because it is correct.

Google’s code-review standard makes the same trade-off explicit: reviewers should approve a change that clearly improves overall code health even when it is not perfect. GitHub’s quality gate similarly lets repository owners choose the minimum severity that blocks a merge.

No RED without a file, reproduction, or failing check

OpenAI’s Codex code-review guidance tells reviewers to inspect changed files and relevant diff lines, check test results and status checks, and validate generated findings against the code. Anthropic’s coding guidance similarly instructs an agent not to speculate about a file it has not opened.

Finding ID:
Severity: RED | YELLOW | NOTE
Violated release claim:
File and line:
Current code or diff:
Reproduction input:
Command or test:
Expected result:
Observed result:
Affected scope:
Confidence:
Fix now or defer:

“Concurrent requests might corrupt state” is a hypothesis. It becomes a blocking finding when the reviewer points to the write path, provides the concurrent request, runs it, and shows the persisted state diverging from the expected state.

The public leaderboard project did exactly that. Two thousand concurrent writes for one user produced a score of 1996 before restart and 2000 after write-ahead-log replay. The measured mismatch made the consistency failure more important than a long list of theoretical concerns.

Recheck the changed risk, not the entire product

The common loop is expensive because every fix triggers a fresh full audit. That resets the scope and invites the new reviewer to discover unrelated concerns.

After a fix, rerun the evidence for the release claim that failed, then test adjacent regressions. An authentication-middleware change should recheck successful login, denied access, token expiry, and the routes using that middleware. A copy change does not justify reopening database recovery and payment concurrency.

Reopen a full audit only when the fix expands scope, touches shared infrastructure, or invalidates the original release claims. GitHub required checks provide a useful mental model: the merge depends on named checks passing against the latest commit, not on a reviewer being unable to imagine another improvement.

A round limit should escalate the decision, not force a release

A hard cap of two or three AI review rounds prevents runaway cost, but it cannot be the safety standard. Two rounds do not make an authorization bypass safe.

Use the cap as an escalation trigger. If the same RED remains after two repair attempts, or the implementing and reviewing agents disagree about the evidence, stop the automated loop. A person chooses one of three actions:

1. Hold the release and resolve the blocker directly.
2. Reduce scope so the blocked path is not part of the release.
3. Build a focused experiment or test that can settle the disputed claim.

YELLOW and NOTE findings do not need repeated audits until they disappear. Move them to a durable issue tracker with an owner and a decision date.

The bounded Claude Code–Codex review loop

1. Write the feature’s acceptance criteria and release-blocking claims.
2. Have Claude Code implement within a named file and behavior scope.
3. Run deterministic build, type-check, lint, and test commands.
4. Ask Codex to find issues, but require severity, evidence, and a violated release claim for every RED.
5. Let the human accept, downgrade, defer, or reject each finding.
6. Send only accepted fixes back to Claude Code.
7. Recheck affected claims and adjacent regressions rather than reopening the entire repository.
8. After the round cap, escalate remaining RED findings to a human decision.

GREEN does not mean Codex can find nothing else to improve. It means every selected release claim has evidence, required checks pass on the latest change, and no evidence-backed RED remains open.

Claude Code and Codex can catch each other’s misses. They cannot decide what level of risk the product is willing to ship unless a person writes that rule first. Let one agent build and another challenge the result. Keep the authority to define RED, accept evidence, and end the review outside the loop.

Frequently asked questions