Evals are just unit tests that hurt your feelings

There is a particular kind of silence that falls over a team the first time a model quietly gets worse in production and nobody notices for a week. This post is about never sitting in that silence again.

The shape of the problem

A unit test asserts that a function returns the value you expect. An eval asserts that a model behaves the way you expect, except the model has opinions, the inputs are fuzzy, and “correct” is a distribution, not a value. That doesn’t make evals optional. It makes them the most important tests you’ll write.

Here’s the harness in miniature:

def eval_case(prompt: str, must_contain: list[str]) -> bool:
    out = run_model(prompt)
    return all(token in out for token in must_contain)

It runs. Eventually.

What to actually measure

• Regression: did a change make a known-good case worse?
• Drift: is the same prompt giving different answers over time?
• Cost: are you paying more tokens for the same outcome?

The number on the dashboard should mean what someone thinks it means. Everything else is decoration.

Write the boring ones first. The boring parts are boring on purpose.