Deterministic verifiers vs. LLM-as-a-judge: how to score agent work

Use a deterministic verifier whenever agent work can be checked in code: it is reproducible, cheap and, if its checks cover what matters and the agent cannot reach them, harder to fool than a judge. Use an LLM judge only for qualities code cannot measure, such as tone, with a rubric, and never for hard pass or fail rules.

This article defines both approaches, compares them, summarises the known biases of LLM judges and shows hybrid designs. It belongs to the series on verification and rewards; the overview is RLVR, explained.

What are deterministic verifiers and LLM judges?

A deterministic verifier is code that always gives the same score for the same final state, because it uses explicit checks and fixed references instead of a model's judgement. LLM-as-a-judge is the practice of asking a large language model to grade or compare outputs, usually with instructions or a rubric. A rubric is a written list of criteria, each with a description of what earns which score.

The difference is not only technical. A verifier encodes a definition of correct work that someone wrote down in advance. A judge brings its own learned sense of what good work looks like, which may or may not match the task's rules.

Unit tests for code are the most familiar deterministic verifier. Chen et al. (2021) evaluated generated programs by functional correctness, where a sample counts as correct if it passes a set of unit tests. Environments for agents apply the same idea to the final state of a simulated world.

LLM judges come in two main modes, both studied by Zheng et al. (2023). In pairwise comparison, the judge sees a question and two answers and picks the better one, or declares a tie. In single-answer grading, the judge assigns a score to one answer. Scoring an agent's message against a rubric is single-answer grading.

How do they compare?

Verifiers cost more to build and cover less, but what they check they check the same way every time. Judges are quick to set up and cover more, but their scores are softer and easier to influence.

A verifier is harder to fool than a judge when two conditions hold: its checks cover what matters, and the agent cannot change the checker, its references or the records it reads, except through the task's tools. Agents that modify tests or scoring code are the familiar counter-example; METR reported frontier models doing exactly that in 2025.

What biases do LLM judges have?

LLM judges show position bias and verbosity bias, and possibly self-enhancement bias. These biases are not random noise: they push scores in predictable directions, and a model trained against the judge is rewarded for following those it can influence, such as length.

Zheng et al. (2023) examined LLM judges on open-ended chat questions and discussed three biases:

• Position bias: preferring an answer because of where it appears, for example first.
• Verbosity bias: preferring longer answers, even when they are not better.
• Self-enhancement bias: preferring answers written by the judge model itself. The authors note that their data was too limited to determine whether the models they studied show it.

The same paper also reported a limitation in reasoning when grading questions such as maths, and a strong result in the other direction. GPT-4 as a judge agreed with human experts 85% of the time when ties were excluded, slightly more than the 81% at which the human experts agreed with each other. Judges are genuinely useful for comparing open-ended answers.

Position bias can be large in pairwise comparison. Wang et al. (2023) showed that the ranking of candidate answers could be changed simply by changing their order. In their experiments, with ChatGPT as the evaluator, Vicuna-13B could beat ChatGPT on 66 of 80 tested queries. Single-answer grading has its own weakness: Zheng et al. note that absolute scores are likely to fluctuate more than pairwise results if the judge model changes.

Why do Vencur's scores use no LLM judge?

Vencur's scores use no LLM judge because the parts of operations work that its worlds are designed to score can be checked exactly, and exact checks make better training targets. Qualities such as tone, which code cannot check, are left out of the reward; the trade-off is that the agent gets no training signal for tone.

Three reasons decide the choice:

1. Stable targets. Noisy rewards slow training and make runs hard to compare. A deterministic verifier gives the same final state the same reward every time; a judge need not.
2. No reward for style. If confident prose earns points, agents learn confident prose. Checking the state removes that path.
3. Auditable scores. Every lost point comes with a reason computed by code, which a buyer can read and check.

The DeepSeek-R1 authors made a related choice for DeepSeek-R1-Zero: they did not use a neural reward model, because it may suffer from reward hacking in large-scale reinforcement learning.

