evaluation-driven development

When you cannot eyeball whether a change helped, you measure. Evaluation-driven development means building your LLM feature around a growing suite of test cases — example inputs paired with a way to score the output — so every prompt tweak, model swap, or pipeline change is judged by numbers rather than vibes. It is the LLM analogue of test-driven development, adapted to outputs that have no single right answer.

You assemble a dataset of representative and tricky inputs, then define how to grade responses: exact checks for structured fields, reference-based metrics, rules that flag forbidden content, or an LLM-as-judge that scores answers against a rubric. Real user interactions and past failures feed back into this set over time. Before any change ships, you run the whole suite and compare scores; in production, you sample live traffic and grade it continuously to catch regressions the offline set missed.

Without evals, LLM development degenerates into changing a prompt, trying three examples, and shipping on a hunch — which is how quality silently rots. The discipline is not free: good eval sets take effort to build and graders are themselves imperfect, especially LLM judges that can be biased or gamed. But a team that can measure its quality can improve it deliberately, while one that cannot is guessing.