AI writes the code. Who writes the architecture?

The amount of code a team can produce per week has multiplied with AI assistants. The amount of code a team can understand per week has not. The technical debt of the next few years is being created in exactly that gap.

The problem is not the AI. It is the missing brake.

An assistant told to “build me this” builds it. It does not ask whether this is the third repository pattern in the same service, whether the new dependency is necessary, or whether the function it is writing already exists. That is not a criticism of the tools. It is a description of their job. The brake has to come from outside.

Three rules we hold to

1. Architecture first, then prompt. Before a feature goes to an assistant, it is settled which module it belongs in, which interface it uses, and what it must not touch. Those guardrails live in the repository, not in someone’s head.

2. Every change is read by a human — all of it. Not skimmed. A review that only checks the diff statistics is not a review. If a diff is too large to read, the prompt was too large.

3. Deleting counts as progress. We do not measure how much code appears, but how much complexity is left per problem solved. An assistant is excellent at finding duplicates and merging them — when you ask it to.

What this changes

The developer’s role shifts from writing to deciding. That is harder, not easier: you have to know what a system should look like before you can describe it. Anyone who can do that gets a lever from AI unlike anything before it. Anyone who cannot gets a great deal of code very quickly.

Human intelligence steering the artificial kind. Not as a slogan, but as a division of labour.

An example from an ordinary week

A client needed an import for a new data format. The first AI proposal: a new parser, a new data model, 600 lines. After ten minutes of architecture conversation: an 80-line adapter feeding the existing model. Both would have worked. Only one of them will still be understood by somebody in a year.