Almost every AI demo works. That is the trap. A copilot that answers ten hand-picked questions in a meeting tells you nothing about how it behaves on the ten thousand real ones it will face after launch. The gap between a demo that delights and a system that holds up on a random Tuesday is the single biggest reason AI projects disappoint, and closing it is mostly a question of measurement.
So before we choose a model, write a prompt, or design a retrieval pipeline, we build the thing that tells us whether any of those choices actually helped: an evaluation harness. We call this working eval-first, and it is the closest thing we have to a guarantee that an AI system will keep working once it leaves the room.
What eval-first actually means
Most teams build AI the way you would sketch a drawing: try something, look at it, adjust, look again. That works for the first version and fails quietly after that, because a change that fixes one case often breaks another you are not looking at. Without a way to see the whole picture at once, you are tuning by vibes.
Eval-first inverts the order. You start by writing down what a good answer looks like for a representative set of real inputs, and you build a way to score the system against that set automatically. Only then do you start changing things. Every prompt tweak, model swap, or retrieval change is judged by whether the number goes up or down, not by whether the latest example felt better.
Start with the question, not the model
The instinct on a new AI project is to pick the best model and start prompting. We start somewhere less exciting: collecting fifty to a hundred real examples of what the system will be asked to do, paired with what a good response would be. This set is the spine of the whole project. It forces the hard conversations early, what does correct even mean here, who decides, and how wrong is too wrong, while they are still cheap to have.
- For a support copilot: real tickets paired with the answer a senior agent would give.
- For a document extractor: messy real documents paired with the fields that should come out.
- For a classifier: genuine edge cases, not just the easy middle of the distribution.
- For anything generative: a rubric, since there is rarely one right answer, only better and worse ones.
What goes in the harness
A useful harness is less about fancy tooling and more about discipline. At minimum it runs the system over the whole example set, scores each output, and reports a single comparable number plus the specific cases that regressed. Scoring can be exact-match where there is a right answer, a model grading against a rubric where there is not, or a human spot-check on the cases the automated score is least sure about.
- A fixed, version-controlled set of inputs and expected outputs or rubrics.
- An automated scorer that produces one headline number you can track over time.
- A regression view that shows exactly which cases got worse after a change.
- A cheap way to add new failure cases the moment a real one shows up in production.
Without measurement you are not engineering, you are decorating. The harness is what turns guesswork back into engineering.
The payoff: changing things without fear
The first time the harness earns its keep is the day a better model is released. Instead of an anxious week of manual checking, you point the harness at the new model and read the number in an hour. It either helped or it did not, and you can prove which. The same is true for a prompt rewrite, a new retrieval strategy, or a cost-saving switch to a smaller model. Decisions that used to be arguments become measurements.
The second payoff is slower and more valuable. Every time a real failure slips through, it goes straight into the example set, so the system can never regress on that case again without you knowing. Over months the harness becomes a precise map of everywhere your system has ever been wrong, and a wall that stops it being wrong there twice.
How to start tomorrow
You do not need a platform or a budget to begin. Open a spreadsheet, write down twenty real inputs and what a good output would be, and run your current system against them by hand once. That single afternoon will tell you more about your AI system than a month of demos, and it gives you the seed of a harness you can automate later.
This is the first thing we set up on every engagement, before anything more interesting, because it is the only way we know how to ship AI that survives contact with real users. If you have a copilot or AI feature that shines in demos but wobbles in production, the fix usually starts here, and we are glad to help you build it.