Main idea

Writing the test first and the code second reverses the usual order, but the point is not the order. The test describes the what — here is the expected behaviour, here is what must stay true. The code describes the how. The first is therefore a piece of the specification, written in a language the machine can evaluate.

What this changes shows over time. The code will be refactored, it will meet new data, other features will grow up around it. The expected behaviour, though, is pinned down somewhere other than in the memory of whoever implemented it: if it is broken, the test breaks, ideally on the developer's machine or in QA rather than in production.

TDD does not eliminate defects, does not replace product thinking, and does not turn a bad specification into a good product. It does one thing, and an uncommon one: it makes part of the quality verifiable before the code exists.

Layer added by "Ontology-Driven Design: what if the ontology became the safety net for AI-generated code?" (2026-10-29). The same logic of doing things first can extend to the part of the expected behaviour that no test formalises: the domain model. Before an agent like Claude Code writes the code for a feature, the request is held up against the domain ontology — concepts, rules, states — and contradictions are settled before they are encoded. The order is the same as in TDD; the guarantee is not, since the verdict comes from an LLM's analysis and not from a deterministic assertion.

Why it matters

It takes the discipline out of the realm of technical hygiene. A test written first is a specification artefact, and therefore a place where product and development can agree on a behaviour — which a prose document cannot offer, since it cannot be evaluated.

It also shifts what tests are worth: written after, they record what the code does; written before, they constrain what it will have to do.

Nuances and limits

The part that can be formalised is narrow. A test says a behaviour is met, never that it was the right behaviour to aim for — the share of quality that comes down to product judgement remains untouched.

And the discipline assumes you can state the expected behaviour. Faced with an overly vague specification, writing the test first clarifies nothing: it freezes the ambiguity instead of resolving it.

Open questions

• What share of a check against the domain model can become reliable enough to play the role of a test, without having its deterministic guarantee?