The AI builder keeps changing the design instead of just fixing the bug
Filed under AI builder problems (Lovable, Bolt, Replit)
Broad prompts like 'fix the login page' hand the builder a whole file to regenerate — and regenerating files is its default move — so every small fix quietly becomes a redesign unless the request fences in what may change.
Fastest route
Give your AI this prompt
Copy it, replace the bracketed part with your error, and send it.
Preview the prompt
Fix exactly one problem: [describe the single behavior that is wrong, e.g. "submitting the login form with a correct password shows an error instead of logging me in"]. Scope rules: 1) Before changing anything, tell me which file(s) you believe the fix requires. 2) Only change those files, and only the parts involved in this behavior. 3) Do NOT change layout, styling, colors, spacing, copy, or component structure. Do not rename or refactor anything. 4) Done means: [your acceptance test, e.g. "a correct password logs in and lands on the dashboard; a wrong one shows the existing error"]. 5) When you finish, list every file you changed and summarise each change in one line. If the fix seems to require touching the design or another file, stop and ask me first instead of doing it.
Fix it yourself
Follow the repair
- Shrink the ask to one behavior. Before sending, rewrite your request until it names a single observable behavior: not "fix the login page" but "when I submit the login form with a correct password, it shows an error instead of logging in". One behavior per round. If your ask has the word "and" in it, it's probably two rounds.
- Name the file and the boundary. Tell the builder where the change is allowed to live: "The fix should only require changes in the login form component." If you don't know the file, ask it to tell you which file it intends to change before changing it. Builders stay remarkably close to a boundary they've had to state out loud.
- Fence the design explicitly. Add, verbatim if you like: "Do not change the layout, styling, colors, spacing, or any copy. Do not modify any other file." Anything not fenced is treated as fair game for improvement — silence reads as permission. This single sentence prevents most surprise redesigns.
- Define done. State the acceptance test: "Done means: submitting with a correct password logs me in and lands on the dashboard; submitting with a wrong one shows the existing error message." A definition of done gives the builder a stopping point, so the round ends at the fix instead of continuing into polish, refactors, and "while I was in there" changes.
- Check the diff after every round. Use the tool's history, versions, or file view to see what actually changed before sending the next prompt. You're looking for scope: files you didn't name, styling churn, copy edits. A redesign caught in the round it happened is a quick restore; caught three rounds later, it's buried under work you want to keep.
- Roll back, don't re-describe. If a redesign already landed, restore the previous version from the tool's version history or checkpoints first — that brings back the exact design, because it was saved, not remembered. Then re-issue the fix using the fenced prompt below. Never ask the builder to "put the design back how it was": it will confidently manufacture a third design that resembles your description, which is not the same as the one you lost.
Why this happensOptional explanation
An AI builder doesn't edit your app the way you would, with a cursor and a small change. It produces new file contents. When the request is broad, the cheapest way for it to comply is to rewrite the whole component — and a rewrite re-decides everything in the file: the layout structure, the class names, the spacing, the button labels, sometimes the imports and half the page. Your design wasn't targeted; it was collateral, standing inside the blast radius of the file that contained your bug.
Your wording decides the blast radius. "Fix the login page" names a place, not a change, so the builder supplies its own idea of what fixing involves — and builders are trained to be ambitious, so the idea grows. Even "fix the login error" quietly licenses touching the form, its styling, and its validation unless told otherwise. This is also why the problem compounds: each unfenced round rewrites files the previous round produced, and within a few rounds the app looks like a different product that nobody chose. The fix is not a sterner tone. It is a smaller, fenced request, issued one at a time, with the changes reviewed between rounds.
- Vague scope: the prompt names a page or a feeling ("make it work") instead of one behavior.
- Whole-file delivery: the tool regenerates files, so everything in the file is renegotiated.
- No done-state: without an acceptance test, the builder keeps "improving" past the fix.
- Stacked rounds: several broad requests in a row drift the design a little each time, unnoticed until it's gone.
Quick answers
Is the AI ignoring my instructions?
Usually, no — it isn't ignoring you; it's filling the space your prompt left open. 'Fix the login page' names a page, not a change, and regenerating the file is the tool's default way to deliver. A prompt that names the file, the behavior, and the things that must not change gets a surgical edit far more reliably.
It already redesigned everything. How do I get my design back?
Restore it from the tool's version history or checkpoints, not by describing the old design and asking for it back — the AI has no reliable memory of the previous look. Roll back first, then re-ask for the fix with a fenced prompt.
What makes a prompt 'fenced'?
One that names the scope in the first sentence: the file, the exact behavior to change, and an explicit 'do not change' list covering layout, styling, copy, and other files. The copy-paste prompt on this page is built exactly that way.