Skip to content
releo

Engineering

Deterministic verification vs LLM-as-judge for code changes

LLM-as-judge, using a model to score the output of another model, is a reasonable technique for evaluating things that have no ground truth, like the tone of a summary. It has quietly spread to a domain where ground truth does exist: code changes. When a model writes a patch and a model then declares the patch correct, the result looks like verification. It is not.
By the Releo team · · 5 min read

What LLM-as-judge looks like for code

In code tooling the pattern usually takes one of these forms:

  • An agent writes a patch, then is asked "does this change preserve behavior?" and answers yes or no.
  • A second model reviews the diff and assigns a confidence score that gates an automated merge.
  • A model reads test output or logs and summarises whether the change "looks safe".

Each of these produces a judgment in fluent language, often with a plausible rationale. None of them produces a fact about what the code does when it runs.

Why a model grading its own patch is not evidence

Evidence, in the engineering sense, is something a skeptical reviewer can check independently. A judgment from the same model that wrote the patch fails that test for several reasons.

  1. Correlated errors. The misunderstanding that produced a bug is the same misunderstanding the model brings to reviewing it. If it believed amount was in dollars when writing the patch, it will believe so when grading it. A different model reduces but does not remove this, since models share training data and failure modes.
  2. The judge reads code, not behavior. A model reasons over source text. A breaking change in an upstream API, a different default in a library, or a subtle ordering change only shows up when code executes against real inputs.
  3. Persuasive is not correct. Models are trained to produce convincing answers. A wrong verdict with a confident explanation is more dangerous to a reviewer than no verdict at all, because it lowers their guard.
  4. Scores are not calibrated to risk. A "92% confident" from a judge model has no stable relationship to the probability that the change is safe. It cannot be compared across runs, models or repositories in any meaningful way.

What deterministic verification gives you

Deterministic verification means the pass or fail signal comes from executing the code and comparing observable outcomes against a reference, with no model in the decision. Compilers, type checkers, test suites, property-based tests and traffic replay all fit. Three properties matter.

Reproducibility

Run the same check on the same inputs and you get the same answer. That makes failures debuggable: you can rerun them, bisect them and fix them. An LLM judge can give different verdicts on identical inputs depending on sampling, prompt wording and model version.

Auditability

A deterministic check leaves an artifact: the inputs, the expected output, the actual output and the diff between them. A reviewer, an auditor or the next engineer on call can read it months later and reach the same conclusion. "The model said it was fine" does not survive an incident review.

Falsifiability

A good check can fail, and when it does it points at the exact divergence: this request, this field, this value. That is the property that turns verification from a ritual into information.

Tests alone are deterministic but incomplete

Deterministic does not automatically mean sufficient. A test suite is deterministic, but it only checks the behavior someone thought to test, and client tests often run against mocks that freeze the old behavior of an API. That is exactly why breaking changes slip through green builds.

For changes that touch API behavior, the stronger deterministic signal is differential: run the old code and the new code against the same recorded real inputs and compare everything they produce. It does not require anyone to have anticipated the failure; it only requires that the change in behavior be observable. A good behavioral diff is explicit about what that comparison should and should not include.

Where LLMs are genuinely useful

None of this argues against using models in the loop. It argues for putting them where their strengths matter and their weaknesses are contained.

  • Generating patches. Models are good at the mechanical and semi-mechanical work of an API migration: finding call sites, rewriting them to a new interface, adjusting surrounding code. A wrong patch is cheap when a deterministic check will catch it.
  • Proposing hypotheses. When a replay shows a divergence, a model can suggest why, which points a human at the likely cause faster.
  • Writing the explanation. A model can summarise what a verified change does for the PR description. The summary is narrative; the verification result is the evidence.
  • Triage of genuinely subjective questions. Naming, readability and documentation quality have no ground truth, and a model opinion is a reasonable input there.

The rule of thumb: let models propose, and let execution decide.

Designing a pipeline that keeps the two apart

A practical structure for automated code changes looks like this:

  1. A model generates the candidate patch.
  2. Static checks run: build, types, linters, existing tests.
  3. Differential verification runs: recorded inputs through old and new code, full outputs compared under explicit rules.
  4. The merge gate reads only the deterministic results. Any unexplained divergence blocks.
  5. A model may then write the summary, which links to the raw verification artifacts.

This is the split Releo uses: models write the migration PRs, and replayed real traffic decides whether they can merge. The model never grades itself.

Frequently asked questions

Is LLM-as-judge ever appropriate for code?

For subjective qualities such as readability or naming, it can be a useful input. For correctness or behavior preservation, where ground truth can be obtained by running the code, a deterministic check should make the decision.

Does using a different model as the judge solve the problem?

It reduces correlated errors but does not remove them, and it still judges source text rather than runtime behavior. It also remains non-reproducible and hard to audit.

What counts as deterministic verification?

Any check whose verdict comes from executing code and comparing outputs against a reference, with the same result on every run: compilation, type checks, tests, property tests and differential replay of recorded traffic.

More from the blog

Coming soon

Ship API changes without breaking your customers.

Releo is in private beta. Join the waitlist for early access.