The AI deleted code that was working
Any AI coding tool Last checked 2026-10-14
Nothing deleted your code on purpose. The model rewrote a file from its own partial view of it, and anything it had not read — or had forgotten — simply did not appear in the new version. Recover with git, then stop whole-file rewrites: demand diffs, not replacements.
What you saw
A feature that worked yesterday is gone. Not broken — absent. The function, the route, the error handling, the edge case you added last week.
Often it follows an unrelated request: you asked for a styling change and lost validation logic in the same file.
What it actually means
When an agent emits a whole file instead of a targeted edit, it is reconstructing the file from context. Anything outside that context is dropped silently — it is not a deletion, it is an omission.
The common triggers:
- Failed targeted edits. Two or three failed string matches and the agent falls back to "let me just rewrite the file." That fallback is where code dies.
- Context eviction. In a long session the earlier read of the file has been compacted away, so the agent is working from a summary of the file rather than the file.
- Truncation. The rewrite was cut off at the token limit and whatever came after is gone.
- Over-eager cleanup. You said "clean this up" or "simplify" and it removed code it judged unused — including things only referenced dynamically, from tests, or from another package.
The fix
Recover first, diagnose second. If it was committed:
git diff HEAD -- path/to/file
git checkout HEAD -- path/to/file
If it was never committed, your editor's local history usually still has it. In VS Code / Cursor: right-click the file → Local History (or Timeline in the Explorer panel). This has saved more work than any other single step here.
Do not ask the agent to "put it back." It will reconstruct from the same incomplete context and you will get a plausible-looking imitation of the lost code. Restore from git or local history.
Then ban the rewrite behaviour for the rest of the session:
Never replace a whole file. Make targeted edits only. If a targeted edit fails twice, stop and tell me — do not rewrite the file.
Before accepting any large diff, read the deletion count, not the additions. A change described as "refactor" that removes 80 lines and adds 20 is the shape of this failure.
How to stop it happening again
Commit before every agent task. Not at the end of the day — before each task. A clean tree makes git diff a complete and instant audit of what the agent did.
Work on a branch per task so an abandoned attempt costs you nothing.
Keep files small. A 1,200-line file invites whole-file rewrites; a 150-line one rarely does.
Add the rule to your project rules file (CLAUDE.md, .cursor/rules/, AGENTS.md) so it applies on every run without you retyping it.
Be specific about scope in the request itself: "change only the button styles in this file; do not touch anything else" materially reduces collateral edits.
Related questions
Can I get the code back if I never committed it and local history is empty?
Sometimes — check your editor's undo stack if the file is still open, and any build artefacts in dist/ or .next/ that were produced from the old version. Otherwise it is gone. This is the argument for committing before every task.
Why does it delete things when I asked for something unrelated?
Because the unit of change was the whole file, not your request. Once a file is being regenerated, everything in it is at risk regardless of what you asked for.
Does a bigger context window fix this?
It reduces it, it does not remove it. Long sessions still compact, and truncation during generation is independent of input size. Targeted edits and git discipline are the actual fix.