The AI builder rewrote or deleted code that was already working
Filed under AI builder problems (Lovable, Bolt, Replit)
The builder regenerated whole files from its incomplete picture of your app instead of editing the small part you asked about — and no copy of the good version was saved anywhere you control.
Fastest route
Give your AI this prompt
Copy it, replace the bracketed part with your error, and send it.
Preview the prompt
While fixing [the change you asked for], you rewrote or removed code that was already working — specifically: [name the lost features or files]. Do NOT try to rebuild them from memory yet. First, answer these questions: 1) What did the previous version of [the damaged file] contain — print its full previous contents if you still have them, 2) which files did your last change touch besides the one I asked about, 3) what version history, checkpoint, or git commit in this project represents the state before your change? I will restore from version history or git first and confirm the old features work. After that, I will re-ask for the original change as a single-file edit with an explicit list of what must not be modified.
Fix it yourself
Follow the repair
- Stop, and do not ask it to fix forward yet. Every additional generation is another chance to overwrite something else. Close the loop now: no more "just try putting it back" prompts until you have secured the last version that worked. The recovery options below get weaker with every edit that lands on top of the damage, so this step genuinely cannot wait.
- Restore from the builder's version history. Lovable, Bolt, Replit, and their peers all keep some form of checkpoints, history, or restore points — a timeline of earlier states of the project. Open it, find the state from just before the change that caused the loss, and restore it. Then — before anything else — click through the features that were lost and confirm with your own eyes that they are back and working. A restore that looks right in the summary can still be missing the piece you care about.
- If the project is in git or on GitHub, restore from there instead. Version control remembers every committed state, immune to whatever the builder does next. Browse the commit history to the last state where the app worked and restore the overwritten files — or the whole project — from that commit. If you connected GitHub at any point, even casually, this copy very likely exists and is your cleanest way back.
- If neither history exists, salvage what you can. Three places may still hold the lost code. The conversation itself: ask the builder to print the previous full contents of the damaged file — if the original is still in its context, it can often reproduce it. Your hosting dashboard: the previous deployment on Vercel, Netlify, or similar usually stays live at its own address, which at least proves exactly what the old version did. And your downloads or email: an exported copy or shared preview from a milestone may be sitting there forgotten.
- Put a safety net in place before you continue. Whatever this incident cost you, make it one-time tuition. Connect the project to GitHub and commit (or let the builder commit) after every state you would hate to lose; if your tool cannot, download a complete copy of the project at each milestone and store it somewhere you control. Also find, right now, where your builder's history and restore controls live — you do not want to be learning that interface mid-crisis.
- Retry the original change in a small, fenced request. The change you originally wanted is still worth making — just not as an open invitation. Name the one file that may change, list the features and files that are explicitly off-limits, and ask for that single change:
Then test like a sceptic: the new fix, plus every feature that was lost last time, before you approve anything further.Fix the checkout total in src/checkout.ts ONLY. Do not modify any other file. The discount banner, the settings page, and the login flow are finished and must stay exactly as they are.
Why this happensOptional explanation
Most AI builders do not edit your files the way a person with a text editor does — line by line, touching only what needs to change. They work more like an enthusiastic contractor who, asked to fix a tap, rebuilds the whole kitchen from memory of what kitchens usually contain. The builder regenerates entire files from its current understanding of your app. When that understanding is complete, the result is fast and impressive. When the chat has grown long and early decisions have scrolled out of its working memory, the regenerated file quietly omits things: the settings page from last Tuesday, the special case in the pricing function, the button it added in the morning. Nothing announces the loss — the summary says "fixed!" and the deletions are only discovered when you next click the missing thing.
The damage compounds when the instinctive response is to ask the same builder, in the same overloaded chat, to put everything back. It regenerates again, from the same incomplete picture, and the restore attempt overwrites more. This is why the recovery order matters: secure a known-good version from outside the conversation first, and only then continue building on top of it.
- Whole-file regeneration: the builder rewrites files from its picture of your app, and the picture is missing pieces.
- Long chats lose early context: features built at the start are the first to vanish from later regenerations.
- No outside copy: if the only record of the good version lived inside the builder, there is nothing solid to return to.
- Fix-forward makes it worse: each repair attempt in the same session is another regeneration from the same incomplete picture.
Quick answers
Why does the builder rewrite whole files instead of just editing the broken part?
Many builders generate whole files from their current picture of your app rather than editing the exact lines you meant. As a chat grows long, early details fall out of that picture, so the regenerated file comes back missing pieces from the beginning of the project. It is a known behaviour of the tools, not something you caused — but it is why outside backups matter.
The builder says it put everything back. Should I believe it?
Not until you have tested them yourself. Builders produce confident summaries of work they only partially did. Click through the specific features that were lost and confirm each one genuinely works in the restored or rebuilt version before you let it make the next change.
What is the single best habit that prevents this?
A backup you control, outside the builder: connect the project to GitHub and commit after every working state, or download a full copy of the project at each milestone. The builder's own history is useful, but history you own survives account problems, project corruption, and every future tool change.