The Art of Validation

← back to the series map

Here's the most expensive lesson I've learned building with agents:

The scar

Last week we finished a system that watches my inbox and files real sales conversations into our CRM. By the time we called it done it had 11,207 passing tests and had survived eight independent adversarial reviews. Everything green, eight times over.

Then we ran it against my actual inbox for the first time. It wanted to file a vendor's support ticket as a sales lead.

Nothing in the green was lying. The tests proved the machinery did exactly what we'd imagined. But every test ran against examples we invented ourselves — so what we'd really proven was that the system agreed with our imagination. Nobody had asked what it would decide about reality. And the same month, a different lesson from the other direction: three releases went out green on every automated check, and the first teammate who actually walked one found six problems every green had missed. His environment wasn't our checks' environment. Real use is a different test than any test.

The lesson

Validation is not a volume of checks. It's an aim.

Before you build — and again before you accept "done" — answer two questions: what actually needs to be true here, and for whom? Not "do the tests pass" but: who consumes this work — which person, which screen, which downstream system — and what does each of them need to be true? That's the whole picture the checks exist to serve. Then give the agent a way to verify that, because it will not aim itself. An agent left to define its own finish line will run to it and declare victory, honestly and uselessly.

How to run it tomorrow

1. Make it name the consumers. Before accepting done: "List everyone and everything that consumes this work, and what each needs to be true." If the list surprises you, the checks were aimed wrong.
2. Ask what would make the green a lie. "All your checks pass. What could still be wrong that none of them would catch?" The honest answer is where validation actually starts.
3. Feed it reality, not its own fixtures. Run the real path on real data. Have it list every disagreement between what it did and what should have happened — the list, not a score. You judge the list.
4. Walk it as the user. Real environment, cold, before "done." Checks catch lies in the code; the walk catches truths that read wrong.

The agent brings endless diligence. You bring the aim. That division of labor is the art.