Each AI edit breaks something else: how to stabilise an AI-built app
When each AI edit breaks something else, stop asking for fixes. Go back to the last version that worked, then put four guards in place: version control outside the builder, tests for the flows that matter, one small change at a time, and a review of every change before it goes live. Lovable's own debugging guide gives the same first step: if an error survives one or two fix attempts, stop and switch to Plan mode, because repeated fixes made without finding the cause bury the real problem under extra code (Lovable, Debug and improve your app). The method below is our own, built from rescuing AI-built apps. Where a builder's docs back a step, we link them.
Why one fix breaks another
Our view: AI builders change code quickly and widely. A request to fix a button can touch a shared component, a data query and a style used on ten pages. Without tests, nobody notices the other nine until a user does. Lovable's guide says the same in one line: if a change touches a shared component, confirm every feature that depends on it still works.
Step 1: freeze and find a known-good version
- Lovable. Every change creates a version. Open History, preview old versions read-only, and choose Revert. You can bookmark versions you trust. Revert affects code only: Lovable says it does not roll back your database data, and data changes made after that version remain (Lovable, Version history).
- Bolt. Open Version history, select a version and choose Restore this version. Bolt says restoring does not change your current Bolt or Supabase databases (Bolt help, Backups and version history).
Because neither revert touches data, check whether any broken edit changed the database structure. If it did, the old code may not match the current tables, and that needs a careful fix rather than another revert.
Step 2: keep history outside the builder
Connect GitHub so every change is recorded somewhere you control. Lovable syncs both ways with GitHub and works on one branch at a time (Lovable, GitHub). Bolt commits each change that does not break the project, and stays linked to the main branch (Bolt help, GitHub). Our advice: once a version works, write down its commit or bookmark it with a plain name such as "checkout works, 15 Nov". That gives you a known place to return to.
Step 3: test the flows that matter
Lovable can write and run tests on request: browser testing that clicks through your app, frontend tests, and tests for backend functions. For TanStack Start apps created from 13 May 2026, it writes a small test automatically when you add or change a rule such as a price or permission (Lovable, Test and verify your app). Whatever the builder, keep your own short list and run it after every change:
- Sign up, confirm, sign in, sign out, reset password.
- The one or two things the app exists to do, end to end.
- Payment, if there is one, in test mode.
- Permissions: a second account cannot see the first account's data. Our note on row level security mistakes describes this test.
Step 4: make one small, scoped change at a time
Lovable's guide asks you to change only what the task requires and to treat working features as locked. Our version of that rule:
- Plan first. Ask the builder to explain what it will change before it changes anything.
- One change per message. Name the files or screens that may change, and the ones that must not.
- For sign-in and payments, ask it to read the related code and stop to explain anything it is unsure of.
- Keep a list of improvements for later instead of folding them into a fix.
Step 5: review before it goes live
On Bolt, edits do not reach the published site until you click Update, which gives you a natural checkpoint. With GitHub connected, every change can be read as a diff, and a pull request lets you review changes before merging them (GitHub Docs, About pull requests). Our review checklist is short: did files outside the task change, did any database structure or access rule change, did any key or secret appear in browser code, and does the test list still pass?
The same habits apply to any AI agent that edits a live app; we wrote about one in what to review before Bubble®'s Agent 2 edits your live app.
When the loop will not break
Sometimes the code has drifted too far to fix by prompting. App Triage ($99 USD) gives you a written diagnosis and a plan. The AI-Built App Audit ($299 USD) is a report-only review ranked by risk. App Rescue and Move to Cloudflare covers stability, sign-in, security and SEO in its Rescue in place step for a fixed $999 USD. If the app works in the editor but not once published, start with a Bolt app that breaks when published.
Sources
- Debug and improve your app, Lovable docs
- Revert and restore your project with version history, Lovable docs
- Test and verify your app, Lovable docs
- Sync your Lovable project with GitHub, Lovable docs
- Backups, restore, and version history, Bolt help centre
- GitHub for version control, Bolt help centre
- About pull requests, GitHub Docs