Cross-Model Code Review

TL;DR: Claude Code writes the code → Cursor + Codex reviews it against the spec → feedback goes back to Claude Code as "CTO who can disagree." Models fail in opposite directions, so the tension between them produces better code.

The Problem

A model reviewing its own code is like proofreading your own essay — you read what you meant to write, not what you actually wrote. The same reasoning that produced a bug is the same reasoning reviewing it.

Cross-model review fixes this. A different model comes in with fresh context and no attachment to implementation decisions.

The Workflow

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Claude Code │     │   Cursor +   │     │  Claude Code  │
│   (builds)   │ ──► │ Codex (reviews) │ ──► │  (CTO filter) │
└──────────────┘     └──────────────┘     └──────────────┘

Step 1: Build with Claude Code

Develop your feature in Claude Code from a GitHub issue or spec. Work as you normally would — no special setup needed.

Step 2: Structured Verification (Optional but Recommended)

Before cross-model review, run the Issue Verification Command in Cursor with Codex as the model. This catches the obvious stuff (missing requirements, incomplete implementations) so the cross-model review can focus on subtle issues.

Step 3: Cross-Model Review

Open the same repo in Cursor. Set the model to GPT Codex 5.3 (or another model different from what you used to build). Give it:

• The original issue or spec
• The code that was written
• This prompt:

Review this implementation against the original issue/spec.

Check for:
1. Spec compliance — does the code do exactly what was asked?
2. Missing edge cases — null inputs, empty arrays, unexpected types
3. Overengineering — unnecessary abstractions or complexity
4. Best practices — anything a senior dev would flag in code review

Be specific. Reference line numbers and file names.

Step 4: CTO Feedback Loop

Take the review output and paste it back into Claude Code with this framing:

You are the CTO of this project. Below is a code review from another engineer.

Go through each comment. You can disagree with any of them, but you need
to justify why. If the reviewer is right, acknowledge it and fix it.

Review comments:
[paste Codex's review here]

Why the CTO framing matters: Without it, Claude accepts all feedback blindly — "great points, I'll fix everything" — even when some suggestions are unnecessary. With the CTO role, it actually evaluates each comment and pushes back where appropriate.

Why This Pairing Works

The key insight: they fail in opposite directions. Claude over-architects, Codex simplifies too aggressively. Each one catches exactly what the other misses.

Example

Issue: "Add pagination to the users list endpoint"

What Claude Code built: Working pagination with cursor-based navigation, a caching layer, and request deduplication.

What Codex flagged:

• Pagination works correctly
• Caching layer isn't in the spec — adds complexity for no clear reason
• Missing: issue says "show total count in response" — not implemented
• No handling for invalid cursor values

What Claude Code (as CTO) responded:

• Agreed the caching layer was overengineered — removed it
• Acknowledged the missing total count — fixed it
• Pushed back on invalid cursor handling: "the spec implies valid cursors only, but adding validation is a 2-line change, so let's do it anyway"
• Disagreed with another Codex suggestion about restructuring the response format: "current format follows our API conventions in CLAUDE.md"

Tips

• Always use different models. Same-family models (e.g. GPT 5.2 reviewing GPT 5.3) share similar failure patterns. The value comes from architecturally different models.
• Fresh context is the point. The reviewer model should have zero knowledge of implementation decisions. Don't share chat history — just the code and the spec.
• Keep a CONVENTIONS.md in your repo root that both models can reference. This eliminates subjective style discussions and focuses reviews on logic issues.
• Don't skip the CTO step. Without it, you'll fix things that don't need fixing and add complexity that doesn't need to exist.

Quick Start

1. Build a feature in Claude Code
2. Run Issue Verification in Cursor with Codex
3. Review the flagged items
4. Paste feedback back to Claude Code with CTO framing
5. Ship better code

Related

• Issue Verification Command — the structured check that runs before cross-model review