Cross-reviewing the same deliverable with Claude Code and Codex

Conclusion

• I had Claude Code and Codex build the same thing separately, then review each other. For the same deliverable — this blog's table of contents, its primary sources, and a sample article — I had two AIs build it independently, then cross-review across five categories: factual errors, missing evidence, secrets, prose, and medium-fit. A human makes the final call.
• The two AIs found different kinds of defects. Codex caught misreadings of what numbers mean: "$15.76 cannot be asserted as the real bill," and "a 100% match rate is not proof that the LLM (Large Language Model, a model that generates responses from large amounts of text) is correct on its own." Claude Code caught that the model's own size, stated as "90GB," was actually about 47GB, and found a Slack workspace name and an absolute path left inside an HTML (HyperText Markup Language, the language that describes the structure of a web page) comment.
• Even so, human review cannot be skipped. If both AIs share the same error, cross-review will not catch it. And the business decision of whether something is safe to publish still remains.

Body (about an 8-minute read)

Don't trust either AI on its own

The articles on this blog are built by two AIs — Claude Code and Codex — that both use an LLM. From the start there was one premise: never take either AI's output at face value.

The reason is simple. An AI tends to overrate what it wrote as "correct" and "ready to use." Have the same model look again, and it reads back with the same assumptions it wrote with. The same blind spots survive.

So I split generation and review across different models. Two AIs build the same deliverable independently and review each other. A human decides last whether it is safe to publish externally. That is the three-stage setup.

I once mentioned, in a single line in another article, that "I have one AI doubt another AI." This article opens up what was inside that one line — how the work is categorized, who is made to look at what, and what the two AIs actually flagged.

Decide roles and categories first

The target is the same deliverable. The sample I ran it on this time was a hands-on account of two things: tallying cloud costs, and operating a local AI that runs on a GPU. The dollar figure ($15.76) and the model sizes (72B, 90GB) that come up later are all content from inside that sample.

Let the AIs review however they like and the findings never line up. So in the production plan (PLAN.md) I wrote, up front, who looks at what and how findings are categorized.

# Cross-review role split (from PLAN.md)
Codex      : article structure & readability / claim-to-evidence mapping / misreadings of numbers / spin-off ideas per medium
Claude Code: consistency with the repo's latest state / gaps in ADRs, work logs, observations /
             technical errors / project-specific disclosure risk
Human      : what is OK to publish externally / whether customers, pricing, incidents can be disclosed /
             paid vs. free split / final title and where to post

# Sort review findings into 5 kinds
factual error / missing evidence / secret / prose / medium-fit

Here an ADR (Architecture Decision Record) is a document that records a design decision. These five categories paid off. Sorting each finding into "the fact is wrong," "the evidence is thin," "a secret leaked," "the prose is poor," or "it doesn't fit the medium" lets you line up, afterward, which AI tends to catch which kind of defect.

What Codex found (verdict: NEEDS_REVISION)

Reviews were kept not as chat but as structured documents a machine can process. Each document carries a reviewer name and a verdict, and findings are tracked in a correspondence table (ID, severity, owner, resolution, status).

The verdict was "needs revision." The table held ten items. The main findings against the Claude Code version were:

• [P0 secret] Three real screenshots in the sample article still showed the internal network, the scale of operations, and per-project uptime. The point: an API (Application Programming Interface, the defined way software components exchange input and output) key not surfacing under image OCR is not the same thing as the image being safe to publish.
• [P1 factual error] The article asserted "$15.76" as "the real cloud bill," but the implementation computes it from registered unit prices, and when a model with an unknown unit price is mixed in, it returns a lower bound covering only the known part. The nominal converted figure and the actual bill do not match.
• [P1 factual error] It summarized a 100% match rate in the purchase-decision Proof of Concept (PoC, running something for real to confirm the idea) as "the LLM being correct on its own," but the primary sources show the LLM's JSON (JavaScript Object Notation, a text format for structured data) formatting succeeded 69% of the time and fell back to an alternate path 31% of the time. Zero dangerous-side errors happened because a deterministic final-stage safety rule (a fixed rule that overrides the LLM's output) absorbed the broken LLM output — not because the LLM was flawless.
• [P1 logic] It said the 72B (72-billion-parameter) model was routed to a work lane (a processing track that assigns tasks) "because its quality is superior," but on the generation benchmark 14B (14-billion-parameter) and 72B tied on success rate, 72B was about six times slower, and the conclusion was "do not promote it." The real reason it was adopted was to use an existing asset as a free, low-risk lane.

