Make your AI app builder fix one thing without breaking the rest

You asked it to fix the button. It fixed the button, moved your header, renamed two pages and broke sign-up.

The AI didn’t misbehave. You gave it a small request and a big room to work in. It filled the room.

The fix is a routine, not a better tool. Plan first, ask for one scoped change, check it, and know where the undo button is before you need it. It works the same way in Lovable, Replit, Cursor and Claude Code. The details below come from each tool’s own docs, checked on 9 November 2026.

If you’d rather learn this inside a first real build, this is where I teach it.

Why does the AI change things you didn’t ask for?

Because “fix the login” isn’t one instruction to an AI. It’s permission to touch every file that has anything to do with logging in.

It also can’t see what you care about. It doesn’t know the header is finished or that you like the pricing page. So it tidies whatever looks tidy-able.

Vague asks are the same problem in any prompt. In stop adding roles to your AI prompts I argue for audience, goal, format, constraints and context instead. For a fix, the constraint does most of the work: “keep everything else exactly as it is”.

How do you get the AI to change one thing only?

Six habits, in this order.

1. Ask first, edit second

Every one of these tools has a mode that reads your project and edits nothing until you approve.

In Lovable, Chat mode messages cost a fraction of a credit and come out of a daily allowance first, while each Plan mode message costs one credit (Lovable Chat mode, Lovable Plan mode). If credits are tight, my guide on how many Lovable credits a SaaS app takes helps you budget.

Cursor’s Plan mode researches the code, asks clarifying questions and writes a plan you edit before any code is written (Cursor Plan mode). Claude Code’s plan mode lets you approve with “Yes, manually approve edits” if you want to see each change (Claude Code permission modes).

Use it for bugs you don’t understand and anything touching more than one screen. A colour change doesn’t need a plan.

2. Write a scoped prompt

A scoped prompt has 4 parts: the one change, where it is, what must stay the same, and how you’ll check it. The “Scoped fix” prompt below has all 4 with blanks to fill.

The line that matters most is “keep exactly as it is”, with named screens. Lovable’s own best-practice page says the same: name the parts it shouldn’t change (Lovable best practice).

Replit gives the same advice for Plan mode: one goal and what should stay the same. If the plan comes back huge, ask it to shrink to the smallest testable version (Replit docs). The “Shrink the plan” prompt does that.

These prompts are starting points, not tested recipes. Adjust the wording to your app.

3. Point instead of describing

For layout bugs, words fail. “The thing under the header is too far down” has 5 possible meanings.

In Lovable, use the preview toolbar’s Select elements mode (press S) to click the exact element, or Draw annotation (D) to circle it (Lovable preview toolbar). Both use credits. For a text change, Edit text inline (T) is free for 100 edits, refilling after 24 hours.

In the other tools, a screenshot pasted into the chat does the same job.

4. One change per prompt, then check

Make one change. Open the preview. Click through the thing you changed and the thing next to it. Then send the next prompt.

Stacking 3 fixes in one message means that when something breaks, you don’t know which fix did it.

5. Stop after 2 failed fixes

If the AI fails twice on the same bug, don’t send a third fix. Find the cause first.

Lovable’s advice: stop after a couple of failed Try to fix attempts and switch to Plan mode to find the root cause. Do the same in any tool with the “Diagnose before fixing” prompt. It asks for the likely cause in plain English, the smallest fix and what else might break, with no edits.

6. Write the don’t-touch rules once

You’ll repeat “don’t touch the header” until you save it somewhere the AI reads every time. In Lovable, that’s Project instructions: a one-page brief with your user journeys, design rules and recurring mistakes. Lovable drafts one from your existing build if you ask (Lovable best practice).

The “Write my don’t-touch rules” prompt builds the brief from your answers, for any tool.

How do you undo an AI change?

Find your undo button now, while nothing’s broken.

• Lovable: open History from the top bar, pick a version and click Revert (Lovable History). Bookmark a version you know works, so you find it fast. Edit message > Revert and resend tries a different direction from an earlier message.
• Replit: open the Agent history, choose the rollback option on a checkpoint and confirm. Everything after that point goes. New changes after a rollback make the later checkpoints unreachable (Replit checkpoints).
• Cursor: hover over an earlier message and click Restore Checkpoint. It rolls back every file the Agent changed after that point, and your messages stay in the chat (Cursor help).
• Claude Code: type /rewind, or press Esc twice on an empty prompt. Choose to restore the code, the conversation or both (Claude Code checkpointing).

What doesn’t undo bring back?

Your data. This is the part that hurts.

• Lovable’s Revert restores code but doesn’t roll back database data or migrations. Credits spent on the reverted work don’t come back either.
• Replit only restores the development database if you tick Database in the rollback options. The production database never comes back this way.
• Claude Code’s checkpoints miss files changed by terminal commands and edits made outside Claude Code. Anthropic says they don’t replace Git.

So anything that changes your data or database gets its own prompt, its own plan, and your full attention. Never bundle it with a design fix.

Which tool makes this easiest?

Lovable, for a first app. Chat mode is cheap, Plan mode is clear, and Revert is two clicks. That’s where I’d validate an idea and get a rough version out.

Cursor gives you the most control once your app gets serious, and it’s where I build anything going to the App Store. The trade-off: more settings to learn. My comparison of the best vibe coding tools covers both.

If your first version keeps growing every time you fix something, cut it back. What to put in your first app version helps you decide what stays.

For the standing rules the agent should read before every task, not just one fix, set up a rules file for your AI coding agent.

Make one change to my app.

The change: [what should be different, in one sentence]
Where it is: [screen, page or feature name]
Keep exactly as it is: [screens, features or styles that must not change]
How I'll check it: [what I'll click or look at in the preview]

Only change what's needed for this. Don't refactor, rename or restyle anything else. If the fix needs changes outside this area, stop and ask me first.

When you're done, list every file you changed and say in one sentence what changed in each.

Don't change any code yet.

The problem: [what goes wrong]
What I expected: [what should happen]
How to see it: [the steps to reproduce it]
What I've tried: [earlier fixes that didn't work]

Look through the project and tell me, in plain English:
1. The most likely cause, and how sure you are.
2. The smallest fix that would solve it.
3. Which files the fix would touch.
4. What else might break.

If you're not sure of the cause, say so and tell me what would help you find it.

Your plan is bigger than I want right now.

Cut it down to the smallest change I can test in the preview today. Keep only the steps needed for that.

Move everything else to a "Later" list at the bottom, one line each, so nothing gets lost. Don't start building until I approve the smaller plan.

Help me write a short instructions block for my AI app builder so it stops changing things I didn't ask for.

About my app: [what it does and who uses it]
Main things users do: [for example: sign up, book a class, pay]
Parts that are finished and must not change without asking: [list]
Mistakes the AI keeps making: [list]

Write it in plain English, under 40 lines, with these sections: About this app, Main user journeys, Don't change without asking, Recurring mistakes. Every line must be specific enough to check. Don't add features my app doesn't have.