When the AI changes the wrong thing

What to do in the next two minutes

You asked for one thing and got another. The heading you wanted moved is where it was, the paragraph you liked has been rewritten, and a page you had not mentioned looks different. The instinct is to type a second message explaining what went wrong. Do not. That is the move that turns one bad turn into an afternoon.

There is a version of the site from before that message ran, and it is one click away. Every build turn is snapshotted before it runs, and reverting is itself revertible. So the fastest route back is not an argument with the model, it is the history button beside the project name in the top bar.

Six steps, in this order. The whole thing takes about a minute once you have done it once, and the last step is the one people skip.

• Stop typing. The next turn builds on the files as they are now — the wrong ones — not on the ones you meant to keep.
• Open the history button beside the project name at the top of the builder.
• Find the entry labelled with the message you just sent. Each entry is the files as they stood before that message ran, and it says when.
• Restore it. The files go back to that point and the preview redraws.
• Check the pages that were right before it, not just the page you were looking at. A turn can touch files you did not name.
• Now write the instruction again, narrower — one change, named page, and a sentence saying what should stay as it is.

Note. The history entry is labelled with the words you typed. That is what makes the list usable a week later — you are looking for the sentence you regret, not for a timestamp you have to guess at.

Why asking it to undo the change makes it worse

This is the complaint people write up more than any other about building a site by asking for it, and it is worth naming plainly rather than selling around. You say "no, put the old wording back". What comes back is not the old wording. It is a third version, different from both, which fixes the thing you named and quietly moves something else. So you explain again. Round four is further from where you started than round one was.

Nothing strange is happening. "Undo that" is a new instruction and it is answered with new work — the model is looking at the files as they are now and at your sentence, and it writes files. It has no way to hand you back something it is not looking at. The only thing that has the old files is the version list.

The tell is simple, and it is worth learning to spot at round two rather than round five: if you have described the same problem twice, you are in the loop. Stop and restore. The loop does not resolve on its own, because every round changes the thing you are describing.

It costs money as well as time, and the honest version of that is not flattering. Billing is metered: a hold is taken before the turn and the difference refunded after. But a turn that ran and wrote files is a completed turn and is charged for, whether or not the files were what you asked for. Four attempts at the same fix are four turns.

Note. If you have said the same thing twice, you are not being misunderstood. You are building on top of the mistake. Go back first, then say it once.

Going back is the fix, not asking again

A wrong change is not an argument you have to win. It is a version you step back to. That is the whole of it, and everything below is detail about how far back you can go and what comes with you.

The snapshot is taken before the turn rather than after, which sounds like a technical distinction and is not. It means restoring gives you the site as it was when you asked, which is what a person means when they say a change made things worse. Hand edits in the code pane are snapshotted the same way, so a bad manual change to a file undoes as cleanly as a bad generation. And restoring is itself snapshotted before it happens, so the one action people take while panicking is not the one action with no way out of it.

The list holds the last thirty versions. For most people that is weeks of work, because a turn that changed nothing does not take a slot. It is not an archive, though, and it is not a backup — see the last section for what it does not cover.

If you are building this for somebody else, the version list is doing a second job. It is the reason you can take a change back out on Monday after a client has looked at it over the weekend, without having to remember what the page said on Friday. Studio is $299 a month and Agency starts at $399, both written for people who build sites for other people, and this is the feature that stops a Friday afternoon request becoming a Monday morning rebuild.

The outermost version of the same idea is that you do not have to keep the site here at all. Export to GitHub or Vercel sits on the free tier, not behind a paid plan — so if you want an undo that nobody else administers, put the project in a repository and use the one you already trust.

• Before every build turn, labelled with what you typed.
• Before every hand edit in the code pane.
• Before every restore, so a restore you regret is one more restore away.
• Not for a turn that changed nothing — that entry is dropped rather than left in the list.
• The last thirty entries, oldest dropping off the end.

How to ask so it goes wrong less often

Going back is the cure. This section is the prevention, and it is worth more of your attention than the cure is, because most wrong changes are wrong for a reason you can see in the sentence that caused them.

Four things make an instruction land where you meant it. One change. The page it happens on. The element it happens to. And a sentence saying what should stay as it is. That last one feels redundant and is the single highest-value thing you can add, because a broad instruction gives the model no reason not to tidy up three other things while it is in there.

One change per turn is the rule people break first, usually because typing three at once feels efficient. It is not. A turn carrying three requests is a turn where you cannot tell which sentence caused the damage, and it is one restore for all three, so you lose the two that landed correctly along with the one that did not. Three separate turns cost the same and each one is independently undoable.

