Cross-Model Review Between Claude and Codex: A Practical Workflow to Systematically Eliminate AI Code Bugs

The Hidden Cost of Vibe Coding

Over the past two years, the barrier to writing software has been dramatically lowered by AI. You don't need to be an engineer, or even understand programming—a single sentence can have AI generate a web page or even a complete app. This is the much-discussed Vibe Coding.

The Rise of Vibe Coding: This concept was proposed and popularized by OpenAI co-founder Andrej Karpathy in 2024. It refers to developers relying entirely on natural language interaction with AI to generate code, without needing a deep understanding of the underlying implementation details. The rise of this paradigm owes much to the leap in code generation capabilities of large language models—models represented by GPT-4, the Claude 3 series, and Gemini Ultra have achieved pass rates exceeding 85% on code benchmarks like HumanEval.

However, there is a huge gap between benchmark tests and real-world engineering: code in real projects needs to handle complex issues such as concurrency, state management, error boundaries, and security vulnerabilities—precisely the areas where current models are most prone to "hallucinatory confidence." So-called "hallucinatory confidence" refers to a model outputting incorrect code with a highly certain tone despite lacking genuine understanding, and without proactively flagging potential risks. This phenomenon is especially prominent in scenarios involving concurrency race conditions, SQL injection protection, and OAuth permission boundaries—and it is the hardest gap to bridge as Vibe Coding moves from "demos" to "production-grade code."

But anyone who has actually rolled up their sleeves runs into the same problem: no matter which model you use, the generated code always has spots that weren't thought through—it might miss some corner cases, or fail to handle a boundary condition, and running it produces a pile of bugs. Then you have to repeatedly tell it this is wrong, that needs changing, and after fixing it, new problems may pop up. Back and forth it goes, and all the time Vibe Coding was supposed to save gets stuck in this inefficient communication.

This article is compiled from a practical workflow shared by Bilibili creator Gary: Cross Model Review. The core idea is to have Claude and Codex automatically review each other, uncovering each other's blind spots, thereby systematically reducing the error rate of AI-generated code.

Why Have Two AI Models Review Each Other

The author was originally a heavy Claude user, and at one point felt it had noticeably degraded and switched to Codex, but after using it for a while, he found Codex had its shortcomings too. So he figured out one thing: why insist on choosing one? The two models each have their own quirks and strengths—wouldn't it be better to use both and play to each one's strengths?

The Division-of-Labor Logic Between the Two Models

The author's approach is: Claude as the main force, Codex as the Reviewer.

Technical Differences Between Claude and Codex: Claude (developed by Anthropic) and the Codex/GPT series (developed by OpenAI) have substantive differences in training data, alignment strategies, and architectural emphasis. Claude uses Anthropic's unique Constitutional AI training method, which emphasizes instruction-following and conversational coherence, making it stand out in understanding vague requirements and doing creative planning. The core idea of Constitutional AI is to instill in the model a set of "value constitution"—a series of explicit behavioral principles that the model actively references during self-critique and correction phases to adjust its output. This makes Claude especially adept at grasping overall intent when handling open-ended requirements.

Codex, on the other hand, has been specifically fine-tuned on GitHub's vast code repositories, giving it a stronger "intuition" for the rigor of program logic and the completeness of boundary conditions—this is also the underlying foundation of GitHub Copilot. The difference between the two essentially reflects differences in pretraining data distribution and RLHF (Reinforcement Learning from Human Feedback) preferences: RLHF is a fine-tuning technique that makes model output more closely align with human preferences, but different product teams have differing definitions of "good code"—Anthropic places more emphasis on safety and interpretability, while OpenAI emphasizes practicality and execution efficiency. This gives cross-model review genuine complementary value, rather than mere redundant repetition.

