Who Judges the Judge? The Hidden Bias in LLM-as-a-Judge
More and more agent loops put an LLM in the grader's seat — scoring outputs, gating merges, ranking candidate patches. But the judge has systematic biases, and they're not the ones you're guarding against. A 2026 study found style bias dominates at 0.76–0.92 across every model tested, an order of magnitude larger than the position bias everyone worries about (≤0.04). In code evaluation specifically, a judge's verdict can flip on prompt cues even when the code is unchanged — enough to alter model rankings. If your verification gate is an uncalibrated LLM judge, you may be scoring polish and prompt artifacts, not correctness. Here's how to calibrate it.
As agent loops get more autonomous, a quiet substitution happens: somewhere in the loop, a human stops grading the output and an LLM starts. It’s almost unavoidable at scale. You can’t manually review every candidate patch, every generated test, every draft an agent produces — so you ask another model to score them, rank them, and decide which one proceeds. LLM-as-a-judge has become the default evaluator of the agentic era, sitting inside verification gates, leaderboards, and patch-selection loops.
Which raises the question nobody asks often enough: who’s checking the judge? Because the 2026 research is clear that the judge has systematic, measurable biases — and they are not the biases most teams think to guard against.
The bias you’re not watching
When people worry about LLM judges, they usually worry about position bias — the judge favoring whichever answer was shown first. It’s real, it’s well-known, and most serious eval setups already control for it by swapping order. The problem is that position bias turns out to be the small one.
A 2026 study, Judging the Judges (arXiv 2604.23178), measured nine debiasing strategies across five judge models from four provider families (Google, Anthropic, OpenAI, Meta) over three benchmarks. Its headline finding reorders the threat list: “Style bias is the dominant bias (0.76–0.92 across all models), far exceeding position bias (≤ 0.04), yet has received minimal research attention.” Read the magnitudes again. The bias toward polished, confident, well-formatted presentation runs an order of magnitude larger than the one everyone already controls for — and it’s the one almost nobody measures.
That should land hard, because style is exactly the dimension a capable generator is good at maximizing independent of substance. A model can produce confident, fluent, nicely-structured output that’s wrong, and a style-biased judge will reward it. The study does note a reassuring nuance — judges distinguish quality from raw length fairly well (0.92–1.00 accuracy on truncation controls), so it isn’t a naive “longer = better” effect. It’s subtler and more dangerous than that: the judge is swayed by presentation, the very thing that correlates with neither correctness nor the thing you’re trying to measure.
In code, the verdict flips on cues, not substance
For anyone using a judge to evaluate code, it gets more pointed. A companion 2026 study, Bias in the Loop: Auditing LLM-as-a-Judge for Software Engineering (arXiv 2604.16790), probed judges across code generation, code repair, and test generation — exactly the agentic-SE settings where, in its words, a judge “can help rank candidate solutions and guide patch selection.”
The finding is unsettling: “judge decisions are highly sensitive to prompt biases even when the underlying code snippet is unchanged.” Same code, different presentation cue, different verdict. Worse, the biases “systematically shift preferences toward the option favored by the prompt, improving accuracy when that option aligns with the gold answer but substantially reducing it otherwise” — and “in some settings, these effects are large enough to change task-level conclusions and alter relative model rankings.” The authors’ conclusion is blunt: “reported judge performance may reflect prompt artifacts rather than stable assessment ability, posing a direct threat to the validity and reproducibility of code evaluation.”
Sit with what that means in a loop. If a judge selects which patch an agent ships based partly on presentation artifacts, the bias doesn’t stay in the evaluation — it flows into your codebase, one selected patch at a time. The gate you installed to catch bad output is itself making decisions for reasons that have nothing to do with whether the output is good.
Picture two candidate patches for the same bug. One is correct but terse — no comments, a blunt variable name, a one-line fix. The other is subtly wrong but beautifully presented — a thoughtful comment explaining its reasoning, descriptive names, a clean structure. A style-biased judge, asked which to merge, leans toward the confident, well-dressed wrong answer. A human reviewer rushing through a queue would make the same mistake — but we deployed the judge precisely to be the rigorous check the rushing human isn’t, and instead it has automated the same bias at scale and at machine speed.
Why this is worse than a noisy metric
A noisy evaluator you could live with — noise averages out over enough samples. Bias doesn’t. It’s systematic and it’s correlated with the wrong signal, so more samples don’t wash it out; they entrench it. Three consequences follow, and each one bites a different decision.
First, leaderboards lie in a specific direction. A ranking built on a style-biased judge doesn’t just have error bars — it systematically over-ranks the model that presents best, which may not be the model that’s most correct. If you pick your agent off such a leaderboard, you’ve inherited the judge’s bias as your buying decision. This compounds the gap we wrote about in the reliability gap: the benchmark may already measure the wrong property, and now the judge scoring that benchmark adds its own distortion on top.
Second, your verification gate leaks. We’ve argued that a bad loop ships bad code faster — and a gate that scores polish instead of correctness is a bad loop wearing a lab coat. It feels rigorous because there’s a number attached, but the number is partly measuring the wrong thing.
Third, the failure is invisible. A biased judge doesn’t throw an error; it returns a confident score. Nothing in the pipeline signals that the score reflects presentation rather than substance. You only discover it when the “evaluated, approved” output fails in production — by which point the judge has been quietly steering the loop wrong for a long time.
Calibrate the judge — don’t trust it
The fix isn’t to abandon LLM-as-a-judge; at scale there’s often no alternative. The fix is to stop treating the judge as an oracle and start treating it as an instrument that needs calibration. A few principles follow directly from the research:
- Measure the judge’s bias sensitivity, not just its accuracy. Bias in the Loop argues exactly this: report bias sensitivity alongside accuracy, and run controlled interventions that isolate one presentation cue at a time. An accuracy number with no bias audit is half a result.
- Debias deliberately — but verify it helped. Debiasing works, but it’s model-dependent: Judging the Judges found the combined-budget strategy improved Claude Sonnet 4 by +11.2 percentage points, with only 2 of 20 non-baseline configurations actually decreasing agreement. So mitigation is worth doing, but it’s not free or universal — you have to check it landed for your judge.
- Prefer verifiable signals where they exist. When the question is “does this code work,” a test suite is an unbiased judge — it doesn’t care how confident the comments sound. Reserve the LLM judge for the genuinely subjective calls, and let executable verification carry the rest.
- Never let one un-audited judge gate anything that matters. Swap positions, vary the presentation, use a panel, and treat a clean judge score as a hypothesis to confirm, not a verdict to act on.
The throughline: a judge is part of your measurement apparatus, and an uncalibrated instrument produces confident, precise, wrong readings.
Why this favors Southeast Asia
Here’s the part that matters for this region, and it’s the familiar shape. Auditing and calibrating an evaluation harness is pure engineering judgment — it costs no GPUs, no frontier model, no capital. It’s the work of designing controlled tests, probing for bias, and refusing to trust a number you haven’t interrogated. That’s a discipline a focused team builds deliberately, and it’s worth more than it looks.
Because most of the market is doing the opposite: trusting vendor leaderboards and raw judge scores at face value, inheriting biases they never measured. A team in Phnom Penh or Da Nang that builds its own bias-aware evals — that knows its judge over-rewards polish and corrects for it — can trust its measurements when competitors can’t, and pick the genuinely better model and the genuinely better patch while others chase presentation. This is the loop-engineering discipline applied to the part of the loop that decides what “good” even means. Get the judge wrong and every downstream decision inherits the error; get it right, cheaply, and you’ve built a measurement advantage no amount of compute can buy.
The agent will keep generating, and you’ll keep needing something to grade it. Just remember that the grader has opinions of its own — and the most underrated job in the agentic stack is making sure those opinions are about the right thing.