Name the page. "Move the phone number up" is ambiguous the moment the site has five pages, and an ambiguous instruction gets answered everywhere it might apply. "On the contact page, move the phone number above the map" cannot be answered anywhere else.

Use the words you would use out loud rather than design words you half know. "Increase the vertical rhythm of the hero" is a sentence you will not be able to check the result of. "There is too much white space above the photograph on the home page" describes something you can look at and confirm.

And describe the outcome rather than the mechanism when you are not sure of the mechanism. "Nobody can find the phone number on a phone" is a better instruction than a guess at what to change, because the guess narrows the fix to your guess.

There is one exception, and it is the mirror image of everything above. When the whole site is subtly wrong — the tone is off, it reads as a bigger company than you are, it sounds like a call centre — do not fix it a paragraph at a time. Say the general thing once and let the whole site move together, because patching sentence by sentence leaves you with a site that argues with itself.

Note. The sentence worth adding to almost every instruction: "leave everything else as it is". It costs you four words and it is the difference between a change and a redecoration.

What going back does not fix

Restoring puts the files back. It does not put the money back, and it does not put anything back that was never in the files to begin with, so it is worth knowing the edges before you rely on it.

A turn that ran and produced files is charged for, and wanting different files does not change that. The exception is narrow and worth having: a turn that produced nothing is refunded in full, and the app says so on the turn. So a build that died before writing anything is free, and a build that wrote the wrong thing is not. Four rounds of the fix loop is four turns you paid for, which is the practical argument for restoring at round two.

The version list is only the project's files. Your domain is not in it, and neither is where a form sends, nor anything you have already pushed to a hosting account of your own. Undoing a change to the site does not walk back a change you made at your registrar, and it should not.

Thirty versions is not an archive. If a particular state of the site matters — the version a client signed off, the one before a rebuild — take it out of the builder rather than trusting the list to still have it in a month. Download the whole project as a zip, or push it to your own GitHub or Vercel account. Export to GitHub or Vercel sits on the free tier, not behind a paid plan, so there is no argument about whether it is worth doing.

And the honest disqualifier. If you cannot say in plain words what is wrong, going back does not help you — you will restore the good version and then produce the same wrong turn again, because the instruction has not changed. Restoring buys you a clean starting point, not a better sentence. Likewise, if what you want is to nudge a heading four pixels to the left and see it move as you drag, this is the wrong shape of tool and no amount of version history makes it the right one. The code pane exists, but an edit you make there is a hand edit like any other, and hand edits are how people end up with a site only they can change.

Note. Before anything you would hate to lose — a rebuild, a big change of direction, a client sign-off — take a copy out. Sixty seconds, and it is the one undo nobody else administers.

Common questions

How do I undo a change an AI website builder made?

Use the version history rather than asking the model to reverse it. Every build turn is snapshotted before it runs, so there is an entry labelled with the message you sent, holding the files as they stood before that message. Restore it, then send a narrower instruction. Asking the model to undo something produces a third version rather than the original.

Why does asking it to fix a mistake make things worse?

Because "undo that" is a new instruction and gets answered with new work. The model writes files based on how they are now and what you just said, so it produces something different from both the version you liked and the version you did not. Each round moves the site further from where it was right. If you have described the same problem twice, restore instead.

Do I get charged for a turn that changed the wrong thing?

Yes. A turn that ran and wrote files is charged for whether or not the files were what you wanted. Billing is metered, so a hold is taken before the turn and the difference refunded after, but the charge itself stands. The narrow exception is that a turn that produced nothing is refunded in full, and the app says so on the turn.

Can I get back a version from last week?

Sometimes. The list holds the last thirty versions, and a turn that changed nothing does not take a slot, so for most people that covers a good stretch of work. It is not an archive though. If a particular state matters — the one a client approved, the one before a rebuild — take a copy out of the builder rather than relying on the list to still hold it.

Does restoring an old version undo the whole conversation?

No. Restoring puts the project files back to that point. It does not remove messages, and it does not touch anything that was never in the files — your domain, where a form sends, or a copy you have already pushed to a hosting account of your own.

Can I keep my own copy outside the builder?

Yes, and it is the strongest form of the same idea. Download the whole project as a zip, or push it to your own GitHub or Vercel account. Export to GitHub or Vercel sits on the free tier, not behind a paid plan, so once the code is in a repository your undo is whatever your repository already gives you.