Write the eval set before you write the feature

The difference between an AI demo and an AI product is almost never the model. It is whether the team can answer "did that change make it better?" with evidence.

By OneShopAI · · 4 min read

Why does judging AI output by feel fail?

Prompt changes interact in ways nobody predicts. You add a line to fix the case in front of you, it works, you ship it — and it has quietly changed the behaviour on three other kinds of input you were not looking at. This is the normal outcome, not the unlucky one, and without a fixed set of cases you will not find out until a user does.

It is also why teams argue about prompts for hours. Two people with different favourite examples will reach opposite conclusions from the same change, and neither can prove anything.

How many test cases does an eval set need?

The barrier people imagine is a big labelled dataset. It is not necessary. Twenty to fifty genuine inputs, each paired with what the right output would have been, is enough to catch the regressions that matter — because real inputs carry the messiness that synthetic ones sand off: the typo, the two questions at once, the pasted email with a signature block attached.

The best source is failures you have already seen. Every complaint, every wrong answer, every case someone screenshotted in a chat is a test case with the answer already known.

How should you score each eval case?

Not everything needs a sophisticated score. A surprising share of cases can be checked exactly: did it return valid JSON against the schema, did it contain the right order number, did it refuse when the input was out of scope, did it cite a source that exists. These cost nothing to run and never drift.

For the rest, write a short rubric — what a good answer must contain, what it must not claim — and score against it, by hand at first. Model-as-judge scales that up and is genuinely useful, but spot-check its scores against your own judgement before you start trusting the number.

When does writing evals first pay off?

Once the suite runs in minutes, the whole rhythm of the work changes. Switching models becomes a measurement rather than a leap of faith. Trimming an expensive prompt becomes safe, because you can prove the shorter one performs the same. Onboarding someone new stops being risky, because the suite catches what they did not know to check.

Build it before the feature and it costs an afternoon. Build it after launch and you spend the months in between unable to answer the only question anyone will ask you about any change you make.