What remains of a system when code becomes replaceable

Now that AI can generate software at scale, the essence of system architecture changes. Where the value of an application used to lie in the hand-written code, the centre of gravity now shifts to the description that code is built from.

The end of the architectural original sin

A wrong architecture decision used to persist for years. Rewriting cost more than the system was worth, which forced developers to build around the flaws. Decisions from the first year thus determined what was still possible in the years that followed.

With AI that changes fundamentally. A wrongly structured component can be rewritten while the system stays in use. The architecture is adjusted step by step instead of fixed once.

The real cost of a rewrite

Writing code costs a fraction of what it used to, but rewriting is still not free. The real costs rarely sit in the code itself, but in:

• Data migration: moving the existing data across.
• Integrations: reconnecting external systems.
• People: retraining those who work with it every day.

Because AI models grow more capable and cheaper every year, a later rewrite usually produces better code than the first. The hard condition is that the lessons from the old code have been carefully written down.

The description as an enforceable norm

When code becomes replaceable, it no longer determines the value of the system. What remains is the description: the structure, the naming, the design rules and the quality requirements.

The difference with traditional documentation lies in automated enforcement:

1. Instruction: AI reads the description as a direct build order.
2. Testing: automated tests and AI checks verify every change against these rules.
3. Correction: deviating code does not pass inspection and is automatically rewritten until it complies.

Whether a human or an AI wrote the code makes no difference: every change goes through exactly the same automated check.

In the starting point I use for new projects, it works like this. One document describes the structure of every component. One check decides when a change is done, and it runs for every change. Recurring components are derived from that description, the same way, independent of who made them.

A new meaning of ownership

As system owner you no longer have to be able to read the code, because it changes constantly. What you do have to do is understand the description and test it against practice. A mistake in the description is built by AI as reliably as a correct rule.

Contractual rights to code and data are merely the minimum. Whoever owns the description keeps control during a rewrite or a change of developer. The description is the first thing a next builder, human or AI, reads.

Five questions for your software builder

Ask a software supplier these five questions before you sign a contract:

1. Is there a binding document that lays down the structure and rules of the code?
2. Is every change automatically tested against those rules, even if AI wrote it?
3. Is the description written in the language of the work itself, understandable for the organisation?
4. Can a next builder continue straight away without a verbal handover?
5. Are the description, the code and the data contractually your full property?

Can you answer yes five times? Then a rewrite is a manageable step. Every system is renewed at some point. What remains of it at that moment, you decide today, in the document and in the contract.