Evals Are the New Tests

The first time an LLM feature I shipped broke in production, every unit test was green. The regression was subtle: a prompt tweak meant to fix hallucinations on medical queries had quietly made the model refuse to answer anything that mentioned a body part. The tests were checking that the endpoint returned 200 and the JSON parsed. Both were true. The output was still garbage. That's the gap evals close. A unit test asserts that add(2, 2) == 4. An eval asserts that when a user asks "what's a good beginner CrossFit workout," the model returns something that (a) actually contains a workout, (b) doesn't recommend a 400lb deadlift, and (c) isn't 800 words of preamble about consulting a doctor. None of those checks are equality assertions. All of them matter more than the HTTP status code. Every serious LLM product I've looked at in the last twelve months — Cursor, Perplexity, Harvey, the Anthropic apps team, Vercel's v0 — ships with an eval harness that runs on every prompt change. If you're building on GPT 5 or Claude Sonnet 4.5 or Llama 4 Maverick without one, you're flying blind. This post is how to stop. Unit tests assume determinism. LLMs don't give you that. The core assumption behind assertEqual is that the function under test is a pure mapping from inputs to outputs. Change the inputs, the output changes predictably. Change nothing, the output stays the same. That model breaks the second you introduce a temperature 0 sampler and a model provider that silently updates weights. Three specific things unit tests can't catch in LLM code: Semantic regressions. Your prompt change makes the summary technically correct but three times longer. Unit test passes (string is non empty, ends with period). User churns. Model drift. OpenAI ships GPT 5.1 as…