Why does my Lovable app break with every change?
You ask for one tweak and something breaks on a screen you never touched. That is not bad luck and it does not sort itself out. What happens under the bonnet, and how to stop it.
At the start it feels like you can do anything. You type what you want, it appears, and it works. Somewhere around the twentieth or thirtieth change that tips: you ask for a button on one screen and something breaks on a screen you have not opened that day. You ask for a fix, that works, and then the first thing is gone again.
That pattern is not called bad luck. It is the predictable result of three things missing from virtually every vibecode project.
1. The model does not see your project all at once
A language model has a limited window in which it can look at your code. While your app is small, everything fits and every answer is right. As your project grows it stops fitting, and the tool picks a selection of files that are probably relevant. Whatever falls outside that selection does not exist at that moment. A change that is logical within the five visible files can break the three invisible ones.
That is also why it gets worse as you go: the more you build, the smaller the share the model can take in at once.
2. The same logic sits in five places
Ask for a price calculation on the quote screen and it ends up there. Ask for one later on the overview screen and you get a second copy. Nobody removes the first, because nobody is looking. Only when you change the VAT rate do you find out there are three places and that you updated two.
- Search your project for an amount or a percentage that should only appear once.
- Find it more than once and you now know why the numbers sometimes disagree.
- This is also why small changes keep taking longer: every change is secretly three changes.
3. There is nothing to warn you
In a normal project, every change triggers a set of tests that checks whether the things that worked yesterday still work today. That is not a luxury for big teams; it is exactly the safety net you are missing. Without those tests your only check is clicking through by hand, and nobody clicks through every screen after every prompt.
You do not have to test everything. Ten tests in the places where money, data or permissions move catch ninety percent of what breaks.
What you can do today
Put your project under version control, if it is not already. Most tools can export or sync to GitHub. From that moment on you can see what changed on a prompt, instead of only that something changed. That alone shifts the conversation with yourself from “why is it broken” to “this line is broken”.
After that, work in smaller prompts and state per prompt which files it may touch. It sounds laborious and it is exactly what brings the number of accidents down: you shrink the area within which the model gets to improvise.
And when that is not enough
There comes a point where the cleaning up is the work: merging the duplicated logic, moving the calculations into one place, and putting tests where it hurts. That is the job I often take over, and it is usually less work than people fear, because the hard question, what should it do, has already been answered by the prototype you built.