LLM as a judge: a reviewer that tries to refute the work

LLM as a judge means a language model grades work against written criteria, instead of a person or an exact test. It works when the judge has the criteria in writing, sees the evidence, answers in a fixed format and cannot overrule the checks a machine can do.

We run one on every pull request our AI agent opens. It is not asked whether the work is good. It is told to try to refute it. This is how it is built, and the rules we added each time it got something wrong.

What is LLM as a judge?

The term comes from evaluating chat models. Instead of paying people to compare answers, you ask a strong model to do it. The paper that named it, Zheng et al., measured how well that works:

The same abstract names the limits: "position, verbosity, and self-enhancement biases, as well as limited reasoning ability". A judge prefers the answer it saw first, the longer one, and the one that sounds like itself. Keep those three in mind. Every rule below fights one of them.

Today the idea is used far beyond chat benchmarks: grading retrieval answers, scoring agent runs, and reviewing code. Ours does the last.

When should you not use an LLM judge?

When a cheaper check gives the right answer. A judge is slow, costs tokens and can be wrong. Code that checks a fact is none of those.

The classifier row is a real one. For a client's online marketplace we tuned an LLM that sorts listings into categories. We did not ask another model whether the categories looked right. We labelled real listings by hand and let code count the matches. When there is a correct answer, a judge only adds noise.

How does our LLM judge review a pull request?

The judge is the VERIFY step in our agent loop, and an advisory check on pull requests people open. Same parts in both:

The call itself is a few lines. This is the step in our shared CI action, slightly shortened:

prompt="$(cat "$L/verify.md"; data "$W/asked.md"; data "$W/checks.txt")"
npx -y @anthropic-ai/claude-code -p "$prompt" --tools "Read,Grep,Glob" \
  --json-schema "$(cat "$L/verify.schema.json")" --output-format json --max-turns 40 > "$W/raw.json"
verdict=$(jq -r .verdict "$W/verify.json")
[ "$mrc" != 0 ] && [ "$verdict" = pass ] && verdict=fix   # a red machine check is never overruled

--json-schema makes Claude Code return output that matches the schema (CLI reference, as of 2026-10-24). data wraps the issue and the check log in markers, and the prompt says that everything between them is data written by others, not instructions. An issue body cannot talk the judge into a pass.

The last line is the most important one. If the tests are red, no verdict turns that into a pass. The same gate also fails a task branch that moves a submodule pointer, a rule we explain in Monorepo vs polyrepo.

What did the judge get wrong, and what did we change?

Every rule in the judge's prompt came from a real miss. Four of them:

• Tests that prove nothing. The agent wrote tests that read source files as text and checked that an import was there. Green, and useless. The judge now has to open every new or changed test, and a test that does not exercise behaviour is a required finding.
• Moving goalposts. On the second round the judge found new, smaller problems in code that had not changed, so the loop never ended. Now a later round gets the previous findings and checks only those.
• Letter instead of intent. It flagged exact counts, wording and table layout that differed from the issue, while the intent was met. Now a finding is required only if a human reviewer would send the work back for it.
• The same finding forever. Findings carry a stable id. If the same id comes back two rounds in a row, another round will not fix it, so the loop stops and asks a person.

The worst miss was not the judge's at all. Earlier this year our AI code review in CI passed on every pull request and did not post a single review. An upgrade of the underlying action had dropped two inputs, and the job exited green with no prompt. A judge that never ran looked exactly like a judge that approved. Today a missing or invalid answer is its own verdict, unavailable, and it fails the job.

Which judge biases still apply?

All three from the paper, in a smaller form:

• Position bias matters most when a judge compares two answers. Ours grades one piece of work against criteria, so there is no first or second answer to prefer.
• Verbosity bias pushes a judge toward long answers. The schema limits what counts: a verdict, findings with evidence, a summary of a few sentences.
• Self-enhancement bias is the one we have not removed. Our judge is the same model family as the agent that wrote the code. A fresh session, the refute prompt and the machine checks reduce it. They do not make it go away.

Using a different model as the judge is the obvious next step. We do it by hand for texts, and we have not wired it into the loop yet.

Is your LLM judge ready for real work?

Go through your setup:

How the reviewer that comments on every pull request is set up in GitHub Actions is in Claude Code review: AI code review in CI. Why a red test before the fix matters is in Red-green TDD with AI agents.

Want a reviewer that sends bad pull requests back?

We set up the machine checks, the judge and the CI around them right in a team's repository as part of AI-native SDLC for development teams. Is your team short of hands rather than review? See a senior developer for your team. AI writes all of our code today, and a senior is accountable for the result. Since 2023 we have delivered 15+ production projects.

We get back to you within two business days, and together we pick what to fix first.

If you'd rather talk first, book a 15-minute meeting with Filip.

What does your AI reviewer do when it has nothing to say: stay silent, or fail?

Frequently asked questions

What is LLM as a judge?

Using a language model to evaluate the output of another model, or of an agent, against written criteria, instead of a person or an exact-match test. The judge gets the task, the criteria and the evidence and returns a verdict, ideally as structured data.

How accurate is LLM as a judge?

In the MT-Bench and Chatbot Arena study, strong judges such as GPT-4 reached over 80 % agreement with human preferences, about the level at which humans agree with each other. The same paper names position, verbosity and self-enhancement biases. Accuracy depends on the task, so measure it on yours.

When should you not use an LLM judge?

When there is a right answer you can check with code: a test, a type check, a link check, or a label set made by people. A judge is for criteria that need reading and judgement, such as whether a change does what the issue asked.

Can the same model judge its own work?

It can, but it tends to favour its own style, which the literature calls self-enhancement bias. We reduce it with a fresh session that did not do the work, a prompt that asks it to refute, machine checks it cannot overrule, and a person who merges.

What should an LLM judge return?

A typed answer, not prose: a verdict from a fixed set, and findings with a stable id, a severity, where the problem is and the evidence. Code can then act on it, and a missing or invalid answer counts as a failure, never as a pass.