Edgecaser LLC logo
LLM evaluation

When LLMs Judge LLMs, Who Judges the Judges?

I set out to build a harness that would let an AI act as a neutral judge. Along the way, I stumbled onto family biases, disagreements that stuck around even after careful checks — and, unexpectedly, a much trickier question than just "which model is best?"

Edgecaser LLC · 8 min read · Originally published on Medium, April 15, 2026
Three brass balance scales side by side on a cream background, each tilted a different way.

The moment the whole thing got weird

I've been tinkering with Shipwright, an open-source toolkit for PM agents. Lately, I got curious: how would the major models handle the same set of questions? I wanted a way to compare their outputs without having to judge every result by hand.

So I needed some kind of judge I could trust — or at least poke at. Something that could look at two artifacts, score them using a rubric, and help me figure out which one actually came out ahead.

I thought the hard part would be building that harness. It turned out, it wasn't. The tricky part was realizing that the judge wasn't actually neutral.

I gave Claude and GPT the same 13 debates to judge. These were a mix of real-world cases from my career, current-day scenarios, and a couple of famous HBR cases. Same arguments. Same rubric. Same prompt. Same effort level.

Claude picked side B in 9 out of 13 debates. GPT picked side A in 8 out of 13 debates. That didn't feel like random noise. It felt like I'd accidentally discovered that my "referee" had an opinion of its own.

I'm a biologist-turned-PM, so when something feels off, my first instinct is to run some controls.

A concrete example

One of the most revealing cases in the set was a scenario called handoff-contradiction.

The artifact was designed to stress contradiction handling: missing context, conflicting signals, and ambiguity about what was actually known versus inferred.

When I later ran an artifact-matched three-family replay on the exact same frozen inputs:

That's when the bigger picture started to come into focus. I realized I wasn't just comparing outputs — I was seeing different, often hidden, ideas of what actually makes a good artifact.

What I was building

I'm building an open-source PM agent toolkit called Shipwright (MIT). One part of it is a cross-model conflict harness: a structured debate where two model families produce competing artifacts through four rounds:

The debating sides are blinded to each other's identity. A third model then judges the final artifacts against a five-dimensional rubric:

The goal wasn't to crown a universal winner. It was to ask whether cross-family judging is stable, fair, and auditable when repeated.

That matters because "LLM-as-judge" is quietly becoming default infrastructure in agent evals, artifact review, ranking pipelines, and product decision systems. Most of us behave as if the judge is a neutral referee.

But it's not.

The controls I wanted before believing anything

I didn't want to over-interpret a flashy first result, so I tried to rule out the obvious confounds.

1. Frozen-artifact replay

Early runs mixed together two very different sources of variance:

That made it impossible to tell what I was actually measuring.

So I built a replay path that takes a completed run, freezes every artifact, and runs a new judge against the exact same saved verdict.prompt.txt and verdict.input.json.

From that point on, any variance is judge effect, not generation effect.

2. Artifact-matched three-family comparison

I picked five scenarios and made Claude, GPT, and Gemini judge the exact same frozen artifact bundle.

That let me compare judge families without side-generation drift.

3. Repeatability study

I ran Gemini 5x on the same frozen artifacts for three contradiction-heavy scenarios so I could separate one-shot weirdness from stable house style.

4. Rationale inspection

I extended the verdict schema so judges had to produce:

That made the reasoning legible, not just the final verdict.

What showed up

1. Claude and GPT lean in opposite directions

Table of judge decisions per model: Claude picked side A twice, side B nine times, with two ties. GPT picked side A eight times, side B five times, no ties. Gemini picked side A six times, side B four times, with three ties.
Decisions made per model

Two frontier judges, same debates, opposite directional lean.

That doesn't mean either model is useless. But it does mean neither one should be treated as an unbiased solo judge.

2. Gemini is genuinely distinct, not redundant

Gemini dissents from both Claude and GPT in 6/13 scenarios. It produces more ties, more low-confidence calls, and more needs_human_review flags.

