Why Vibe-Coded Projects Stall at 80%

There's a pattern so consistent it's almost a law. The first session is euphoric — a working app appears out of a conversation. The second session is productive. Somewhere around the fifth, progress slows. By the tenth, every fix breaks something else, and the project quietly stops.

The app is 80% done. It has been 80% done for six weeks.

This is not a personal failing and it isn't a sign the tools are fake. Five distinct mechanisms produce this stall, they have different symptoms, and — this is the part that matters — they have different fixes. Applying the wrong one is why "I tried starting over and hit the same wall" is such a common follow-up.

Which one has you?

Find the symptom that sounds most like your last two sessions.

Most stalled projects have two or three of these at once. Work them in the order above — the later ones are much harder to fix while the earlier ones are still true.

Mechanism one: the context ceiling

An AI model can only reason about what's in front of it. Early on, your entire project fits — every file, every decision, the whole picture. The model's suggestions are excellent because it genuinely sees everything.

As the project grows, it stops fitting. The tool now has to choose which parts to look at, and it chooses imperfectly. It writes a function that duplicates one it can't see. It changes a component without knowing about the three places that depend on it.

You'll know it's this when the AI starts being confidently wrong about your own codebase — referencing a function you deleted, or "fixing" a bug by adding a second code path instead of correcting the first.

There's a rough threshold. While a project is a handful of files, everything fits and everything works. Somewhere past a couple of dozen files — earlier if they're long — the tool starts having to guess what's relevant, and the quality of its guessing becomes the quality of your results.

You didn't get worse at prompting. The project outgrew the window. The context problem covers the mechanics in depth.

Mechanism two: undecided architecture

Every prompt gets answered locally. Ask for user login, get user login. Ask for a settings page, get a settings page. Each answer is reasonable on its own.

But nobody ever decided how this application manages state, where business logic lives, or what the data model is. Those decisions got made implicitly, forty times, slightly differently each time.

You'll know it's this when a single conceptual change — "users should have a display name" — turns into edits in six files that each do the same job a different way.

The AI can't refactor this cleanly, and it's worth understanding why: there's no coherent pattern to refactor toward. It would have to invent the architecture that was never chosen, and it has no basis for picking one invention over another. That decision is yours, and it's the one piece of this that genuinely cannot be delegated.

Mechanism three: the untested foundation

Without tests, there is no way to know whether a change broke something except by clicking through the app.

For a while this is fine, because you can hold the whole app in your head. Past a certain size you can't, and you start shipping regressions you don't notice for days. Confidence drops. You start making smaller and smaller changes to avoid breaking things.

You'll know it's this when you catch yourself avoiding a change you know is right, because you can't predict what it would disturb.

The stall here is often just fear. The project isn't technically stuck; you've become unwilling to touch it. That's a rational response to having no feedback signal — and it's why adding a handful of tests to a stalled project so often unsticks it within a day.

Mechanism four: the last 20% is the hard 20%

The first 80% is the part the model has seen ten thousand times: a login form, a list view, a dashboard layout, a CRUD form. This is genuinely solved, which is why it appears so fast.

The remaining 20% is your specific business logic, your edge cases, your integration with the one vendor whose API is strange, your particular compliance requirement. The model has never seen this, because it's yours. It cannot pattern-match its way through, and neither can a prompt that says "finish it."

You'll know it's this when the thing you're stuck on is something you'd struggle to explain to a new employee in one sentence.

So the ratio inverts. Where you were getting a feature per prompt, you now get a partial fix per five prompts.

The reason it feels like you're doing something wrong is that early velocity set an expectation the hard part was never going to meet.

Nothing has broken. You've just crossed from the part of the problem that was already solved into the part that's actually yours.

Mechanism five: no rollback discipline

If the work isn't committed to version control, every AI change is irreversible. That single fact changes behavior enormously. You stop letting the agent try things. You review defensively. You keep broken code because you're not sure what removing it would break.

You'll know it's this when you find yourself writing deliberately timid prompts — asking for one small edit at a time, when what the project needs is a real restructure.

Builders who commit before every agent run move dramatically faster than those who don't. Not because the AI performs better, but because they're willing to let it attempt more. The cost of a bad attempt drops to one command, so ambitious attempts become worth making.

The rewrite trap

The most common instinct at this point is to start over. You now understand the problem far better than you did on day one, the codebase feels like a mess, and a clean slate is genuinely appealing.

It usually doesn't work, and the reason is specific: rewriting addresses mechanism two and nothing else. You'll get a cleaner architecture — real value — but you'll rebuild your way straight back to the same context ceiling, with the same absence of tests, and the same last 20% still waiting. Except now you've also spent three weeks reproducing behavior you already had.

Rewriting is the right call in one situation: the existing code is small enough that recreating it costs less than understanding it. If your project is genuinely 80% done, that isn't you.

The alternative that does work is a targeted refactor — keep the code, impose the architectural decision on the parts that matter, delete what you don't need, and leave the rest alone.

How to get moving again

Each of these is tagged with the mechanism it treats. Don't do all of them; do the ones matching your diagnosis.

Reduce the surface. (Fixes 1) Delete features you added but don't need. A smaller project fits back inside the context window. This is the highest-leverage move available and the one people resist most, because deleting working code feels like going backward. It isn't — it's buying back the model's attention.

Write the tests now, retroactively. (Fixes 3) Not comprehensive coverage — just the five paths that matter: signup, login, the core action, payment, and whatever loses data if it breaks. Ask the AI to write them, then read them yourself, because tests written by the model that wrote the bug can encode the bug.

Write down the architecture. (Fixes 2) A short document stating how state is managed, where data fetching happens, and what the data model is. Feed it to the agent at the start of every session — most tools have a designated file for exactly this. You're supplying the coherence that was never chosen.

Get it into git. (Fixes 5) Then commit before every agent run. This one habit is the difference between an agent you supervise nervously and one you let work.

Change what you ask for. (Fixes 4) "Finish the app" cannot be answered. "Add validation to the checkout form so it rejects expired cards, and show the error above the submit button" can be. In the last 20%, prompts have to get dramatically more specific, because the model can no longer infer what you mean from convention.

Give the agent a way to check its work. (Fixes 1, 3) Connect a browser tool so it can see the rendered page, or a database tool so it reads your real schema instead of guessing. An agent that can verify its own output catches its own mistakes before you're involved. See MCP explained.

Escalate the model. (Fixes 4) Routine work runs fine on a mid-tier model. Debugging a tangled interaction across a large codebase is a different task. If you've been on the same model for the whole project, part of the wall you hit may be a capability wall.

When to bring in help

Sometimes the honest answer is that the project needs someone who can read the whole thing, decide what the architecture should have been, and do a real refactor. That's usually a few days of work, and it unblocks months of stalling.

That's not a failure of vibe coding. It's the normal shape of software: getting to a prototype and hardening a system are different jobs, and they always have been. The only thing that changed is that the first job now takes a weekend instead of a quarter.

The second job still takes what it always took. Knowing which job you're currently doing is most of the skill.