What Claude Code found (32 items)

Next, Claude Code reviewed the Codex version. This is the second stage. It checked six angles in parallel — benchmark numbers, memory and routing, the measured 50.3% throughput, table-of-contents coverage, secrets, and prose and medium — and re-verified each finding against primary sources, using 18 agents in total. There were 32 findings: 3 factual errors, 4 secrets, 10 missing-evidence items, 11 prose items, and 4 medium-fit items. For the 12 items with medium-to-high impact, the grounds were re-confirmed. 77 items were confirmed as having no problem.

• [factual error] "The 72B model itself is about 90GB" is wrong. 90GB is the resident value with a 32k-token context loaded; the model itself was about 47GB. Within the article, the "model itself" field and the "including context" field both read 90GB, which is internally inconsistent.
• [secret] An HTML comment in the body (it stays in the Markdown source but is not shown on screen) still held a Slack workspace name, a permalink to a channel, and several local absolute paths. Even if they are invisible on screen, they are readable from the published Git repository and the Markdown source.
• [missing evidence] The generation benchmark's denominator n=7 (a sample size of 7) was absent from the body; local 50.3% and cloud 48.2% sum to 98.5%, and the remaining 1.5% (unknown, the share that couldn't be classified) went unexplained; and projects with high observation counts were missing from the table of contents. It raised ten such evidence gaps.

Even under the same category name, the two AIs found different things. Both flagged "secret," but Codex found internal information captured in a published image; Claude Code found absolute paths and a Slack name buried in an HTML comment. Both flagged how 72B was handled, but Codex flagged the logic — "the stated reason is the opposite of the benchmark" — while Claude Code flagged the number, "90GB versus 47GB."

The difference the two models flagged this time

A single reviewer leaves that reviewer's own blind spots in place. The Claude Code version's sample article had a strong narrative and plenty of real screenshots. But it "put a real dollar figure in without vetting it" and "generalized beyond what had been observed." The Codex version handled the meaning of numbers and disclosure risk rigorously. But it dropped the later developments and buried evidence inside HTML comments, mixed into the body.

For this deliverable, Codex flagged the meaning of numbers and disclosure risk; Claude Code flagged consistency with the repo's latest state, dropped observations, and secrets inside HTML comments. That the two models flagged different kinds of defects is as far as this record lets me claim.

I have not run a controlled comparison against self-review, so I cannot assert that a different model finds more defects. What I can confirm is that this time Codex pointed out that "OCR not surfacing a key is not the same as being safe to publish" — an angle distinct from the side that generated the work.

The limits of cross-review

There are three limits.

First, cross-review is not exhaustive. The Codex-side review itself states its scope limit: "I did not re-verify every individual number across all 96 article candidates against the originals. I prioritized the sample article and the publishing pipeline."

Second, if the two AIs share the same error, cross-review will not catch it. That is why I kept the final human review — what is OK to publish externally, whether customers, pricing, and incidents can be disclosed — as a mandatory third stage.

Third, the theme taxonomy used to sort the articles diverged between the two. This is not the five review categories (factual error, missing evidence, secret, prose, medium-fit); it is a separate scheme for what themes the article catalog is grouped by. Because each version built that theme taxonomy separately, the Codex review records that the Claude Code version's six English categories and the Codex version's seven Japanese categories did not match. Reconciling them required a human ruling.

The human judgment remains.

As a byproduct, this cross-review has fed several corrections. Findings are put into a correspondence table (ID, severity, owner, status). The public tree and the non-public evidence are physically separated. Top articles get a per-claim evidence ledger. This very article you are reading went through the same process.

From running this, three things became clear:

• Use a different model for generation and for review. This time, different models flagged different kinds of defects. That said, whether that catches more than self-review is something I have not compared.
• Keep a shared taxonomy, but let each AI go deep in its strong area. Even under the same category name "secret," one finds a published image while the other finds an absolute path in an HTML comment. Line them up on a shared axis like the five categories and that difference becomes visible.
• A human decides publishability last. Errors the two AIs share, and the business judgment of whether it is OK to publish, are not filled in by AI review alone.