Industry settled this problem long ago, and not with instructions. It invented the keyed part: a component shaped so that it cannot be fitted the wrong way round. The plug that goes in one way only, the SIM card with a cut corner. The instruction becomes unnecessary, because the mistake has become impossible.
My work consists of putting keyed parts into software. A rule that matters is not a paragraph in a document: it is something that fails, loudly, the second it is crossed. Before release, before your customers, before the incident.
What this changes for you
- Your teams no longer have to remember everything in order to break nothing.
- What protects your customers no longer depends on the memory of the person who wrote it: it therefore does not leave with them.
- Your AI tools work inside a frame, rather than alongside it.
What this buys you: being able to keep changing your product without dreading what the change will break elsewhere.
It is also, to my mind, what decides whether AI-assisted development holds over time. A machine produces plausible code — and plausible is exactly the dangerous property: it passes review, and it gives way under real conditions. This is not a model problem. It is a boundary problem.
Three examples, taken from my own systems
The three examples that follow are taken from my systems rather than my clients’: a practice is proven at my own expense before being proposed elsewhere.
An app that must work without a network, held by two locks
Latitudes is one of my laboratories: no version of it has been published, and nobody other than me uses it. Its main rule: what the user does there every day should never depend on a connection. In the mobile app, one folder alone therefore has the right to speak to the server, and exactly two files have the right to reach it. That list is nominative, and it is held by two independent checks: the tool that reads the code as it is written, and a test demanding exact equality, not one file more nor one fewer.
Why two rather than one? Because a single lock comes off in one discreet edit. Two locks come off in plain sight.
Operating rules born of real outages, rather than of a guide to good practice
The servers that carry my projects are governed by a written list of rules that must never be breached — invariants. They do not come from a guide to good practice: they are written from outages I have had, and phrased so that the same outage can no longer replay unseen.
One example, readable without being a developer. When a piece of software stops on an error, it reports the file and the line at fault: that is what allows you to go and fix the right place. I checked that report on one of my projects, at the 97 places where its code can raise an error. The compiled file pointed to the right line only 4 times. Everywhere else it sent you to a wrong line, and nothing anywhere signalled the discrepancy. After correcting the way the code is compiled: 92 times out of 97. This is the kind of defect that breaks nothing and never announces itself — you fix the wrong place believing you are in the right one.
A second example, less flattering, and that is precisely why I publish it. One of the components I publish for installing my own servers stayed accessible to anyone for nine days, from 8 to 17 August 2026, while the repository — the place where the code is kept and reviewed — was private. No code review could have seen it: that setting does not live in the code. The invariant that came out of it fits in one sentence: what does not live in the repository is probed, not reviewed. An automatic check now handles that on every publication, in each of the repositories concerned, and it also fails when it is inconclusive, rather than advising you to try again.
AI agents contributing to the code under written constraint
Plume is my second laboratory: a long-form writing environment with AI assistance, with no users other than me. It is where I work on the question my clients face — letting AI agents contribute to a codebase without its coherence degrading, month after month.
Agents there receive written rules rather than advice: what the rule forbids, the incident that gave rise to it, and the command that proves it was honoured. A 503-line checks file reads the code on every verification and refuses deviations. Five files produced automatically from the code — including the description of the server interface — are committed to the repository, then regenerated and compared on every verification: the slightest difference stops everything.
It is this practice, transposed to your repository and written from your own incidents, that I install on engagements.
What holds by review, I write down
Not every rule can be made mechanical. On Latitudes, the decision to keep AI out of the engine that composes the day rests on the structure of the code and on review, not on an automated check. I put that in writing rather than let anyone believe otherwise.
An honest inventory is worth more than an approximate guarantee.