A few weeks ago, I wrote that evals are the new PRD, and the most useful thing you can hand an AI team is a test set full of graded examples.

It's no longer a spec full of requirements. A bunch of you wrote back with the same fair question. But how do you actually grade the answers?

It's the right thing to get stuck on. When you test a normal feature, grading is easy. The checkout charges the right amount, or it doesn't.

The date shows as 30 May, or it doesn't. You compare the output to the expected, and mark a tick or a cross. Now, picture the thing you are testing as a support bot.

A customer asks: "I was charged twice, what do I do?" There are a hundred good answers. A warm one. A blunt one. One that leads with an apology, one with the fix.

There's no single correct string to compare against. The "right answer" isn't a value but a quality, and quality doesn't fit through a string match.

For a while, the only thing that could judge quality was a person, marking each output as good, wrong, correct, but rude. That works right up until you have scale.

A person can carefully grade fifty answers.

They can't grade fifty thousand, and definitely not every time an engineer tweaks a prompt and wants to know in ten minutes whether it helped.

The human becomes the bottleneck.

The evals you were so proud of just sit there, ungraded.

This idea breaks the bottleneck, and it might sound slightly mad at first.

If a human can judge quality but can't scale, use the one machine that can scale and make a passable impression of judging quality.

It's another language model. This is LLM-as-a-judge. You take a second model and give it a job that has nothing to do with helping the customer. Its only task is to grade.

You give it three things: the input, the output you want assessed, and a rubric that tells what "good" means. It returns a verdict and reasoning.

That last bit matters more. Instead of you asking for a vibe, you are asking it to apply your written definition of good and show its working.

The rubric is the product decision. The model applies it at a speed no human can touch.

Think of it like marking exams. One brilliant examiner can't personally mark a hundred thousand papers, so exam boards have that examiner write a mark scheme, a document saying what earns a mark, and an army of markers applies it to every paper.

LLM-as-a-judge is the same trick. The rubric is the mark scheme.

The judge model is the army of markers.

You, the PM, are the chief examiner deciding what a good answer even is. Get the scheme right, and it scales. Get it vague, and thousands of papers get marked badly.

Also read: What are Evals and Why They are Important: A Guide for PMs

There isn't just one flavour of this. The original research from a Berkeley-led team put the technique on the map, laying out three modes you will meet in practice.

You show the judge one output and ask it to score that against the rubric. "Here's the question, the answer, and what good looks like. Grade it."

This is the workhorse. It tells you whether an answer is acceptable.

You show the judge two answers to the same question, A and B, and ask which is better, or whether it's a tie. You don't get a score, but a winner.

You use this after changing a prompt or a model to know whether version B beats version A. Models are often better at picking between two answers than at scoring one alone.

This is the same as the way you can pick the better of two coffees more reliably than you can score one out of ten.

Sometimes you do have a correct answer, such as a known fact, a worked sum, or the actual policy from your help centre. You hand the judge that reference next to the output and grade against it.

It's the closest to old-school marking, except the judge checks whether the meaning matches. The reference says refunds take 5–7 days. But the bot said, "About a week."

A string match says no, and a judge says yes.

This stays fuzzy until you see one, so let's make it real. Say our support bot sits on top of a help centre, and we care about two qualities.

A common mistake here is to ask the judge for a score out of ten.

Models are shaky at fine-grained numbers. The same answer might score a 6 on one run and an 8 on the next, and "7 out of 10" tells you nothing you can act on.

The more reliable move, pushed by most eval tooling teams, is a binary verdict with a sharp definition of each outcome. Pass or fail. Faithful or not.

If you need nuance, grade several narrow yes/no checks rather than one fuzzy out of ten. So the faithfulness rubric you hand the judge might read:

Now feed it a real case.

The context says: "Refunds are processed within 5–7 business days." The bot replied: "You'll get your refund instantly, usually within a few minutes."

The judge comes back:

