Meet Code Tribunal: AI Code Review Where the Reviewers Cross-Examine Each Other

---

Most teams that add an AI reviewer to their merge requests go through the same arc. At first it's exciting. Then come the obvious nitpicks, the missed bugs and the false positives. A few weeks later, nobody reads the bot's comments anymore.

Code Tribunal is my answer to that problem. It doesn't rely on one AI reviewer. It runs several independent reviewers and makes them cross-examine each other before anything reaches your merge request.

Why one AI reviewer isn't enough

We review code because we don't fully trust ourselves. Everyone ships mistakes they can't see in their own work.

The same logic applies to AI. Every model and every agent harness (Codex, Claude Code, Cursor, OpenCode, …) has its own blind spots and habits. Trusting a single one just moves the blind spot somewhere else.

So the answer isn't more reviewers. It's reviewers who review each other's review.

The usual options

• A human driving the strongest models by hand gives great results, but it's limited by attention, capacity and mood, and getting different harnesses to talk to each other can be tricky. It can't be the default for every merge request.
• A cheap model in an open-source tool finds the obvious issues, misses the rest and adds false positives. People lose confidence in it and start ignoring it.
• Commercial review products are another subscription, often a costly one. They also lock you into one vendor's view of your code.

Code Tribunal sits in between: the quality of a cross-examined review, automated and running on every merge request.

Architecture: three pillars

Code Tribunal is multi-harness, multi-model and multi-stage, and it runs in your CI pipeline: GitLab merge-request pipelines or GitHub pull-request workflows. The whole design follows one principle:

LLMs propose. Deterministic code decides.

1. Parallel review

Three or four reviewer seats, each a harness × model pair (Claude Code, Codex, OpenCode, Cursor), review the diff in parallel. None of them sees the others' output. Keeping them independent is what produces different perspectives instead of one opinion repeated. Every finding is validated against a shared schema before it moves on.

2. Blind cross-examination

Each reviewer then critiques its peers' findings. The findings are anonymized, so a reviewer doesn't know which model or harness raised them. Findings are judged on substance, not on reputation.

3. Deterministic verdict

No LLM decides the outcome. Plain code groups related findings and keeps a group when at least two reviewers support it independently. Findings only one reviewer raised aren't thrown away. They're posted as FYI, so dissent stays visible instead of being averaged away.

The surviving findings are posted as review discussions on the merge request. Each finding is tracked across revisions, so re-runs update existing discussions instead of piling up new ones. Results are informational: whether a change may merge stays with your repository's own policy.

Why it works

1. Cross-examination: find more, err less. Different models catch different classes of issues, so more of them find more. Cross-examination knocks out false positives before a human ever sees them. And when reviewers disagree, that's the most useful signal in the whole review: it shows you exactly where to look.

2. The best of every vendor, swappable. The AI market moves fast and no vendor stays ahead for long. Code Tribunal lets you run the current best model from each vendor side by side, through an existing tool subscription where you have one, or through pay-per-use API access, for example via OpenRouter. Model, harness and effort level are configuration, so when a better or cheaper model ships, swapping it in is a config change.

3. A deterministic verdict. The final call isn't made by yet another LLM acting as judge, with biases of its own. Plain code applies a fixed rule, so the same findings always produce the same outcome, and you can always trace why a finding was posted. Each finding also keeps its identity across revisions, so re-runs update existing discussions and resolved findings are recognized as resolved instead of being reported again.

We recently put point 2 into practice and moved every repo to a new four-reviewer lineup:

Harness	Model	Effort
Claude Code	Sonnet 5.5	high
Codex	GPT 6.1 Sol	medium
OpenCode	DeepSeek V4.1 Flash	max
Cursor	Grok 4.7	high

Three reviewers make a full panel, enough for a 2-to-1 majority on any finding. A fourth adds a fallback if one reviewer fails, plus one more perspective.

What changes in your workflow

The real metric for AI code review isn't how many comments it posts. It's confidence.

When findings have already survived cross-examination, people stop skimming past them and start acting on them. Human reviewers don't disappear. Their attention moves to the places where the tribunal disagreed with itself, and deep human review becomes the exception for high-stakes changes instead of the bottleneck on every merge request.

The numbers so far

Every repository in my team and our sister team now runs Code Tribunal. The numbers below come from the first one to adopt it, a large frontend repo that I oversee, measured by how long tickets sit in the Code Review column of the board.

Code Tribunal was switched on in early July. After a two-week break-in, most eligible merge requests were getting a review. We then compared two equal 61-day windows, before and after:

Metric	Before	After	Change
Average time in Code Review	3.8 days	1.5 days	−59%
Slowest 10% of tickets	11.1 days	4.2 days	−62%
Typical ticket (median)	7.8 h	6.4 h	−18%
Typical single visit	1.7 h	0.8 h	−52%
Visits per ticket	1.6	2.1	+31%
Tickets in the window	103	105	flat

Stuck reviews got much shorter. Tickets that used to sit in review for more than a sprint now move through, and the typical ticket spends less time in the column too.

Tickets bounce back more often, but faster. Visits per ticket went up because findings lead to short rounds of rework. Each visit is so much shorter that the extra pass doesn't eat the gain.

This doesn't mean every review is twice as fast from day one. The honest version: after about two weeks of break-in, tickets leave Code Review faster, and the ones that used to get stuck benefit most.

What's next

Code Tribunal is actively evolving. On the roadmap:

• Harness-native /review commands. These will plug in the review modes vendors are building into their own tools as tribunal members.
• Incremental follow-up reviews. Checking whether earlier findings were resolved already works. Next, follow-up runs will review only what changed since the last run instead of the whole diff.
• Deep consensus mode. An escalation path for complex or tricky merge requests: two strong harness + model pairs at extra effort, going back and forth in rounds until they agree on every point. The same mode is useful for planning and debugging.
• Architectural input. Structural suggestions beyond line-level findings, such as solving more with less, or fixing a problem by removing code instead of adding another guard clause. Related findings should also be linked into one issue when they share a root cause.

Try it

If your team has started ignoring its AI review bot, or never trusted one in the first place, give Code Tribunal a look: github.com/seanleecoder/code-tribunal.

I'd love to hear how it works on your codebase, and which lineup you end up with.