What hybrid patterns work?

Hybrids work when code decides correctness and a judge scores only what code cannot measure. Three patterns are useful.

Code gates, judge adds a small score. A gate is a check that sets the whole score to zero when it fails. Gates and correctness scores are computed in code, and a judge scores one separate quality, such as the tone of a message to a colleague, against a rubric, with a small weight. A wrong result still scores zero, however polite the message.

Code where possible, models where necessary. In its final stage of reinforcement learning, DeepSeek-R1 used rule-based rewards for reasoning data in maths, code and logic, and reward models for general data, to capture human preferences in complex and nuanced cases. TheAgentCompany splits by checkpoint: most of its evaluators are deterministic and written as simple Python functions, and the authors use LLM-based evaluation for checkpoints whose deliverables are less structured.

Judge for review, not for reward. A judge can flag episodes for a human to read, for example reports that look inconsistent, without its opinion entering the score.

What does a hybrid score look like in practice?

A hybrid score keeps correctness in code and gives the judge one small, separate part. The worked example below shows the structure.

In this example, a wrong decision fails a gate and scores zero, whatever the judge thinks of the messages. A correct decision with curt messages loses at most a fifth of the points. The judge influences how good the work is rated, never whether it counts.

A small weight is weaker protection than it looks. Once an agent passes the gates and maxes out the code scores, the judge's 0.2 is the only part of the reward that still varies, and optimisation concentrates on it. Gao et al. (2022) showed for reward models that optimising an imperfect proxy too far can hurt true performance, and a judge is such a proxy. Two mitigations help: cap the judge's part, for example by giving full marks above a rubric threshold, and check regularly whether rising judge scores still match human ratings.

How do you test a deterministic verifier?

Test a verifier like any other critical code, and then attack it like an agent would. A verifier that has never been tested against wrong answers has only shown that it accepts right ones.

• Known-good states. Save several correct final states, including valid alternatives to the reference, and check that each scores full marks.
• Mutations. Break one thing at a time in a correct state, such as an empty shift, a broken rest rule or a missing message, and check that the score drops by the expected amount with the right reason.
• Adversarial states. Build states an exploiting agent might produce: nothing changed, the report claims success, work that existed before the episode is presented as new. Each must score zero or lose the right points.
• Tampering. Try to edit the checker or its configuration, or to write directly to the files and records the checker reads. The verifier must run where the agent cannot write.
• Determinism. Score each saved state twice, and on two machines. The results must be identical. The usual causes of differences are timestamps, unordered iteration, floating-point rounding, time zones and network calls.
• Speed. Time the verifier on the largest states. Training calls it very often.

Keep these tests in the repository next to the verifier, and run them on every change. When a red-team attempt finds a gap, add it as a new test before fixing it.

How do you test an LLM judge?

Test a judge for the biases it is known to have, on examples where the right answer is known, and protect its part of the score. The expensive part is building a set of examples graded by people; the tests themselves are cheap to run.

Fix the prompt, the rubric and the model version, record them with every score, and never let a judge decide a hard rule, a required output or whether work was done. If a judge fails the length or order test, its scores should not enter a training reward. It may still be useful for flagging episodes for human review.

How do you decide for a new task?

Decide by asking, for each quality you want to score, whether code can check it from the final state. Then assign each quality to the right scorer.

1. List what makes the work correct. Illustrative example, for a roster: every shift covered, rules kept, the right person told.
2. Mark each item as checkable or not. Coverage and rules are checkable; the friendliness of the message is not.
3. Make the checkable items gates or weighted scores in code. Use Scoring agent tasks as a template.
4. Give the rest a rubric, and decide whether it needs a score at all. Often it is better left out of the reward than scored badly.
5. Test both parts. Red-team the verifier, and test the judge for length, order and agreement on known examples.

For evaluating agents more broadly, including how public benchmarks score them, see How to evaluate AI agents. Vencur's worlds are designed to score every episode in code; see Vencur Environments.