Write the eval before the prompt, you animal
Prompt engineering without an eval set is interior decorating in the dark. Twenty labeled examples beat two hundred vibes.
Here is a ritual I have now watched at four different companies. An engineer changes a prompt. They run it on the one example that was failing. It passes. They ship. Two days later a different example breaks, someone changes the prompt again, and the first example quietly regresses. Repeat until everyone agrees LLMs are unreliable.
The model is not unreliable. The process is. You are doing test-driven development with no tests and the commit message "vibes".
twenty examples is a superpower
An eval set does not need to be a platform, a vendor, or a quarter-long initiative. It needs to be twenty real inputs with known-good outputs in a JSON file. Grade with exact match where you can, a checklist rubric where you can't, and a judge model only where a human would also need judgment. Run it on every prompt change. That's it. That's the whole discipline.
The magic is not statistical significance, it is regression detection. With twenty cases you cannot prove your prompt is good, but you can prove change 41 broke cases 3, 9 and 17, which is the thing nobody notices when testing on one example at a time.
make failing cheap
The loop only sticks if it runs in seconds from the terminal. Mine is a script that prints a table: case, expected, got, pass. Red rows get investigated before anything ships. When a new failure shows up in production, it becomes case 21. The eval set is a ratchet: it only tightens.
where the twenty cases come from
Not from your imagination, which produces the inputs you already handle. Pull them from logs: the ticket that escalated, the query someone screenshotted into Slack with "lol", the input with the emoji and the trailing whitespace and the entire email thread pasted in. Real inputs are weirder than invented ones in exactly the dimensions that break prompts. My distribution rule for a starter set: ten ordinary cases that must never break, five known hard cases, five cursed artifacts from production that nobody can explain. The cursed five do most of the work.
Prompts are code that a probabilistic interpreter runs. You would not refactor code without tests. Stop refactoring prompts without evals, and yes, the eval comes first, because otherwise you are writing tests to bless whatever the prompt already does.