EngineeringHafsteinn Runarsson · AI Konsulent02 Apr 2026 · 9 min

Evals are the new unit tests

You would not merge code without tests. Yet teams ship prompt changes to systems that talk to their customers with nothing but a vibe check: run it twice, looks good, deploy.

An eval is to an LLM feature what a unit test is to a function: a fixed input, an expected judgement, and a score you can trend. The difference is that the function was deterministic and your model is not — which makes the harness more necessary, not less.

Building one is less work than it sounds. Start with fifty real cases pulled from actual traffic — the weird ones, the borderline ones, the ones that went wrong. Write down what a good answer looks like for each, in a rubric precise enough that two people would score it the same way. Then score every change against the set before it ships.

The rubric is where the real thinking happens. Vague criteria produce vague systems. The discipline of writing what correct means — cites its source, refuses out-of-scope requests, never invents an order number — is the same discipline that makes the feature good in the first place.

Two habits keep the harness alive. Feed it: every production failure becomes a new case, so the suite grows teeth over time. And gate on it: the score is not a dashboard curiosity, it is the thing that has to go up — or at least not go down — before a change reaches users.

Models drift, prompts accumulate fingerprints, and the person who wrote the original prompt leaves. The eval set is the institutional memory of what the system is supposed to do. Treat it like your test suite, because that is exactly what it is.