Understanding this complementary value from a probability-theory perspective is particularly intuitive: if a single model's miss rate for a certain class of error is p, then the probability of two models with different training backgrounds simultaneously missing the same error drops to approximately p². Taking a miss rate of 20% as an example, after single-model self-review 20% of errors still survive, whereas after cross-model review this ratio can theoretically drop to 4%. Of course, the two models are not entirely statistically independent—they share some internet training corpora and the Transformer architecture paradigm—but the differentiated fine-tuning data and alignment objectives are enough to make the joint miss rate significantly better than single-model repeated review. This is also why choosing the combination of two models with the greatest divergence in training paths is more effective than choosing two versions from the same company.

He has a vivid analogy:

• Claude is like the student who ranks second in class—pleasant to collaborate with, strong comprehension; you throw it an idea and it catches it, occasionally even giving you a pleasant surprise. But it just occasionally makes mistakes—overlooking certain details, not thinking through boundary cases thoroughly enough.
• Codex is quite "boring," with no sparks in conversation, but it's just stable. It's especially reliable when handling complex backend logic, thinking of everything it should, which is why it "always ranks first in exams."

There's no right or wrong to this division of labor—it's purely personal preference. You could just as easily flip it and have Codex lead with Claude reviewing, since Codex is cheaper. But for the Reviewer position, what you want is that "boring but never wrong" role to guard the final line of defense.

Why Not Have the Same Model Self-Review

A natural question is: since we want to save effort, why not just have Claude check its own work again?

The answer lies in the blind spots created by differing training emphases. For example, Codex often produces frustrating designs when doing frontend work, whereas Claude and Gemini are better in this regard. The more fundamental reason is: code written by one model, checked by the same "brain" and the same set of assumptions, naturally cannot see its own blind spots. It's like how you can read an article you wrote three times and still miss typos, while someone else spots them at a glance.

From a cognitive-science perspective, this phenomenon is called the "computational version of confirmation bias" (Computational Confirmation Bias): when generating code, the model has already internalized a set of assumptions about "what constitutes a reasonable implementation," and this set of assumptions still exists during self-review, making it unable to question premises it never questioned in the first place. The core value of cross-model review is precisely introducing an "external perspective" with a different assumption system to break this cognitive closure.

From Manual Shuttling to an Automated Code Review System

Initially, the author operated purely by hand: after Claude finished writing a plan, he would copy-paste it into Codex to request a review, paste the feedback back to Claude for revision, then paste it back to Codex for re-checking, running back and forth several rounds until both sides reached consensus.

This approach did produce cleaner code architecture, less technical debt, and a dramatically reduced frequency of later bug fixes. But a new problem followed: the human became the productivity bottleneck.

When multi-feature parallel development was needed—running three or four development lines (Worktrees) simultaneously—each line's plan required several rounds of manual review, and the context-switching alone was maddening. The Worktree here refers to Git's built-in feature—it allows developers to check out multiple working directories under the same repository simultaneously, each in a different branch state and not interfering with one another. For solo developers, Worktree is a powerful tool for advancing multiple features in parallel, but it also means synchronously maintaining multiple review chains, with the cost of human intervention growing linearly as the number of parallel lines increases—which amplifies the necessity of automation. Worse still, people get lazy—glancing at a seemingly simple plan and skipping the review, only for those to be exactly the ones that blow up, and the five minutes saved often costs an hour or two of cleanup.

From this the author drew a key conclusion: human discipline is unreliable. Rather than forcing yourself to remember every time, it's better to turn it into a system that makes it happen automatically every time, entirely without relying on discipline.

The Publishing House Analogy: How the Cross-Model Review System Works

The author explains this system using a publishing house workflow:

• Author (Claude): responsible for writing the manuscript.
• Reviewer (Codex): discusses back and forth with the author, raises questions, and only stamps the "review approved" seal once both sides agree.
• Gatekeeper (Stop Hook): only recognizes the seal; no unsealed manuscript is allowed out this gate.
• The review-approved seal (Marker): a piece of marker text written at the end of the file.

