Write the evals before you write the prompt
The single habit that separates AI features that improve over time from ones that silently get worse.
·2 min read·evals
Here is the most common way AI features get built: someone writes a prompt, tries five examples by hand, tweaks it until those five look good, and ships. A week later a user reports a bad answer. Someone tweaks the prompt again. The five original examples quietly break. Nobody notices.
This is not a model problem. It is a missing test suite.
Evals are just tests for probabilistic code
An eval is a set of inputs, an expectation for each, and a way to score the output. That’s it. The difference from normal unit tests is that the expectation is often fuzzy (“mentions the refund policy”, “doesn’t invent an order number”) and the score is a rate, not a pass/fail.
You do not need a platform to start. You need:
- A small, honest dataset. Twenty to fifty real inputs, including the ugly ones: typos, ambiguous requests, adversarial users.
- A grader per behaviour. Some checks are plain code (valid JSON, contains a citation, under 200 words). Some need a model as a judge, with a tight rubric.
- A number you track. Run it on every change. If the number drops, you don’t ship.
type Case = { input: string; mustMention?: string[]; mustNot?: RegExp[] };
function grade(output: string, c: Case): boolean {
const mentions = (c.mustMention ?? []).every((m) => output.toLowerCase().includes(m));
const clean = (c.mustNot ?? []).every((re) => !re.test(output));
return mentions && clean;
}
Twenty lines of code like this will catch more regressions than a week of manual testing.
Why “before the prompt”
Writing the evals first forces you to decide what good means before you get attached to a particular prompt. It turns vague requirements into examples, and it gives you a baseline to beat. Every later change, whether a new model, a new retrieval strategy or a cheaper tier, becomes a measurable experiment instead of a vibe check.
Start this week
Pick one AI feature you own. Collect twenty real inputs. Write down what a good answer must and must not contain. Score your current version. Whatever the number is, you now know something your team didn’t know yesterday, and you can make it go up on purpose.