Code has become cheap. With AI it appears faster than it can be read. What has become expensive is the opposite, namely clarity about what the code is supposed to prove. Build before the question stands and you get no answer, only an artefact that wants defending.
Three sentences before every build
Every trial here starts with three written sentences. What do we suspect? How would we notice that it is wrong? What may the trial cost? The second sentence is the important one, because a suspicion that cannot fail is not one.
The idea is borrowed from empirical research, where you record in advance what you expect and what would refute it. In software this feels unfamiliar, because a running artefact always looks a bit like success. That is precisely why the stopping criterion has to exist beforehand rather than afterwards.
An experiment is allowed to fail. A demo is not, which is why demos teach so little.
An example that did not work
Skimmer was meant to go through large piles of documents quickly and pull out what mattered. The written suspicion was that a cheap first pass would reduce the volume of material enough to make the expensive step afterwards noticeably cheaper. The trial did not confirm it. The pre-pass cost roughly what it saved, and in substance the tool landed between two stools: too close to ordinary search, too far from a retrieval step that knows the task.
We archived it and wrote down the reason. It still sits on the product shelf marked as discarded, because a shelf that only shows wins helps nobody. The trial was useful all the same: it cleared the suspicion away and closed off a branch we would otherwise have left open for months.
What the cost ceiling is for
The third sentence looks harmless but prevents the most common trajectory of all: a trial quietly turning into a project. We set the ceiling in days and in francs, and when it is used up we stop and write down where we got to. The dangerous state here is not clear failure but the almost-worked. It supplies enough hope to continue and too little evidence to justify it.
Build small, measure early
The second-cheapest iteration is the smallest one that can run. It answers the written question and nothing else. What it proves is kept. What it refutes is discarded, together with a note saying why. Discarding becomes a result instead of a defeat.
The side effect is the most valuable part. A shelf of answered questions is worth more than one of half-finished products, because you can build on it.