That's the whole thing, and it's worth sitting with how unmagical it is. The judge didn't know anything special. It applied a definition you wrote, explained itself, and it will do that a thousand more times before you have finished your coffee.

That is what makes evals scale: not the model being clever, but the model being a tireless, consistent applier of a standard you set.

The catch is whether you can trust the applier.

Here's where it would be easy to get lulled, so let me be blunt.

A judge model is not a neutral oracle. It's a language model, so it ships with the same wonky instincts as every other one, and if you don't design around them, it grades things wrongly in predictable ways that corrode every decision you make off it.

The same research paper that mapped the technique also catalogued its failure modes. Three matter most.

Show a judge two answers and ask which is better, and it tends to favour whichever it saw first, regardless of which actually is.

The researchers found that simply swapping the order could flip the verdict. It's the same answers but a different order and winner.

The fix is mechanical and non-negotiable.

Run every comparison both ways, A then B, and B then A, and only count a result if the judge picks the same winner both times. If it flips when you flip the order, it didn't have an opinion. It had a seating preference.

Judges tend to prefer longer, more elaborate answers even when the longer one isn't clearer or more correct, sometimes mainly when it isn't.

The paper showed you could win the judge over with a padded answer that added words but no substance. Length reads as effort.

The fix is to tell the judge to ignore length and grade on substance, and keep compared answers a similar length where you can.

Length-neutral wording in the rubric cuts the bias in half.

This is the one that should make you most uncomfortable.

The researchers named it self-enhancement bias: models tend to favour answers they themselves generated, or from the same model family.

GPT-4 preferred GPT-4's answers. GPT-3.5 preferred its own.

Which means the most tempting setup, let the model that wrote the answer also grade it, is the one most likely to flatter itself. Letting a model mark its own is a measurable defect.

The fix is obvious. Don't let a model grade its own output. Use a different judge from the model under test, so the marker has no stake in the result.

(There are others... judges can be swayed by a confident tone or by formatting. But these three are the ones to design around from the start.)

Also Read: Everything You Must Know About Mixture of Experts (MoE)

By now, the promise is obvious: write a rubric once, grade forever, for pennies. So it's tempting to read all this as "automate the humans away."

But it isn't. The humans move, but they don't leave.

This question should be nagging you: if the judge is just another fallible model, how do you know its verdicts are any good?

You don't unless you check. How you check is the same discipline I keep coming back to: you treat the judge itself as something to be tested.

In practice, that means building a small set of examples humans have graded carefully by hand, your gold-standard answers, then running the judge over that set and measuring how often it agrees.

You are evaluating your evaluator. If it agrees most of the time, you can trust it on the thousands of cases no human will ever look at.

If it doesn't, you don't fix the bot. Instead, you fix the rubric, rerun, and check again until the judge and the humans line up.

This is also where that reassuring statistic you may have seen needs care.

The 2023 study found that a strong judge agreed with human preferences over 80% of the time. In the clear-cut cases, GPT-4 touched around 85% agreement with humans, slightly higher than two humans agreed with each other (about 81%).

That number gets quoted a lot, usually to argue that the judges have basically solved it. Read it the other way.

It says judges are good enough to be useful, and that human judgment is itself messier than we admit, not that the judge is right every time.

Roughly one in six verdicts still diverged from people. Your bot, your cheaper judge: assume your number is lower until you have measured it.

So the loop never fully closes. You don't human-review every output.

That was the whole problem you were running from. You review a sample of its verdicts regularly to catch it drifting from what you mean by good.

The model does the grading. The humans keep the grader honest.

That's the real shape of testing AI in 2026.

Two models in a conversation, neither experiences, one answering and one marking, thousands of times an hour while everyone's asleep.

It holds together only because upstream, a person decided what "good" means and wrote it down clearly enough for a machine to apply.

The hard part was never the grading. It was being able to say, precisely, what a good answer is. The judge just makes you write it down.