There is a familiar shape to LLM project failure. A team picks a model, writes a prompt, plumbs the API into their product, and ships. Then a real user types something the demo never covered, and the system answers confidently and incorrectly. The team adds a system prompt, then a guardrail library, then a fine-tune, then a second model. Six months in there is no way to know if any of it is working.
The eval is the deliverable
We start every LLM engagement by writing the evaluation harness before we write the model code. Fifty rubrics, minimum. Each one is a (prompt, expected behavior, grader) tuple. The grader can be exact match, an LLM-as-judge, or a human checkbox — whichever fits.
- If you can't write the rubric, you don't know what shipping looks like.
- If the rubric is vague, the model will exploit the vagueness.
- If the rubric is wrong, you'll find out before a user does.
Who writes the rubrics
Not the engineers. The domain experts — the nurses, the support leads, the financial analysts. Their hands on the keyboard. Our job is to give them a comfortable way to write 250 of these without it feeling like data labeling.
“The eval harness changed how our clinicians think about AI. They trust this system because they wrote the questions it has to pass.”
What the eval gives you
Permission to change anything. The prompt, the model, the retrieval. As long as the eval stays green, the change is safe. As long as the eval has the right coverage, green means shipped.