My AI broke my site, how do I go back

Updated on

Your site worked this morning. Now it is broken, and the AI offers a fix that breaks something else. You pile on patches, every attempt makes it worse, and you no longer remember what the working version looked like. You just want to go back, without knowing how.

Do not ask the AI to fix it. Go back to the last version that worked first, then look at what changed. If your project is under version control, one command undoes everything. If not, your backup is the only way out, and you need to set up tracking right now.

The instinct that makes it worse

The site worked. You asked for a small change. Nothing displays any more.

The natural instinct is to tell the AI “it is broken, fix it”. That is the worst possible sequence, for one simple reason: it does not remember the previous state. So it rebuilds, from memory, something resembling what you had. You end up with a third version, neither the original nor the broken one, and the problem becomes impossible to locate.

Do not repair. Go back.

In order

1. Stop changing things. Every extra change moves you further from the state that worked. Close it, breathe.

2. Return to the last working version. If your project is under version control, that is one command and it is instant. You get back exactly what you had, down to the comma.

3. Look at what had changed. Once you are back on safe ground, you can compare the two versions calmly and see the exact lines that broke.

4. Ask for the change again, differently. This time, ask for the plan before the execution.

The three breakages, and why they must be told apart

“Broken” covers three very different situations, and confusing them is what costs you the afternoon.

The page is blank. The most dramatic, and often the least serious: a single error is enough to stop everything dead. The rest of the site is intact, it simply is not being displayed.

The page loads, but something no longer responds. A dead button, a form that sends nothing, a missing image. Here the damage is local, and it is found at the exact spot of the last change.

Everything works on your machine and nothing works online. The most disorienting case, because there is nothing to repair in your code. The difference lies elsewhere: a file left out of the upload, an address that only resolves on your machine, a key missing from the server.

In all three cases, going back remains the right first move. But knowing which one you are in saves you two hours of searching in the wrong file.

The backup that is not one

Plenty of people believe they are covered and are not, for two reasons that come up constantly.

“My host takes backups.” Possibly, and they mostly exist to protect the host. They are often daily, sometimes chargeable to restore, and they bring back the whole server state — not the version of your file from the day before yesterday. A backup you cannot restore yourself is, in practice, not a backup.

“I have a copy of the folder.” Better than nothing, and still a single point in time. You can go back to the copy; you cannot see what changed in between, nor return to an intermediate state. It is the difference between a photograph and a film.

The test that settles it is simple, and it is done on a day when nothing is on fire: try restoring. If you cannot manage it in ten minutes unaided, you do not have a backup, you have an intention.

If you have none of that

If your project is under no version control at all, there is no elegant answer. Your most recent backup is the only way out, and if it is three weeks old, you lose three weeks.

That is the situation nobody wants to be in, and it is the situation most beginners are in.

Set up version tracking before you resume work. Not after, not next week. It is thirty minutes once, and it turns every future disaster into a single command.

How to make this impossible

Nearly every accident of this kind comes from a change you did not ask for: a spontaneous tidy-up, an improvement along the way, a neighbouring file touched “while we’re here”.

An instruction written into your instruction file shuts that door — provided it is phrased as a checkable order and not a wish. That is the whole difference between an instruction that gets followed and one that gets ignored: “be careful” means nothing to a machine, “wait for my go-ahead before touching a second file” can be checked at a glance.

The most effective of them all is the one requiring the plan before the action. A five-line plan lets you see the surprise change coming before it is applied — which is the only moment it costs nothing.

What stays true

A written instruction can be ignored. Rarely, but it happens.

That is why version control is not optional. The instruction lowers how often accidents happen. The backup decides what happens on the day one happens anyway.

Same request, two answers. Click to compare.

> change the button colour to green

Frequently asked questions

I have no version control, what now?
Your most recent backup is your only option. Restore it, then set up version tracking before you resume work. Until that is done, every working session is a gamble.
Can I just ask the AI to undo what it did?
Bad idea in most cases. It does not reliably remember the previous state, so it rebuilds from memory something that resembles the original without being it. You have added a layer to the problem.
How do I find out exactly what broke?
Compare the working version and the broken one file by file. Version control does that in one command and shows you only the lines that changed.

Sources

  1. Git documentation — undoing things — accessed