The first two days produce something that genuinely works. The second two weeks produce arguments with the software.
Almost everyone building with AI meets this curve. The early progress is not an illusion — the thing really does work, and it really was built in an afternoon. Then the rate of progress falls away, and it falls away faster than anyone expects.
It is tempting to read this as a verdict on the tools, or on yourself. It is usually neither. It is a predictable consequence of what determines the cost of a change.
The beginning is fast for a reason that expires
On day one there is nothing to preserve.
No existing behaviour can be broken, because there is no existing behaviour. Nothing has to be integrated, because there is nothing to integrate with. No earlier decision can be contradicted, because none have been made. Every request is a fresh start, and a fresh start is the situation AI handles best: a self-contained description with no obligations attached.
That is a real advantage and worth using. But notice what it depends on — an empty context. Each thing you build removes a little of that emptiness, and none of it comes back.
The cost of a change is set by what surrounds it
A change is rarely difficult because of what it does. It is difficult because of what it must not disturb.
Adding an availability calendar to an empty project is a description and a result. Adding one to a booking tool that already has clients, appointments, cancellations, reminder emails and a month view is a different task — not a longer one, a different one. The new behaviour has to be correct, and it also has to leave five existing behaviours exactly as they were, several of which nobody ever wrote down.
The work does not scale with the size of the change. It scales with the size of everything the change can reach.
Four things that grow while you are not watching
Interactions, not features. Ten features are not ten things. They are ten things plus the ways they affect one another, and the second number grows much faster than the first. Cancellations interact with reminders, reminders with the calendar, the calendar with availability rules. Nobody added an interaction deliberately; they arrived as a consequence of adding features.
Decisions that quietly became architecture. Early on something was settled without much thought — an appointment belongs to exactly one client, say. It was reasonable and probably right. Twenty features later it is no longer a decision but a foundation, and a request for group bookings is not a feature request but a demolition.
The verification surface. After a change you check the change, and you check what it might have touched. The first stays roughly constant. The second grows with the software. This is the part people feel most directly: the same size of change takes visibly longer to be confident about than it did a fortnight ago.
What the assistant can actually see. Early on it can hold essentially your whole project in view. Later it cannot, and is working from a portion — which means the things it might break are increasingly things it cannot see. It will answer with the same confidence throughout, because reduced visibility does not feel like anything from the inside.
Why it arrives as a cliff rather than a slope
All four grow steadily, so it is fair to ask why the experience is not a gentle tailing-off.
The reason is that you do not perceive cost directly. You perceive whether the work is going well, and it goes well right up until a change breaks something else. That is the first moment the accumulated cost becomes visible, and by then it has been accumulating for weeks.
After that the character of the work changes. Sessions that used to add things now fix things. A correction causes a second problem. Part of the afternoon goes on re-checking behaviour that was already working. The project is not broken and you are not doing anything wrong — the ratio of new work to protective work has simply inverted, and nothing announced it.
This is not the same as drift
The two are easy to confuse, because they feel similar from the inside and often arrive together.
Drift is a loss of knowledge: unverified change accumulates until you can no longer say what the software does. The cure is to regain confidence — verify, re-establish the behaviour, get back to solid ground.
Stalling is structural. It happens to projects that have not drifted at all. You can know precisely what your software does, have checked every increment, and still find that each new feature costs several times what the equivalent cost a month ago — because there is now more to preserve, and preserving it is genuine work.
The practical difference is what to do about it. Drift is repaired by verification. Stalling is not, because nothing is unverified. It is addressed by reducing what each change has to reach.
What actually helps
Very little of this is avoidable, and pretending otherwise is how people end up over-engineering an empty project against imagined future problems. Some of it is manageable.
Write down what must keep working, as you go. The expensive part of a late change is discovering by accident which behaviours it affected. A short record of accepted behaviour turns that discovery into a lookup, and its value grows precisely as the project gets harder — the stable baseline record exists for keeping it.
Bound each change explicitly. The reach of a change is what drives the cost, so state what it may touch. This does not shrink the software; it shrinks the part of it any one request can disturb.
Treat the early cheap decisions as decisions. The ones that later become foundations are almost always the ones nobody noticed making. Two minutes spent on "can an appointment belong to more than one client?" while the answer is still free is worth a great deal afterwards, and finding those questions is a skill in itself: the decisions to make before AI makes them for you.
Expect the ratio to change, and work with it rather than against it. A project six weeks old is not failing because it moves more slowly than in week one. Comparing the two is the actual error. The useful comparison is against a project of the same size and age built any other way, and by that measure the position is usually far better than it feels.
The slowdown is not evidence that something went wrong. It is what building on top of things has always cost, arriving all at once because the early part was so unusually cheap.