Write the evals before you build the AI feature

An AI feature always returns something, so it never looks broken. A small set of real examples, checked by hand first, is how you find out whether it actually works.

Normal software fails loudly. A button does nothing, a page throws an error, someone reports a bug. AI features fail quietly. The summary reads well and leaves out the one number that mattered. The support bot answers with confidence and gets the refund policy wrong. Nobody reports it. People just stop using the feature.

So we write evals before we write the prompt. An eval is a test for output quality: a set of real inputs, what a good answer looks like for each one, and a way to check. You do not need a platform on day one. You need a spreadsheet and an afternoon.

Start with fifty real examples

Take inputs from the real world: actual support emails, actual documents, actual search queries. If the product does not exist yet, write them with the founder and the people who will use it. Fifty is enough to start. Put the awkward cases in on purpose: the message that is half English and half Arabic, the scanned PDF, the question the feature should refuse to answer.

Read the failures before you pick a metric

Run the first version and read every output yourself. Write one line for each failure saying what went wrong. After a few dozen, patterns appear. Maybe it ignores dates. Maybe it invents a policy when the document does not cover the question. Those patterns become your metrics.

Teams that start from a generic score, like helpfulness out of ten, often end up with a number that goes up while users stay unhappy. The score measures what was easy to define, not what was going wrong.

If you cannot describe what a wrong answer looks like, you are not ready to automate the check.

Then automate, a little at a time

• Use plain code wherever it works: is the JSON valid, is the date in the right format, does the cited source exist.
• Use a model as the judge only for what code cannot check, and compare its grades with yours on a sample before you trust it.
• Run the whole set on every prompt or model change. A change that fixes one case and breaks three does not ship.
• Keep adding cases from production. Every user complaint is a new test.

What this changes for a founder

Evals turn opinions into numbers. "Is the new model better?" becomes "it passes 46 of 50 instead of 41, and here are the four it still gets wrong." They also tell you when something simpler is enough. Sometimes the eval set shows that a rule or a plain search index does the job and the model call can go. That is a good result too.

None of this is expensive. It is a few days at the start of a feature, and it saves the weeks you would otherwise spend guessing.