What to Do When AI Overwrites Code You Wanted to Keep

An AI assistant can change a landing page in seconds. That speed is useful until a small request produces a much larger edit.

You ask it to change one headline. It rewrites the hero section. You ask it to move a button. It replaces the CSS that controlled the mobile layout. The new version may still look plausible, which makes the missing details harder to notice.

This is a normal consequence of AI-assisted development. The practical question is not whether an assistant will eventually make an unwanted edit. The question is whether you can identify the change and restore the last working version.

First, stop making new changes

When a page breaks, the fastest reaction is often another prompt:

Fix the layout you just broke.

That can work, but it can also create a second layer of changes before you understand the first one. Each additional edit makes recovery less predictable.

Pause the editing session and preserve the current files. Even a broken version may contain one useful change that you want to reapply later.

Identify what was actually overwritten

Start with the smallest possible comparison.

Suppose the original hero contained this markup:

<section class="hero">
  <p class="eyebrow">Publish directly from your AI assistant</p>
  <h1>Give your AI somewhere to publish.</h1>
  <a class="button" href="/signup">Create a project</a>
</section>

You asked the assistant to change the button label. The resulting file now contains:

<section class="hero redesigned-hero">
  <h1>Build and launch your next website with AI.</h1>
  <p>Generate, edit, and publish in one workflow.</p>
  <a class="primary-cta" href="/register">Start building</a>
</section>

The request concerned three words. The result changed the structure, copy, class names, and destination URL.

Review changes at three levels:

1. Content: headings, labels, links, form fields, metadata.
2. Structure: elements added, removed, or moved.
3. Behavior: CSS classes, JavaScript hooks, form endpoints, analytics attributes.

A page can look correct while a form, tracking event, or responsive rule has stopped working.

Recover from the strongest source available

Use the most reliable recovery source you have, in this order.

1. A saved version or snapshot

A version created before the edit is the cleanest recovery point. Restore it first, verify the page, and then reapply the requested change as a smaller edit.

This separates recovery from experimentation. You return to a known working state before asking the assistant to try again.

2. A source-control commit

For projects stored in Git, inspect the diff and restore only the affected file or lines. This works well when commits are frequent and the person managing the page is comfortable with source control.

3. A previous exported copy

A downloaded ZIP, copied HTML file, or deployment artifact can provide the missing code. Compare it with the current version instead of replacing everything blindly, because the older copy may also remove valid recent work.

4. The chat transcript

The conversation can help reconstruct intent, but it is a weak backup. A transcript records prompts and responses; it does not always preserve the exact state of every file after each operation.

Use it to understand what changed, then verify the reconstructed files manually.

Restore first, then make the edit smaller

After recovering the working version, rewrite the task so the editing boundary is explicit.

A broad instruction:

Update the hero CTA.

A bounded instruction:

In index.html, change only the visible text inside the existing anchor with class button from Create a project to Publish your site. Preserve the element, href, classes, surrounding markup, CSS, and JavaScript. Return the exact diff before applying any other change.

This does not guarantee a perfect result, but it reduces ambiguity. File names, selectors, preserved attributes, and forbidden scope give the assistant a smaller decision surface.

Verify the restored page

A successful rollback means more than seeing the old design again.

Check the parts that produce business value:

• navigation and CTA destinations;
• contact-form submission;
• mobile and desktop layout;
• analytics and tracking attributes;
• custom-domain response;
• page title, description, and social metadata.

For a lead-generation page, submit a real test entry. A visually correct form that no longer records enquiries is still a broken page.

Why chat history is not version history

Chat history explains the conversation. Version history records the state of the project.

Those are different assets.

A chat may contain several proposed implementations, partial code blocks, corrections, and later edits. The final working combination may never appear as one complete message. A project version preserves that combination as a recoverable state.

This distinction becomes more important when several assistants or team members work on the same page. Without discrete versions, every new edit depends on someone remembering what changed earlier.

A safer AI editing workflow

A reliable workflow is simple:

1. Save a version before a meaningful edit.
2. Ask for one bounded change.
3. Review the diff or changed files.
4. Test the page and its forms.
5. Save a new version after verification.

The goal is not to slow down AI-assisted work. It is to preserve the speed while making each accepted change reversible.

Using Deplion for recoverable publishing

Deplion keeps published projects as versions that can be restored when an AI assistant changes the wrong code. The assistant can continue working through MCP, while the project retains recoverable states, domains, and form submissions in one workflow.

When an edit goes wrong, restore the last working version, verify the page, and reapply only the intended change.

Create a Deplion project and give your AI assistant a publication workflow with rollback built in.