The short version
Early work is additive and easy. Later work is a negotiation with everything already built — and that is a different task.
01
The arc is remarkably consistent
Talk to enough people who have tried to build something real with AI and the same story comes back with the nouns swapped. Hours one to three are genuinely thrilling: you describe a page and it appears, you ask for a change and it happens, and the gap between wanting something and having it collapses to about ninety seconds. Then somewhere around hour four something small breaks, you ask for a fix, the fix works, and now something adjacent is broken. You have entered a loop you will spend more time in than you spent building everything before it.
02
Why the pace cannot hold
The first three hours and the next forty are different tasks that look identical from outside. When a project is empty, everything you add is new — there is nothing to conflict with and no prior decision to contradict. That is the easiest possible situation for a system that generates plausible code. Once a dozen files reference each other, every change becomes a negotiation with everything already there. Adding one field to a form means touching the form, the thing that validates it, the thing that saves it, and the thing that displays it later. Miss one and you get a bug that surfaces somewhere unrelated.
03
You have been accumulating decisions you never made
Every time the AI wrote code it made choices: how to organise files, what to name things, how to store data, which library to pull in. Those decisions were made locally — each sensible on its own, with no awareness of the others, because the model was answering one question at a time. Two hundred locally-sensible decisions with nothing coordinating them do not add up to a system. They add up to a pile, and the pile is what you hit at hour four.
04
Nothing is checking anything
Professional projects carry automated tests whose only job is to confirm that other code still works. Your project almost certainly has none, so your only test is looking at the screen. That catches obvious visual breakage and misses everything else: the form that fails for names with apostrophes, the total that is wrong only in certain months, the upload that works for you and fails on a slower connection. Those bugs exist from the moment they are written — you just meet them later, often in front of a customer.
05
What actually helps
Three habits do most of the work. Keep a plain decisions file listing every choice that matters and paste it into new sessions. Ask for the plan before the code on anything non-trivial, so you see structural decisions before they are baked in. And ask what else depends on the thing about to change. None of these require learning to program, and together they prevent most of the damage.
Go deeper
This is one chapter of a much longer story
Build Your First Real App is the next step: a 120-page prompting course where you build a mini marketplace one checked feature at a time, plus the Northstar visual kit to build against.
See the course — $29.99FAQs
Quick answers
Is this a problem with the tool I picked?
Almost never. The arc reproduces across every major AI coding tool because the cause is how the models work, not which product wraps them. Switching tools usually reproduces the same wall about a week later.
Does this mean I should not use AI to build?
No. For prototypes, internal tools, landing pages and personal projects it is genuinely excellent. The trouble starts when a working demo is mistaken for a finished product.
Can a developer rescue a project that already hit this?
Usually yes, and it is much cheaper earlier than later. The good parts are typically kept while the structure underneath gets rebuilt.