← All writing

If you can't measure it, you shipped a demo

July 2026 · 5 min read · vallesAI

Every failed AI project we've been called in to look at shared one property: nobody could say, with a number, how well the system worked. There were impressions — the CEO's test went great, support tickets seemed down, the demo killed at the board meeting. But no number, no baseline, no way to know whether last month's prompt change made things better or quietly worse.

That's the actual difference between a demo and a system. A demo has to work once, in front of the right people. A system has to work on Tuesday's weird inputs, after the model provider's silent update, under next quarter's data drift — and someone has to be able to tell when it doesn't.

What a useful evaluation harness looks like

Not a research benchmark. A few hundred examples drawn from your real traffic, labeled with what the right answer actually is, and a script that runs the system against them and prints three numbers: quality (defined for your problem — extraction accuracy, resolution rate, citation correctness), cost per case, and latency. It runs in minutes, on demand, and in CI.

Two properties make it earn its keep:

• It's built first, not last. Building it forces the question most projects defer until it's expensive: what exactly does "correct" mean here? If stakeholders can't agree on labels for two hundred examples, the project isn't ready for engineering yet — better to learn that in week one.
• It grows from production. Every case a human reviewer corrects becomes a candidate for the set. The harness gets harder and more representative over time, which is what keeps quality a fact rather than a memory.

"Is it good enough to ship?" is a question with a number for an answer. If nobody can produce the number, the honest answer is no.

The objection, answered

The common pushback is that evals slow the project down. Our experience is the opposite. Without a harness, every prompt change triggers a round of manual spot-checking and a debate; with one, changes merge with a green check. The team without evals is slower within six weeks — they just spent the savings up front, where it was visible, and pay interest forever after, where it isn't.

We won't ship a system without an evaluation harness, and we put that in writing. Not because it's virtuous — because we've never once regretted building one, and we've watched many teams regret not having one.