Every fix breaks something that was working

You ask for one small change. The AI edits nine files, the change works, and something unrelated is now broken. This is the defining daily frustration of building with AI, and the fix is a routine rather than a better prompt.

Why it happens

The AI can only see part of your project at a time, and it doesn't know which parts you actually care about. When it touches shared code it has no way to tell that the change also affects the checkout page you never mentioned. It isn't being careless; it's working without the knowledge of what matters that lives only in your head.

The routine that fixes it

1. Save a known-good version before each change

Not after: before. The value of a save is that it marks a state you're certain worked. Then "undo everything since this morning" is a decision rather than an archaeology project.

2. One change at a time, described narrowly

"Change the pricing page heading" invites a small edit. "Improve the pricing page" invites a rewrite. Narrow the ask, and say what's out of bounds:

3. Keep a list of what must keep working

Write down the five things your app absolutely has to do: sign up, log in, the main action, checkout, the contact form. Whatever they are, that list is the thing the AI can't guess. Give it to the AI as context and click through it yourself after each meaningful change. Five minutes of clicking catches nearly everything.

4. Make it explain the blast radius before it starts

When it breaks anyway

Go back to the last version you know worked, rather than asking the AI to fix forward. Fixing forward on top of a broken state is how one bad afternoon becomes a lost week: each repair is written against code that's already wrong. If your project has a saved history, this is one click. If it doesn't, our guides on undo in Cursor and undo in Claude Code cover what your tool can recover on its own, and the comparison covers giving the project a proper history so this stops being a crisis.