Most prompt work starts the wrong way round. Someone writes a prompt, looks at three outputs, likes two of them and ships it. A week later a small wording change breaks a case nobody remembered.
Test-driven development has an answer to this, and it carries over almost unchanged. Before you write the prompt, write down what a good answer looks like.
Red, green, refactor — for prompts
- Red. Collect a handful of real inputs. For each one, write the checks a good answer has to pass. Some are hard rules (valid JSON, no invented sources), some are graded by a second model against a short rubric.
- Green. Write the simplest prompt that passes them. Not the most elegant one.
- Refactor. Now improve the wording, shorten the context, swap the model. The evals tell you instantly whether you broke something.
What changes
The eval set becomes the specification. Discussions move from "I think this answer is better" to "this case fails, here is why". New bugs turn into new cases, so the same mistake cannot come back quietly.
It is slower on day one. From day two on, it is the only way I know to change a prompt without fear.