Evals or It Didn't Happen: Testing LLM Features

Shipping an LLM feature by clicking around until it 'seems good' is how you end up silently breaking it three prompt-tweaks later. The output is non-deterministic and 'correct' is fuzzy, but that's an argument for more rigour, not less.

Start with a tiny eval set

You don't need thousands of examples to start — you need twenty good ones. Collect real inputs, especially the ones that have burned you, and write down what a good answer looks like for each. That set is now the thing you're actually building against.

Grade with a mix of methods

Some things you can assert on hard: valid JSON, the right fields, a number in range, no banned phrases. For the fuzzy parts — is this answer faithful, helpful, on-tone — use an LLM as a judge with a clear rubric. Hard assertions catch the obvious breakage; the judge catches the drift.

Run it in CI like any other test

Wire the eval set into your pipeline so a change that tanks quality fails the build, exactly like a unit test would. Now prompt changes, model swaps and refactors all get graded automatically, and 'it feels worse' becomes a number you can point at.

The takeaway

Evals are the unit tests of the LLM era. They turn a vibes-based feature into an engineered one — and they're the only reason you'll ever be able to change a prompt without holding your breath.