Why does my app break every time I ask the AI to change something?

You asked for something small. Move the button. Change the wording on the signup screen. The AI said "Done!" and now the login page is blank, the checkout doesn't work, or the whole thing shows a white screen.

This is the most common experience in AI-built software, and it is not because you prompted badly. It happens for reasons that have nothing to do with you.

Is the AI editing my app or rewriting it?

The AI does not hold your whole app in its head. It looks at the part it thinks is relevant to what you asked and produces new code for that part. It does not re-read the rest to check whether anything else was leaning on the bit it just changed.

Your app is full of shared pieces. The box that holds your login form is probably the same box holding your settings page. The bit of code that fetches a user is probably called from six different screens. Rewrite one of those to satisfy your request about the button, and the other five places get something they weren't expecting.

This is why the breakage so often lands somewhere with nothing to do with what you asked for. It feels random. It isn't. It's a shared piece changing shape.

Is "almost right" normal, or is my tool broken?

It is normal. The 2025 Stack Overflow Developer Survey asked developers what actually frustrates them about AI coding tools, and the biggest answer was solutions that are "almost right, but not quite."¹

Read that again, because it reframes everything. Professional engineers, with decades of vocabulary and a debugger open, say the main problem is code that looks finished and isn't. That is the same problem you have, without the training that lets someone else spot it in ten seconds.

Sean Ellis, writing about a year of building in Lovable, described the loop exactly: fix one thing, break another, tweak a component, break something unrelated.³ He wasn't shipping fast in that period. He was fighting things that used to work and had stopped.

Why does the AI say it worked when it didn't?

Because it doesn't know. When you make a change, the AI writes code and tells you it's done. What it usually hasn't done is use your app the way a real person does — sign in with a real account, submit the real form, take a real payment.

So "Done!" means "I wrote something that looks like what you asked for." It does not mean "I checked." Those two sentences feel identical in the chat window, and that gap is where most of the panic lives.

It gets worse than not knowing. In July 2025 the investor Jason Lemkin was building on Replit when its agent deleted his live database during what he had declared a freeze on changes, and then, he said, misrepresented what had happened. Replit's CEO publicly called the incident unacceptable and apologised.² It's an extreme case, but the lesson scales down to your button: what the AI reports about its own work is a guess, not a check.

Why does my app work for me but not for my users?

Most apps built with these tools have screens on one side and stored data on the other. The screens ask the data for things by name. Rename something on the data side, or add a rule about who can read what, and the screens keep asking the old way.

Nothing in the chat window warns you. The build succeeds. The preview may even look fine, because the preview is often logged in as you, with your permissions — and you are frequently the one account that can still see everything.

There's one more layer. The thing you look at while you edit is usually not the thing your users are using. There's the version in the editor and the version that's live, and they diverge in both directions: you fix something and it isn't live yet, or you push something out and only the live copy trips over it.

What actually reduces this?

None of this requires learning to code. It's mostly about narrowing what the AI feels invited to rewrite, and checking the result yourself.

1. 1
   One change per request

   Big combined asks are where the AI improvises most. Small asks are boring, and boring is what you want.
2. 2
   Name what must not change

   "Change the wording on the signup button. Do not touch the login flow, the database, or any other page." Not magic, but it narrows the blast radius.
3. 3
   Ask before you tell

   Most of these tools have a mode where the AI explains what it's about to do instead of doing it. Read the plan. If it mentions files or features you never asked about, that's your warning shot.
4. 4
   Keep a list of five things

   Write down the five things that absolutely must work — sign up, log in, the main action, pay, log out. After every change, do them yourself in a normal browser window, logged out first. Five minutes catches most of it.
5. 5
   Know how to go back

   These tools keep a history of previous versions and let you restore one. Find that button now, while nothing is on fire. Panic is a bad time to learn a new interface.
6. 6
   Stop after the second failed fix

   Each attempted fix touches more of the app and gives you more to untangle.⁴ If two tries haven't done it, roll back to the last version that worked and make a smaller request from there.

Before you change anything: describe the exact change you plan to make and list every file and screen you will touch. Do not write code yet.

The change I want is: [describe one small change].

Do not modify the login flow, the database structure, or any page I did not name. If the change requires touching anything else, stop and tell me why.

How do I find out when my live app breaks?

Something outside your app has to look at it regularly and tell you when it stops responding. The five-minute check only happens when you remember to do it, and the real hole is the hours between a break and hearing about it — usually from a user, usually apologetically, usually late.

Be clear about where the others win. UptimeRobot and Better Stack have been at this for years, check from more places around the world, keep longer and deeper histories, and offer far more ways to be notified, including phone and chat tools. If you have an engineer on your team, they will be happier in Better Stack, and they should use it.

Fomio fits the person reading this for a narrower reason. It doesn't ask how often to check or what counts as a failure, because those questions assume you know. You give it the link. When something goes wrong it tells you in words you already use, and on the paid plans it writes the prompt to paste straight back into the tool you built the app with — which is exactly the next thing you were going to have to figure out.

What should I do next?

Before your next change: find the version history in your tool and note where it is. Write your list of five things. Then make your next request small and say out loud what the AI is not allowed to touch.

And set something up to watch the live app, so the next time an edit takes it down, the thing that tells you is not a customer.