Eval-driven AI development

Every AI feature I've shipped in the last two years started with the same artifact: a spreadsheet of 100 test cases. Not a prompt. Not a model. A spreadsheet. This is eval-driven development, and it's the only way I've found to ship LLM features that don't embarrass you in production.

Here's the workflow. Before you write any model code, write the test cases. Take real inputs your users will give the model, write the ideal output, and rate each output on a 1-5 scale. Now you have a baseline. When you change the prompt, the model, or the retrieval pipeline, you re-run all 100 cases and see if your average score went up or down.

The trap most teams fall into is testing on the happy path. They try 5 examples, all work, and they ship. Then a user asks the model something slightly different and it hallucinates a citation. The eval harness catches this because you wrote test cases for the weird inputs too — the adversarial ones, the ambiguous ones, the ones in Arabic, the ones with no good answer.

Production AI needs more than evals, but evals are the foundation. You also need tracing (so every answer links to the source chunks), guardrails (so the model can't say something illegal), and cost monitoring (so a single user can't bankrupt you). But all of those are secondary to having a measurable definition of 'good output' in the first place.

If you take one thing from this essay: write the test cases first. Not after. Not during. First. The model is the easy part — knowing what 'good' means is the hard part, and evals force you to figure that out before you write a line of code.