Vibes don't survive contact with production
Here's the loop nearly every team runs at first. Tweak the prompt. Try three inputs. They look better. Ship. Two weeks later something else is worse, and nobody can say when it broke or which change did it.
The problem isn't laziness. It's that LLM outputs have no single correct answer, so the assertion you'd normally reach for —
assert result == expected
— doesn't exist. Two summaries can be equally excellent and share almost no words. Exact matching would fail both.
That doesn't mean you can't measure. It means you measure differently, and the ladder goes like this.
1. Build the eval set first
Twenty to fifty real inputs, chosen deliberately rather than sampled randomly: the common cases, the edge cases, and every failure anyone has reported.
This is the highest-leverage hour in the entire project, and it is almost always skipped — because it feels like admin, and because nobody wants to write test data before they've seen if the thing works at all.
The compounding bit: every bug that escapes gets added. The set grows into a regression suite that encodes everything the team has learned about how this feature fails.
2. Assert what's checkable
Far more is checkable than people assume, and these run in milliseconds for free:
- Does it parse?
- Are all required fields present?
- Is every cited ID one that actually exists in the retrieved context?
- Is it under the length cap?
- Does it avoid the six phrases legal told you never to say?
Deterministic, cheap, and they catch a real share of failures before anything clever runs.
3. Judge what isn't
For "is this summary any good?" — use a model. With a rubric. Which is where it gets interesting.