Almost everyone building a site with AI goes through the same curve.
Day one: an afternoon produces a presentable page and it is exciting.
Day three: a few features added, a few rounds of colour changes. Fine, if a bit slower.
Week two: you move a button and the mobile menu breaks. You fix the menu and the footer shifts. You start being afraid to change anything.
The curve is common enough to be worth explaining.
The problem is not code quality
Clear one misconception first: individual pieces of AI-written code are usually fine. Names are sensible, comments are present. Read line by line there is little to criticise.
The problem is accumulation.
Each time you ask for something, AI adds to what exists. What it sees is “current code plus this request”, and what it produces is the shortest path to satisfying the request. That behaviour is correct on its own terms.
But a codebase’s structure survives only because somebody keeps subtracting: these two things are the same, merge them; this value is threaded everywhere, lift it out; this logic is in the wrong place, move it. None of that is driven by a request. You will not ask for it, so it will not happen.
Code therefore only grows. By the fifth revision one feature may have three implementations, and changing one leaves the other two still active — which is the mechanism behind “I changed this and that broke”.
Three characteristic forms of accumulation
Styles layered over styles. You want different spacing, so a new rule is added to override the old one. Change it again and another rule overrides that. Three rounds in, an element’s appearance is decided by five stacked rules resolved by precedence. Changing it now is fastest by adding a sixth, and the problem keeps growing.
We hit a version of this ourselves. In a configuration file, a general rule and a specific rule both matched the same files, and their values were concatenated rather than replaced. The first won and the second did nothing. The symptom was “the caching policy is set but has no effect” — no error, nothing to test against, visible only by reading response headers one at a time.
Duplicated decisions. “If this is the English page, show it this way” might be written once in the template, once in the styles and once in the script. If those three conditions are not identical, you get “fine mostly, wrong on one page”. These are hard to find because they do not reproduce reliably.
Forgotten connections. You add a template but do not add it to the list that invalidates the cache. So you edit the template and the live site does not change. Assuming it did not save, you edit it again. Still nothing.
We did exactly this last week: a new template file was missing from the watch list, deployment changed nothing visible, and it took a while to think of the cache. What these share is that they do not present as an error, they present as “I changed it and nothing happened”.
What experience contributes
Not “writing better code”. Subtracting periodically, and knowing what has to change in pairs.
Stop every few rounds and consolidate. No new features — merge duplicates, flatten rules that override each other. AI is perfectly capable of this, but you have to ask: “combine these style rules into one set without changing the result.” It will not suggest it.
Keep a list of things that change together. A new template means updating the cache list. A new page means updating the sitemap and the warm-up list. A new language means routing and hreflang. Write those relationships down, in comments or documentation. Memory does not hold them, particularly after two months away.
Make “nothing happened” detectable. After publishing, request the key pages automatically and check the content contains what you just changed. More reliable than opening them by hand — people miss things, and browsers show cached copies.
Keep structural decisions with a person. “Which layer does this belong in”, “are these two things the same concept” — AI’s answers here are often locally reasonable and globally awkward. What it lacks is not capability but a view of where this particular project is going.
When to rewrite instead of continuing
One signal is reliable: when you start avoiding changes because you are afraid of breaking something.
That feeling means the structure has become complex enough that you can no longer predict the consequences of a change. Adding to it only deepens the condition.
Rewriting is usually cheaper than continuing to patch at that point, and rewriting with AI is now inexpensive. Screenshot the existing pages, list the features, have AI rebuild from a clean structure — often half a day, against two days of archaeology in the old code.
The important part is carrying across what you learned: which features nobody uses (drop them), which parts always change (make them configurable), which decisions are scattered (gather them). None of that was knowable the first time, and it is where the value of a rewrite actually is.
What this means when hiring someone
If you are outsourcing, one question is worth asking: in three months, when I want another feature, does it get added or does this get rebuilt?
There is no correct answer, but how someone responds tells you a lot. Anyone who answers “depends what — this kind of change is easy, that kind touches the structure” has generally thought about it.
Our own practice is to leave the structural reasoning in the code: anywhere the handling is not obvious, a comment says why it is done that way and what the alternative was. Not for appearance — so that whoever returns in three months, possibly us, does not have to reconstruct the argument.
On our projects the source belongs to the client, comments and documentation included. You can hand it to someone else whenever you like, which is also why we are happy to explain the structure — you can take it with you regardless.