Main idea

Someone who wrote their own code holds it through memory: they know what they decided, where they took a shortcut, which parts touch each other. When the code is produced by an assistant at a rate of dozens of commits a day, that memory does not exist. What remains is screens that work, a repository you have not read in full, and parts you could not explain out loud.

What does survive in that situation is the tests. A project built in a few days can hold several hundred of them; the assistant re-runs them very often, and most of the time nothing breaks. When something does break, the test does not only say there is a problem: it says which expected behavior is no longer respected, so it locates the fault, where a broken screen merely signals one.

The test here is therefore not a token of quality in the usual sense. It is the only instrument that lets you keep a grip on a system whose construction you do not remember.

Why it matters

It changes the argument you use to defend tests to someone who does not code. "Tests are good practice" weighs nothing against speed; "without them you have no way of knowing what your last change just broke in code you have not read" is understood immediately.

It also points to what should be demanded first of an assistant handed the production work: not coverage for its own sake, but the existence of a net that makes the system questionable after the fact.

Nuances and limits

The foothold is not a control. Tests only detect what they describe: they see neither the collapse at real data volume, nor security flaws, nor an architecture that is becoming impractical to evolve.

And the requirement is dosed. A very simple internal tool, low-risk and short-lived, does not call for a full test strategy — the question reverts to one of scale.

Open questions

• On code you did not write, how do you know whether the test suite covers the behaviors that matter rather than the ones that were easy to write?