When AI overwrites your code
You opened the file. The AI wrote over what you had. The lines you spent two hours getting right are gone, replaced by something different. Maybe it works, maybe it doesn't; either way, the work you had is no longer there. The instinct is panic.
The panic is reasonable. The instinct that follows panic, which is to immediately ask the AI to "put it back," is the wrong move. The AI doesn't have a reliable model of what was there before. Asking it to restore the previous version will produce a fresh approximation that may or may not match what you actually had.
I want to walk through the recovery sequence for when this has just happened, and then the discipline that makes the next overwrite recoverable rather than catastrophic. The discipline is small upfront work that prevents the recurrence of the situation you're currently in.
Step one: stop touching the file
The first move is to not save anything new to the affected file. Don't close it without saving (the IDE might prompt you and you might click the wrong button). Don't run the AI tool again on the same file. Don't manually edit the new version trying to add back what was lost.
Every additional change to the affected file reduces your recovery options. The current state of the file is the worst-case baseline; you want to preserve enough of the situation to find better recovery paths than this baseline.
Step two: check version control
If the file is in a git repository (or any version control), check whether the previous version is recoverable.
git status shows whether the file is modified, staged, or committed.
If the file is modified but not staged, git diff <filename> shows the change from the last committed version. If the previous content is in the diff, you can recover it by reverting or by extracting the old version from the diff output.
If the file is staged but not committed, git reset HEAD <filename> unstages it; you can then recover or compare with the committed version.
If the file was committed and then overwritten, git log <filename> shows the history; you can find the commit before the overwrite and recover the previous version with git checkout <commit> -- <filename>.
If the AI made changes that aren't yet committed and you've been making frequent commits, recovery is usually clean. If you haven't been committing frequently, recovery is harder but often still possible.
Step three: check editor history
Most modern IDEs maintain local history independent of version control. VS Code has Timeline. JetBrains IDEs have Local History. Sublime has unsaved-changes recovery.
These tools record local changes at intervals, often every few minutes, regardless of whether you committed or saved deliberately. If version control doesn't have your previous version, the IDE's local history might.
Check this even if you don't think you used the IDE that made the overwrite. Sometimes the local history was being recorded by an IDE you had open in the background.
Step four: check the file system
Operating systems often retain shadow copies of files. Windows has Previous Versions (System Restore + Shadow Copy). macOS has Time Machine if it's been running. Linux has whatever backup system is configured.
If the previous content existed when the last system snapshot was taken, you can recover it from the snapshot. This is slower than version control or editor history but works when those don't.
Step five: reconstruct from context
If none of the previous steps recover the file, you have to reconstruct from what you remember and what's still visible elsewhere.
Other files that imported from or called into the overwritten file constrain what the overwritten file used to do (function signatures, expected behavior).
Tests that ran against the overwritten file describe what it was supposed to produce.
Documentation, comments in other places, design notes, or specifications give you the intent of the file even if the implementation is lost.
This recovery is real work and usually produces a version close to but not identical to what was lost. Accept the imperfection; the alternative is no recovery.
Step six: codify the prevention
Once you've recovered as much as you can, the next move is to ensure this doesn't happen again. The current incident becomes the source material for the discipline that prevents the next one.
The discipline has four parts.
Frequent commits. Commit working code often. The cost of committing is trivial; the benefit is that the worst-case loss is what you've done since the last commit. With commits every 30-60 minutes during active work, the worst case is bounded to a recent window.
Branch-and-checkpoint workflow. When using AI tools, work on a branch separate from your main branch. Create the branch before invoking the AI. Each significant change is a commit on the branch. If the AI overwrites something, you can recover from the branch's commit history or discard the branch entirely without affecting main.
Protected paths configuration. Some files should never be touched by AI tools. Database migrations, deployment configurations, security-sensitive code, anything that's both important and rarely correct to modify. Configure your AI tools to either refuse or warn before touching these files. In Claude Code, this is the --disallowedTools and read-only mount configuration. In Cursor, it's the indexing exclusions.
Pre-commit hook backstops. Pre-commit hooks run before a commit goes through. They can verify that changes to specific files match expectations, that no protected patterns are introduced, that certain invariants are preserved. The hook is a mechanical layer that catches what other discipline missed. The same pattern is documented in the gate that caught us where a pre-commit hook caught a vendor-name violation mid-promotion, and in the nav that almost wasn't where the same kind of gate caught a different class of failure.
How the discipline plays out
In practice on my own work: every AI-tool session starts with git checkout -b ai-session-{date}. The branch is the workspace where the AI can make changes. Frequent commits during the session create rollback points. Protected paths configured at the tool level prevent the AI from touching critical files. Pre-commit hooks verify that the changes pass codified gates before they leave the working tree.
When something goes wrong, the rollback path is clear: discard the branch, start over from main. The cost of being wrong is bounded. The discipline takes maybe 30 seconds at the start of each session and prevents hours of recovery work when something inevitable goes wrong.
The pattern repeats across the rescue cluster: small upfront discipline prevents large downstream pain. The cases where the discipline isn't installed are the cases that produce the rescue work. The cases where it is installed produce recoverable surprises instead of catastrophes.
What this means for the immediate situation
If you've just been overwritten and recovered (or partially recovered), the first thing to do after the recovery is install the discipline above. The next overwrite is coming; the only question is whether it'll be recoverable cleanly or whether you'll be back in the recovery position you just escaped.
Investing the 30 minutes to set up branching, frequent commits, protected paths, and pre-commit hooks is the highest-leverage move available right now. It pays back the next time the AI does something unexpected, which will be soon.
The discipline doesn't slow down your work meaningfully. It transforms catastrophic-loss-risk into bounded-rollback-cost, which is the transformation that makes AI tools genuinely usable.
If you've been hit by an AI overwrite and want help recovering or installing the prevention discipline, send the repo state, what was lost, and your current workflow. VibeKoded can scope a rescue diagnostic, stabilization sprint, or rebuild plan. → Work with VibeKoded