Cross-model code review: when one AI lab should check another's work

Cross-model code review is having an AI model from one lab review code that a model from another lab wrote, for example Claude reviewing a draft from OpenAI's Codex. It can catch mistakes the writing model misses, but the direction matters. In a July 2026 study of 116 coding tasks, Claude reviewing Codex's drafts raised the pass rate from 71.6% to 89.7%, while Codex reviewing Claude's drafts lowered it from 91.4% to 82.8% (Xiang et al., arXiv 2607.21656). In Poly (usepoly.co), a team runs the same pattern in one room: one person builds with one lab's model, a teammate reviews with another's, and nothing lands without the room seeing it.

Key takeaways

• A second lab can catch what the first misses, but one study found the benefit ran in one direction only. Test the direction on your own work.
• The reviewer needs the goal and the decisions, not just the diff.
• In a shared room, the reviewing model gets a catch-up of what was said and reads the same files and git history.
• People still decide: the review is a reply in the timeline, and any change it proposes waits for the room's approval rules.

Why review one model's code with another?

A model reviewing its own draft tends to share the draft's blind spots. A model from a different lab was trained on different data with different methods, so its mistakes are less likely to line up with the writer's.

The evidence is early. The study above, from the Agentic SE workshop at KDD '26, ran Claude and Codex in six set-ups (each alone, each reviewing itself, each reviewing the other) on 116 recent hard and medium tasks. The reviewer saw the problem and the draft but could not run tests. Claude's review lifted Codex's drafts further than Codex's own review did: 89.7% against 84.5%. Codex reviewing Claude made things worse, and Claude reviewing itself changed nothing. One study, two agents and one kind of task is not a law. It is a reason to choose the reviewer on purpose.

How do developers do cross-model review today?

Mostly alone, on one machine:

• OpenAI's Codex plugin for Claude Code runs a Codex review, a more skeptical "adversarial" review, or hands a task to Codex, from inside Claude Code (openai/codex-plugin-cc).
• Community skills and scripts have one agent call another agent's command-line tool for a second opinion.
• Two chat windows, with code pasted between them.

All three put one developer in the middle, running both models from their own setup, and the review happens where only that developer can see it.

How does a team do it in one Poly room?

1. Build. A member working with one model, say Claude Sonnet 5, asks for a change. It lands as a commit with a receipt, after whatever approvals the room's working mode asks for.
2. Review. A teammate with another lab's model selected, say GPT-6 Sol or Grok 4.7, asks: "Review the last change for bugs, missing edge cases and missing tests. List problems by severity. Don't change files yet." The reviewing model gets a catch-up of what was asked and answered, and reads the same workspace and git history. In a mode that asks before edits, anything it tries to change waits for an approval anyway.
3. Decide. The review is a reply in the timeline, so everyone reads it. Members can mark each changed file, and a "request changes" note can go to the agent as the next prompt. Whoever asks for the fixes picks which model makes them.

Each turn is billed to the person who sent it, so the reviewer pays for the review.

What should the reviewer be told?

• The goal, in a sentence, so it reviews against intent rather than taste.
• What to look for: bugs, edge cases, security, tests.
• What not to do: "don't change files yet" keeps a review a review.
• How to report: problems by severity, each with the file and line.

When is cross-model review not worth it?

• Small or obvious changes. A second model doubles the cost for little gain.
• When tests can answer it. The study's reviewers couldn't run tests. Poly's agents can run commands in their sandbox, subject to the room's approvals, so run the tests first.
• When the direction is wrong for your models. The study found one direction helped and the other hurt. Try both on a few real changes before making it a habit.

Multi-model AI coding lists the models a room can use for either side.