Write the test before you write the AI feature
The difference between an AI demo and an AI product is not the model. It is whether anyone can tell when the answers get worse.
We turn down about half of the AI work that comes to us, and the reason is nearly always the same. There is a demo that impressed the board, but no agreed definition of a correct answer. So there is no way to know whether tomorrow's change made the system better or quietly worse.
A demo has no memory
Normal software has tests. When someone changes a line and breaks something, the build fails. AI systems usually ship without that safety net, because the output is a range of possible answers rather than one right value, and writing a test feels impossible. It is not impossible. It is just work that has to happen before the feature, rather than after the incident.
- A fixed set of realistic inputs, taken from your own business rather than a public benchmark.
- A way of grading answers, with its own known weaknesses written down — human, automatic, or model-graded with spot checks.
- A pass mark that blocks the release. If it does not block anything, it is a dashboard, not a test.
The cost argument
Teams skip this work to save time, then spend the two weeks they saved in incident reviews. The honest comparison is not test work against nothing. It is test work against the cost of finding out about a problem from customer complaints — including the part where nobody can work out which of the last forty changes caused it.
There is a cost angle too. Without tests, you cannot safely switch to a cheaper model, shorten a prompt, or cache more aggressively. Every saving becomes a gamble on quality you cannot measure. Clients with good test suites often cut their cost per request by two thirds within three months, because they can finally make those changes with evidence.
What we do on day one
- Collect 150 to 400 real inputs, together with the expert who will judge the answers.
- Ask that expert to grade a sample by hand, and write down where graders disagree. Those disagreements are your real specification.
- Automate the grading, accept a known error rate, and connect it to your build with a pass mark.
- Only then build the feature.
Which model you use is a setting you can change. The test is the real product decision.
Keep reading
Read the blogSlow onboarding is a warning sign, not a normal cost
Most teams accept that the first month of a project is wasted. Most of that month can be saved — and what is left tells you something important.
The hidden cost of running two processes
When an outside team brings its own way of working, someone has to translate between the two. It is never the outside team.