Answers
The app works. Nobody can change it any more.
Five things go wrong in an AI-built project, each with a symptom you can check today. Then the fix, written so you can do it with files and discipline.
Last updated
Nothing is wrong with the code you can see. What is missing is everything around it: what is finished, what was decided, what already exists, and what was actually tested.
Without those, each new feature is built by someone with no memory of the last one. It works, so it ships, and the pile grows. That is the mess, and it is not a coding problem.
Below: the five mechanisms with the symptom each one produces, then a prescription you can implement this week with nothing but a text file and a habit.
It is not just you, and it has a price list
"'Slopfix' software team charges $10,000 a week to delete AI-generated code bloat, ironically, the team uses AI agents to trim messy repositories by up to 65%"
Tom's Hardware, 2026. Cleaning up after AI code is now a paid trade with a rate card.
"Lovable, Bolt, and Replit will only get you 70% of the way to launching your app. As you keep developing features with more prompts, bugs can occur where the agent will be able to fix some, but others will be so complicated to solve that they'll be stuck in loops or break surrounding functionality."
Zapier, July 2026. Not a critic. A comparison written for people choosing one of them.
And the shape of it is measurable. GitClear's 2026 maintainability research reports duplicated code blocks at the highest level on record, up 81% against 2023, while refactoring, the act of tidying code up, fell from 13% of changed lines in 2023 to 3.8% so far in 2026.
More copying, almost no tidying. That is a description of your project, and of everybody else's.
The five things that went wrong
Each one has a symptom you can check in the next ten minutes. If three of them are true, the mess is real and it is still fixable.
- 1
Nothing records what is finished
Work exists as a conversation, so finished is whatever the last message said. Nobody can produce a list of what is actually done, because no such list was ever kept.
You would notice it as: You keep discovering features that are half built, and you find them by using the app, not by reading anything.
- 2
Decisions were never written down
You chose one approach over another, in a chat that has since closed. The reasoning went with it, so the next session has no way to know the choice was even made.
You would notice it as: The agent proposes the thing you rejected a month ago, and you cannot immediately remember why you rejected it.
- 3
The same thing gets built again
An agent that cannot see what already exists writes a new one. This is the mechanism behind the duplication numbers above, and it compounds, because the next agent now has two versions to copy from.
You would notice it as: Two date formatters. Three ways of calling the same API. A second login form nobody remembers asking for.
- 4
Fixed means claimed, not checked
A fix is reported in the same breath as it is made, by the same actor, with nothing in between. Some of those reports are wrong, and nothing catches the wrong ones.
You would notice it as: The same bug comes back after being fixed three times, and each fix touched something else on the way past.
- 5
Every session starts over
A session begins with an empty context window by design. Whatever was carried in your head from yesterday is not carried anywhere else, so each session works to a slightly different standard.
You would notice it as: The code from different weeks looks like it was written by different people, because in every way that matters it was.
The prescription, with any tool
Five habits, one per mechanism, in the order that pays. All of them work with a text file and a rule you keep. Nobody needs to buy anything to start.
1. Nothing gets built without a written unit of work
Before the agent writes a line, write down what is being built and how you will know it is finished. Two or three ticks, not an essay. "A wrong password shows an error and no session. A right one lands on the dashboard." This one habit fixes more than the other four together, because it makes finished mean something.
2. Every decision gets one line, in the repository
A file called DECISIONS.md. Date, what you chose, and one sentence about why you did not choose the other thing. Thirty seconds each. It exists so that in six weeks, when the agent proposes the option you already rejected, you have the reason instead of the feeling.
3. Search before you build
Before any new feature, ask the agent to list every place in the project that already does something similar. It is very good at this and almost never does it unasked. This is the habit that stops the duplication the research above measures.
4. Done means a command ran
Not "I fixed it". A command, its output, and whether it passed. If the agent cannot show you the command, the fix is a claim. Keep the outputs somewhere, even pasted into the task, because in a month the memory of it will not survive.
5. Write the state down before you stop
At the end of every session: what is finished, what is half done, what is next. Three lines in a file. The next session, yours or the agent's, starts by reading it.
That is the whole prescription. It is unglamorous, it is free, and if you do the five for a month the decay stops. Most pages about this problem stop at describing it. This part is the reason the page exists.
If you hit the wall in an app builder
Different situation, same cause. You built something real in Lovable, Bolt or Replit, it got you a long way, and now a bug will not die. You describe it, the agent says it is fixed, it is not fixed. Three rounds later you are further back than you started.
That is the 70% wall in the quote above, and it is not a failure of nerve on your part. The builder is holding your whole app in one conversation. Past a certain size, the conversation cannot hold it, so each fix is made by something that no longer sees the rest.
What to do about it, in order:
- Get the code out. All of these let you export or connect a repository. Do it today, even if you change nothing else. It is your work, and while it lives only inside a builder your options are whatever that builder offers.
- Write down what the app does, screen by screen. Every page, every button, what it is supposed to do. This is tedious and it is the highest-value thing you can do. Notably, the cleanup firm charging $10,000 a week starts by making exactly this inventory.
- Take the smallest broken thing and fix it once, properly. One bug, with a way to check that it is actually fixed. Not five at a time. The loop you are in is caused by fixing without checking.
- Then keep going with an agent that has the inventory. A coding agent in your own editor, reading a repository and a written description of the app, is a very different thing from a chat that has run out of room.
What that looks like as machinery
Mission HQ is the five habits, built so they happen without you remembering them at the end of a long day.
No task, no code
Work exists as tasks with their own acceptance criteria, written before the building starts. Finished has a definition, and the definition was agreed while it was still cheap to argue about.
Decisions are records, not chat history
A choice and its reasoning are stored against the part of the project they govern, and they come back when work touches that part. Nobody has to remember to look them up.
Done is refused when it is not proven
A task will not close on the agent's word alone. A test counts as passing when a runner on your own machine executed the command and posted back the real exit code. A pass the agent simply types stays visibly unverified.
The state is written as you go
Checkpoints on every prompt, a summary and warnings at the end, and the next session opens on that instead of a blank page.
An existing project can be mapped
If the mess already exists, the import path works through it: the agent lists the files, and the project is not counted as understood until every significant file belongs to a module that has documented knowledge behind it. That is the inventory from step two, done systematically.
$10,000 a week to delete it, or $12 a month to not make it
14 days, no credit card. Point it at the project you already have.
What it does to a mess that already exists
Straight answer, because this is the question anyone in the middle of it actually has. Nothing here rewrites your code. The duplication that is already in there stays in there until somebody removes it, and that somebody is you or an agent you point at it.
What the import does is map it: every significant file belongs to a named part of the project, and that part has written knowledge behind it. From that point the decay stops, because the next feature is built by something that can see what already exists. Cleaning up is then a series of ordinary tasks instead of an archaeology project.
Questions people ask about this
How do I fix an AI-built app that became a mess?
+
Why does AI-generated code become unmaintainable so fast?
+
What is the 70% wall in Lovable, Bolt and Replit?
+
Should I rewrite my AI-built project from scratch?
+
Can I do this without buying a tool?
+
Does Mission HQ clean up the mess that is already there?
+
Two things you can do now
Measure your own duplication, free
Ask your agent one question: list every place in this project that sends an email, or formats a date, or checks whether a user is logged in. Pick something that should exist once. If it comes back with three or four, you have just measured the mess, in five minutes, without installing anything.
Works even if you cannot read the code.
Or stop it growing
Start a 14-day trial, no credit card. Bring the project you already have and let the import map it, so the next feature is built by something that can see the rest.
Start free trial