AI is a very good drafter and a poor architect, and the difference matters more every month. A drafter turns a clear ask into working code. An architect holds the whole system in mind, remembers why the last three decisions were made, and refuses the fourth when it does not fit. The tool does the first part better than most of us. It cannot do the second, because it has no memory between sessions. Every session starts with whatever is in the repo and the prompt.
Fast food
The analogy is fast food. It is not bad. It is quick, it is consistent, and on a busy day it is the right call. A steady diet of it is the problem.
A steady diet of AI drafts with no architecture looks like this. Each session solves the task in front of it. Each solution is locally sensible and globally unaware. Six months later there are three ways of talking to the same database, two authentication paths, and a scheduled job that nobody remembers asking for. Every piece was drafted well. Nothing was designed.
I have taken over systems like this twice, both built on a no-code platform (how that goes). The work was not rebuilding the features. It was sorting each mechanism into “a product decision” or “a workaround for something the platform could not do”. One of the workarounds, carried over as-is, would have been a way to impersonate any user. Nobody had decided that. It had accumulated.
The continuity plan that is not one
The version of this that should worry a leader is the outage. Something breaks at seven in the evening. The person who built it is away. Someone opens an AI tool and asks it how the pieces fit together.
It does not know. It never did. It knew for the length of one conversation and then it forgot. If the business continuity plan relies on the model remembering the bespoke patchwork of APIs it helped build, the continuity plan is wishful thinking.
Where the reasoning should live
The fix is not less AI. It is giving the tool something to read.
- A standards file the tool loads every session. How this codebase does things. Naming, structure, where rules live, what not to duplicate. The draft gets better because the drafter has a brief.
- A decisions log. One short note per decision: what was chosen, what was rejected, why. Dated. This is the architect’s memory, written down so the next session and the next person start where the last one finished.
- A vault of what the team has learned. Beyond one repo: the gotchas, the patterns, the things that worked and the things proven wrong. Written once, applied automatically at the start of every session, kept true by the people who wrote them. My own is the learning loop, with a build guide, and the notes on this site are distilled from it.
- An owner for the shape. A person whose job includes saying no to the fourth way of doing the same thing. Not a gate on every change. A reader of the whole.
Done looks like a new person, or a new session, opening the repo and knowing why, not just what. Then the drafter can draft as fast as it likes.