Iterating on an AI-Built App Without Breaking Working Code

The one-sentence version: one scoped change, checked, before the next one

Every working feature in your app is a small amount of accumulated trust: it does what it's supposed to, and you've stopped worrying about it. A broad or vague iteration request risks spending that trust without you noticing, since an AI agent asked to "improve" or "clean up" an area has no way to know which parts you actually consider fixed and which parts you'd welcome changes to. The fix isn't caution for its own sake, it's making the boundary explicit every time: this, specifically, changes; everything else, specifically, doesn't.

The "no-fly zone": naming what must not change, explicitly

This site's own guide to writing prompts AI agents understand covers the third part of a well-formed request, what shouldn't change, as one of three things every good prompt names. It matters most specifically here, during iteration, since an agent working on a feature that's already partly built has real, working code sitting right next to whatever you're asking it to touch, and nothing stops it from "helpfully" adjusting that neighbouring code too unless you say otherwise. A named boundary, "leave the pricing table untouched," "don't rename any existing functions," removes the guesswork entirely rather than hoping the agent infers your intent correctly.

Your checkpoint before you iterate: Git, or your builder's own revert

Naming a boundary reduces the odds of an unwanted change; it doesn't eliminate them. A real checkpoint is what makes an unwanted change cheap to undo rather than something you have to manually describe your way back out of. This site's own guide to what Git actually is covers the underlying mechanism, and Git and GitHub basics for AI-built projects covers connecting Lovable, Base44 or Bolt.new to a real repository, more precise than any platform's own single revert button since every pushed change becomes its own inspectable, individually-restorable commit.

Why "also fix this while you're in there" is the single riskiest prompt pattern

Bundling an unrelated fix into the same request as your original change removes your ability to tell which of the two caused a new problem if one shows up afterward. This is exactly the mechanism this site's own guide to breaking vibe-code loops shows spiralling: fix A, and a bundled, unrelated "also fix B" changes something B depends on, which then affects A again, and now two changes are tangled together in a single conversation instead of one clean, checkable edit. Keeping requests to one thing at a time isn't slower in the ways that matter, it's what makes each step actually verifiable before you move to the next one.

Ask for a summary of what changed, not just the result

A short addition to any iteration prompt pays for itself: "tell me exactly what you changed." It costs one sentence and turns an otherwise invisible set of edits into a short, readable list you can hold up against what you actually asked for. Catching "I also renamed that shared function" in that summary, before it causes a problem somewhere else that uses it, is far cheaper than discovering it later as an unrelated, confusing bug.

Not every change needs this much ceremony

A colour tweak, a typo fix, a spacing adjustment on one element genuinely doesn't need a checkpoint-and-scope ritual built around it, the cost of that process would outweigh the actual risk. This matters more, not less, as a change gets closer to something with a real consequence if it breaks: a payment flow, an authentication check, anything this site's own guide to why a vibe-coded app isn't production-ready by default already flags as a path a quick demo never exercises. Match the discipline to what's actually at stake in the specific change, not to a fixed rule applied identically everywhere.