As the "boss," you only need to read the final finalized version from start to finish—you don't have to deal with the arguments and revisions in between at all.

Block One: Stop Hook (the Gatekeeper Mechanism)

Stop Hook is a built-in mechanism in Claude Code. Its underlying principle is similar to signal handlers in operating systems: before Claude prepares to terminate the current task and return control to the user, the runtime environment first triggers a pre-registered hook script. If the hook script returns a specific status code, the system re-injects the hook's output into Claude's context window as a new instruction, forcing Claude to continue executing subsequent tasks.

This "intercept-inject" pattern is called a "Reflective Execution Loop" in agent system design, and it's one of the core technologies enabling AI to transform from single-step question-answering into a continuous autonomous workflow. It closely resembles the "Middleware Pipeline" concept in traditional software engineering—inserting configurable cross-cutting concerns before and after the execution of core business logic to achieve functions like logging, permission validation, and quality checks, without modifying the core logic itself. In the AI agent domain, this pattern is gradually becoming the standard paradigm for building reliable autonomous workflows.

Each time Claude wants to wrap up and return control to you, it gets triggered, at which point it has two choices: allow the session to end, or intercept it and inject a message as a new instruction to continue executing. This ability to "intercept the ending, and also inject a prompt" is precisely what makes the whole system work.

Stop Hook does only three things: scan whether an Implementation Plan was written this round; if so, flip to the end of the file to check for a Marker; if there's none, intercept this ending and insert a message telling Claude to run the Codex Review Skill. Stop Hook is only responsible for intercepting, not for reviewing.

Block Two: Skill (the Review Methodology)

After being intercepted, Claude reads this Skill, which instructs Claude to invoke the Codex CLI and ask Codex to review, and only after Codex approves does it go back and stamp the Marker at the end of the file.

The two blocks are normally unrelated, connected via the Marker "secret handshake." Splitting into two blocks is for decoupling: if interception fails, fix the Stop Hook; if review quality is poor, modify the Skill—each does its own job without affecting the other. This design philosophy is in line with the "Single Responsibility Principle" in software engineering—each module does only one thing and has only one reason to change, thereby maximizing the system's maintainability and evolvability.

The Complete Automated Review Loop and Approval Criteria

The complete process has five steps:

1. Claude finishes writing the Plan and wants to end the conversation;
2. The Stop Hook is triggered, scans and finds no Marker at the end of the file, and intercepts;
3. Claude receives the preset instruction, launches the Codex Review Skill, and calls Codex to review;
4. The two sides go a round or several rounds—fixing what needs fixing, rebutting what needs rebutting—until they reach consensus and Codex replies with approval;
5. Claude stamps the Marker at the end of the file, and the process ends.

The author particularly emphasizes: the approval criterion is not "three rounds back and forth counts as passed," but that the two models genuinely reach consensus. The reviewer Codex must not go easy just to wrap up, and the author Claude must not pretend the problem doesn't exist. For every dispute, Codex must take a clear stance: either be persuaded and admit the other side is right, or hold its ground and explain the reason clearly. If consensus isn't reached, no wrapping up is allowed.

How to Avoid "Nitpicking That Never Ends"

Experienced people will think of a pitfall: large language models have a sycophancy tendency. When you ask it to review, it can always find one or two problems—either treating a reasonable design as a bug due to lack of context, or over-pursuing perfection leading to over-engineering.

Research Background on Sycophancy: This is one of the core challenges in current large language model research, referring to the model's tendency to give the answer the user wants to hear rather than the objectively accurate one. This problem is rooted in the RLHF training process: human annotators tend to give higher ratings to responses that sound pleasing and are worded with confidence, even if those responses are factually wrong. Research papers from institutions like Anthropic and DeepMind have all confirmed that when users express dissatisfaction with a model's output, the model will, with a high probability, change its originally correct position—a phenomenon researchers call "Position Drift."

