Every fix breaks something else
When every fix breaks something else, the problem is no longer in any one line of code. It is in how the pieces are connected. A coding agent builds the quickest thing that satisfies the request in front of it, so the same logic gets copied into several places, one function ends up doing five jobs, and screens reach into the database directly. Fix the copy you can see and the other copies stay wrong. Change the function for one caller and the other four shift.
This is a normal stage. Products built with any tool reach it when they grow past what one person can hold in their head; agents just get there faster. The way out has two parts: find out what the app actually is now, and put checks in place so a change to one part cannot quietly break another.
Below: how to tell whether you are there, what you can do this week, and what a proper fix involves.
In founders’ words
“I've tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each 'fix' resurrecting a previous 'break”
“At first, we wasted months. I tried to build too many things at once.”
“I've built a working prototype of a web app using AI, but I don't have enough experience in web development, programming, or cybersecurity to confidently turn it into a secure, production-ready product.”
How to tell a structure problem from a bad prompt
A bad prompt produces one wrong change, and a clearer prompt fixes it. A structure problem produces a pattern. Count how many of these you recognise:
- The same bug comes back after it was fixed, sometimes weeks later.
- A fix on one screen changes a number or a layout on another.
- The agent's summary of what it changed lists files you did not expect.
- Two parts of the app disagree about the same thing: the cart total and the invoice, or the count on the dashboard and the count in the list.
- The agent says "fixed" and its tests pass, but the thing is still broken when you click it.
- You have stopped asking for features because you are afraid of what the next one will break.
Two or more means structure. A better prompt will not get you out; the next section says what is going on underneath.
What is going on underneath, in plain words
- Copies. The rule for a discount, a date, or who can see what exists in three places because the agent wrote it fresh each time it was needed. A fix lands in one copy.
- No single owner. There is no one place that decides what an order is or what "paid" means. Each screen decides for itself, and they drift.
- Screens that talk to the database directly. A column rename or a new security policy then breaks every screen that read the column, not one layer that could be fixed once.
- Shared state. One piece of data that several screens read and write, so a change for one of them surprises the rest.
- No tests. Nothing runs the old flows after an edit, so the first test of each change is you, or a customer.
None of these look wrong in a single file. They only show up when you read the whole thing, which is why the agent that wrote it does not see them either.
Three habits that stop the cycle this week
You can start these today, with the tool you already use.
- Stop fixing in place. Every time the app works end to end, save that state (a commit, or a named version in your tool). After two failed attempts at a fix, go back to the last working state and describe the change smaller. The third attempt is where the damage is done.
- Write down what "right" is before the fix. One or two lines: "When a store's order is over its limit, it waits for approval. Under the limit, it dispatches." Ask the agent to find every place that rule lives before it changes any of them, and to write a test for the rule that fails first.
- One change per commit, with the agent listing the files it touched. Then click through the flows that make you money. If the list includes a file you did not expect, ask why before you keep it.
What a real fix looks like
A real fix starts with reading the whole codebase, not the part that broke. Out of that comes a map: what is finished, what is only partly connected, what is only a screen with nothing behind it, and where the copies live. Then the copies are pulled into one place each, the screens stop reaching into the database directly, and a test goes on every flow that touches money or customer data. The agent gets a rules file so it builds on the new structure instead of around it.
It is usually not a rewrite. A rewrite with the same unclear spec grows the same tangles, only faster. Untangling keeps what works and changes how it is connected.
This does not make bugs impossible. Nobody can promise that. It means a bug shows up once, in a test, and a fix stays fixed because the test keeps running.
When you may not need help yet
If nobody pays for the app and you can afford to lose a week to it, the three habits above will get you a long way. Many founders never need more than that.
If money or other people's data runs through it and the same break has come back three times, the problem is past what prompts can reach. That is when a read of the whole thing by someone who has run software pays for itself. We do that read, and it starts with a free call where we will say if you do not need it.
| What happens | Bad prompt | Structure problem |
|---|---|---|
| After a clearer prompt | The fix holds | The fix holds here and something else moves |
| The same bug | Fixed once, stays fixed | Comes back in another screen or after another feature |
| Files the agent touched | The ones you named | Several you did not expect, every time |
| Two screens showing the same number | They agree | They disagree, and fixing one changes the other |
| What gets you out | A better prompt | A map of the code, one owner per rule, tests on the flows that matter |
Questions
Should I just rebuild from scratch?
Usually not. A rebuild with the same unclear spec and no tests grows the same tangles, and you lose the parts that work. Rebuild one area at a time, behind tests, and only the parts the map says are not worth keeping.
Would switching from Lovable or Bolt to Cursor or Claude Code fix it?
Not by itself. The structure moves with the code. A coding agent gives you more control over each change, and that control is what you need, but only if you use it to add tests and a staging copy rather than to keep fixing in place faster.
Is this because the AI is bad at coding?
No. It is because each request is answered on its own, with no one holding the whole picture. A human team without a lead and without tests ends up in the same place, over a longer time.
How long does untangling take?
Nobody can say without reading the code, because it depends on how many copies of the same logic exist and how much of the app is only a screen. Be careful of anyone who quotes a time before they have read it.
Can I ask the agent to untangle its own code?
Ask it to map first, not change: list every place a rule lives, every screen that reads a table, and anything that is only a screen. Then fix one area at a time, with a test written before the change. Let it change everything at once and you get a new tangle.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.