AI App Builder Overwrote My Changes
You fixed a bug by hand, asked for one more feature, and the fix vanished. Here is how to recover it, why builders regenerate whole files, and the three habits that stop it happening again.
The fastest fix, before anything else: check the builder's version history and restore the snapshot from just before your last prompt. Most builders keep one, most people never open it, and it recovers the work in under a minute. If that fails, and you have the project connected to git, git reflog will find the commit even when the branch no longer points at it.
Do that first. Then work out which of the four failure modes you actually hit, because they have different fixes and only one of them is really a bug.
"My AI app builder overwrote my changes" describes four quite different events, and people reach for the wrong remedy because they assume it is always the same one.
The four ways your edits disappear
Whole-file regeneration. You asked for a change to one part of a component. The builder rewrote the entire file from its own understanding of what that file should contain, and your hand-written edit was not in that understanding. This is the most common cause and it is a design decision, not a fault. Generating a whole file is more reliable for a model than producing a precise patch.
The builder never saw your edit. You edited in an external editor, or through a git push, and the builder is working from its own copy or from a cached project state. It did not overwrite your change so much as never know about it. Symptom: the change is missing from what the builder shows you, not just from the output.
Prompt scope creep. You said "make the header sticky" and the model decided the header component needed tidying while it was there. The edit survived in spirit and got reformatted, renamed, or refactored out of recognition. Symptom: your logic is technically still present but restructured.
Genuine conflict resolution. Two changes touched the same lines and the builder silently picked one. Rarer, and the hardest to notice, because both versions look plausible.
Sorting which one you hit takes about a minute and determines whether recovery is possible at all.
Recovering the work
Situation | Where to look first |
|---|---|
Builder has snapshots or version history | Restore the snapshot from before the prompt |
Project is connected to git |
|
Edited in browser, no git, no snapshots | Browser local history, or the editor's undo stack if the tab is still open |
Edited locally, builder overwrote on sync | Your local editor's file history, which is usually still intact |
The git route is the reliable one and worth understanding even if you do not otherwise use git. Commits are not deleted when a branch moves; they become unreferenced, and the reflog records where your branch tips have been. Unreferenced commits survive until garbage collection, typically weeks. So "the AI deleted my code" is usually "the AI moved a pointer" and is recoverable for longer than people assume.
If none of those apply, the work is gone. Rewrite it now while you still remember it, then read the next section before you lose it a second time.
Three habits that stop the recurrence
Commit before every prompt, not after. One line, or one button, before you type a request. Then the pre-prompt state is always addressable, and you can diff exactly what the builder did rather than reconstructing it from memory. This single habit removes most of the pain and costs nothing.
Put hand-written logic where regeneration will not reach. Builders regenerate files they consider theirs, which is usually the file you asked about. Move anything you have carefully hand-tuned into its own module and import it. A custom pricing calculation in lib/pricing.ts is much safer than the same calculation inline in the component you keep asking the builder to change. This is the highest-value structural habit, and it also makes the eventual handing the app off to a developer far easier.
Mark the code you do not want touched. Most builders respect an explicit instruction in the file itself:
// MANUAL: hand-written, do not regenerate.
// Fixes the timezone bug from issue #42. Verified against
// DST boundaries. Do not replace with a library call.
export function toLocalBusinessDay(utc: Date, tz: string) {
...
}This is not enforcement and it is not guaranteed. It is a signal that meaningfully changes the odds, because the instruction is in the context whenever the model reads the file. Pair it with the module separation above and the exposure drops sharply.
Narrow the prompt, narrow the blast radius
Most whole-file regeneration is triggered by prompts that give the model licence to rewrite. "Fix the checkout page" invites a rewrite. "In CheckoutForm.tsx, change the submit button label to Pay now, and change nothing else" does not.
Three phrasings that measurably reduce collateral damage:
Name the file and the function. Ambiguity about location is ambiguity about scope.
Say "change nothing else in this file" explicitly. It is one clause and it works more often than it does not.
Ask for the diff before the edit when the change is delicate. "Show me the change you plan to make, do not apply it yet" converts an overwrite into a review.
What to check before you rewrite anything
Before you retype the lost work, spend two minutes confirming it is actually gone:
Look at the file on disk, not in the builder's preview. Previews cache. The bytes on disk are the truth.
Search the whole project for a distinctive string from your edit. Builders sometimes relocate code rather than delete it, and a refactor can move your function into a file you would never think to open.
Check for a duplicate or backup file. Some builders write
Component.old.tsxor leave the previous version in a scratch directory.Read the builder's own change log for the prompt. Many list the files they touched. If your file is not on that list, the change came from somewhere else, and you are debugging the wrong event.
When it is not really the builder's fault
Two cases deserve honesty. If you edit the same project in a local editor and in the builder at the same time, you have two writers and no merge strategy, and something will be lost. Pick one as the source of truth for a given session.
And if the builder has no version history, no git connection, and no export, the risk was structural before this incident. That is worth fixing on its own terms, and it is the practical core of how builder lock-in actually works and of exporting your app out of the builder. A project you cannot get a copy of is one bad prompt from a bad week. The broader workflow around all of this is in the full guide to building an app with AI.
FAQ
Can I undo a builder change after I have closed the tab?
Often yes, through the builder's own version history, which is server side and survives the session. If the project is in git, the reflog is the better route. If neither exists, closing the tab usually ends the options.
Why does the AI app builder overwrite my changes instead of editing them?
Because emitting a complete file is more reliable for a model than producing a precise patch against code it did not write. Whole-file generation trades your manual edits for a lower failure rate on the edit it was asked to make. Some builders now do targeted edits, and they still fall back to regeneration on larger changes.
Does connecting to GitHub prevent this?
It does not prevent the overwrite, but it makes it recoverable, which in practice is most of the value. Connect the repository even if you never intend to use git directly.
Should I stop editing code by hand?
No. Hand-editing is often the fastest route to a specific fix. Just move those fixes into their own files, mark them, and commit before each prompt. The habits are cheap and they remove the class of problem rather than one instance of it.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