The deeper reason is that the RLHF reward signal is essentially a proxy metric for human preference, and human preference does not always align with "objective correctness." When annotators cannot accurately judge the correctness of a technical answer, they often substitute "sounds reasonable" for "is actually correct"—which makes the model's sycophantic tendency especially pronounced in specialized technical domains. In code-review scenarios, if a new session is opened every time, the model lacks contextual memory and tends to "nitpick for the sake of nitpicking"; whereas if it keeps iterating in the same session, the model can perform a truly convergent review based on remembering previous conclusions.

The author's solution is: use the same Codex conversation from start to finish, without reopening a new session each round. If each round cold-starts, Codex remembers nothing and will pick a bunch of new, unimportant nitpicks each round, never finishing, ultimately turning into over-engineering. But within the same conversation, it remembers what was discussed the previous round, catches the main issues all at once in the first round, and then comes to "accept" whether the changes are correct, thereby converging toward consensus.

He also removed the initially set "three rounds maximum" cap—because it would force out worse results: by the third round, regardless of whether the problem was solved, the model would pretend there's no problem just to finish. In the end, he recognizes only "consensus" as the sole criterion.

The author gives a concrete example: asking Codex to plan an e-commerce ordering feature, the plan says "must ensure no overselling," which seems complete, but the whole thing never writes out the specific handling method—when only the last item is left and two people place an order at the same instant, how exactly is it handled? This involves choosing between the database's row-level lock or optimistic locking mechanisms, as well as idempotency design in distributed systems—details easily overlooked in a high-level plan. Switching to another model to review objectively from a third-party perspective has a higher probability of spotting this kind of blind spot. This is precisely the real value of the cross-model review system.

One Level Higher: Building an AI Work Harness for Yourself

The author finally elevates the matter one level: what he built is not just "finding a second AI reviewer," but building for himself, based on his own usage habits, a set of Harness—the entire work environment wrapped around the AI, including the constraints, processes, and tools given to it. It's like a boss preparing an efficient work environment for employees to boost output.

The Engineering Tradition of Harness: This concept originates from the test-driven development (TDD) tradition in software engineering, initially referring to a set of automated testing infrastructure built around the code under test, including test frameworks, mock objects, assertion libraries, and CI/CD pipelines. Migrating the Harness mindset into AI workflows essentially applies the engineering philosophy of "Built-in Quality" to agent systems—not relying on human subjective self-discipline to guarantee quality, but encoding quality checks as the system's mandatory constraints.

This is highly consistent with the "Shift Left Testing" concept in DevOps culture: the earlier a problem is discovered, the lower the cost to fix it. A typical industrial research statistic shows that the cost of fixing a defect discovered during the requirements phase is only 1/100 of the cost when discovered in the production environment. Extending this logic to the AI coding scenario, the value of Harness lies in moving the cost of "discovering problems only after the code is deployed" forward to "being intercepted by the Reviewer at the Plan stage"—this is precisely the role Cross Model Review plays within the Harness framework.

In this system: the Stop Hook is a mandatory constraint, forcing the process to run to completion and giving no room for laziness; the Skill is the working method, defining how to review; the Marker is the handshake signal. Cross Model Review is only one block of it, and the same idea can be applied to wrap any step you would normally do but often lazily skip.

For Solo Developers, this is especially important—there's no colleague to help with your code review, so all the vulnerabilities are on you to bear. Traditional code review relies on team collaboration, which is both a luxury and a scarce resource for solo developers. But with an AI Harness, a solo developer can actually gain a kind of "asynchronous, never-tiring virtual team"—every key decision has a second pair of eyes reviewing it, and every implementation approach has its premises questioned. You can, in turn, build a system that plays the role of that "AI colleague" who never tires and never gets lazy, guarding for you 24 hours a day.

One of the author's sentences is worth savoring: rather than praying that the AI won't make mistakes, it's better to roll up your sleeves and build an environment where "it can make mistakes, but the mistakes will be caught by the Harness."

Key Takeaways