That's valuable. It means Gemini is not just echoing one of the other judge families.

But that also means Gemini isn't just a simple "tiebreaker." It brings a different perspective, not necessarily a quick answer.

3. The Gemini bias story got narrower under scrutiny

At first glance, Gemini appeared to have a broad house-style bias toward decision_usefulness. On the full replay pass, it chose that as the decisive dimension in 10 of 13 cases.

That looked suspicious. But once I ran the repeatability study, the story got more specific.

prd-hidden-scope-creep. Across 5 repeated frozen replays:

So this case does not support the strongest version of the bias story.

event-automation-boundary. Across 5 repeated frozen replays:

So this also isn't a clean "Gemini always collapses to usefulness" case.

handoff-contradiction. This is the one that held up. Across 5 repeated Gemini replays:

And in the artifact-matched three-family comparison on the same frozen bundle:

So the strongest current conclusion is:

Gemini does not show a universal usefulness bias across all cases, but it does show a stable usefulness-led tendency on at least one important contradiction case.

That's a much narrower — and more useful — claim than the sweeping bias story I started with.

4. Some of the Gemini skew appears to be selection-layer bias

When I inspected the per-dimension rationales, Gemini often did reason sensibly about evidence discipline and internal consistency.

In handoff-contradiction, for example, Gemini acknowledged the evidence-discipline tension clearly. But it still named decision_usefulness as decisive.

That suggests a narrower problem than "Gemini can't reason about evidence issues."

The more plausible interpretation is:

That's interesting because it means some of the failure may be in the final labeling step, not the whole reasoning process.

5. The operational caveat: Gemini required repair every time

This part matters a lot if you're thinking about production use.

All 13/13 Gemini replay verdicts in the richer schema path required one repair pass before becoming schema-valid JSON.

That means:

So while Gemini is definitely interesting from an analysis standpoint, needing to fix its output every time makes it a tough pick as a default judge right now.

What I changed my mind about

At one point I thought Gemini might be the best default single judge because it was the most willing to abstain, tie, and surface uncertainty.

After more testing, I changed my mind.

If I had to pick a default solo runtime judge today, I would choose GPT.

Not because GPT is unbiased — it isn't.

I would choose it because:

So here's where I've landed for now:

What this means for LLM-as-judge systems

Three things stood out after all the checks.

1. Don't use a single model family as a neutral arbiter

If your evaluation system is only one model family deep, it has a bias profile you probably can't see from the outside.

2. Triple-panel evaluation should be an escalation, not a default

Running three judges on everything is expensive and noisy.

The better pattern is:

3. Ties should be routing events, not dead ends

A useful judge shouldn't stop at: "I can't decide."

It should also say:

That pushes the verdict from "score" toward "workflow signal," which feels much more useful in practice.

What I'm not claiming

Why I'm sharing it

Because I have a hunch a lot of us are building on LLM-as-judge assumptions we haven't really put to the test.

The biggest thing this project gave me wasn't a ranking of models. It was a better question:

What exactly is my judge optimizing for when it says one artifact is better than another?

If you're building eval infrastructure, the frozen-artifact replay pattern may be worth stealing. It was the single most useful methodological move in the project.

If you're using LLM judges in production, I'd strongly suggest:

The harness, schemas, and the full correspondence where I argued through the methodology with Codex and Claude are all in the repo. I kept the memos because I wanted the conclusions to be inspectable, including the parts where the story got narrower or changed.

Shipwright is MIT-licensed. If you think my method is off, I'd honestly rather hear about it than hold on to a flattering result.

Repo: github.com/EdgeCaser/shipwright
Review correspondence: docs/review/ on the codex/cross-model-debate-harness-spec branch

Relying on an LLM judge somewhere in your product?

If model evaluation is quietly load-bearing in your pipeline, Edgecaser can help you check what the judge is actually optimizing for before you build on the verdicts.

Let's talk about your product