Why did the AI delete my comments? Why did it refactor that unrelated function? We analyze the
What a Ghost Edit Actually Is
A ghost edit is a change the model made that you never requested. You asked for a bug fix and comments vanished. You asked for a new helper and an unrelated function got refactored. You asked for a one-line tweak and the model “cleaned up” naming, reordered imports, or rewrote control flow two files away. The result is a diff that mixes the work you wanted with work you did not approve.
These edits are easy to miss because they often look plausible. A deleted comment may seem harmless. A slightly tighter function may even look better. The damage shows up later: lost intent, harder reviews, and regressions in code paths you thought were untouched.
Ghost edits usually come from how assistants optimize. They are trained to produce complete-looking solutions, not minimal patches. Vague prompts invite broad rewrites. Large context windows surface distant code that looks related. Autocomplete and multi-file tools apply suggestions without a hard boundary between “required for the task” and “nice to clean while we’re here.”
How to Spot Them Before They Land
Treat every AI-assisted change as untrusted until you have read the full diff. Do not skim only the lines that match your request. Scan deletions first—comments, guards, dead-looking branches, and tests often disappear because the model decides they are noise. Then check rename and extract moves: if a symbol changed outside the feature you asked for, that is a ghost edit until you prove otherwise.
- Run the diff against your original prompt: every hunk should map to an explicit ask or a hard dependency of that ask.
- Prefer smaller scopes—single file, single function, or a named list of symbols—so stray edits have fewer places to hide.
- Re-read comments and TODOs the model touched; if intent was removed without a replacement, restore it before merge.
- Run tests and a quick manual path through adjacent features, not only the happy path you changed.
Contain the Model’s Ambition
Prompt for a patch, not a redesign. State what must not change: public APIs, comments that encode policy, error messages, and neighboring helpers. Ask for the smallest diff that solves the problem, and require the model to list out-of-scope ideas instead of applying them. If you use multi-file agents, start with read-only exploration, then approve write targets by path.
When a ghost edit already landed, reverse the process. Isolate the requested change on a clean branch or stash, discard the rest, and re-apply only what you need. If you must keep part of an opportunistic refactor, pull it into a separate commit with its own rationale so review stays honest. Over time, keep a short personal checklist of the ghost patterns you see most—deleted comments, silent renames, “helpful” null checks—and run that checklist before every AI-authored commit.
Make Human Ownership Explicit
AI is a drafting tool; you own the merge. A useful habit is to accept only changes you could defend in a review without saying “the model did that.” If you cannot explain why a line moved or a comment vanished, put it back. That standard keeps the codebase’s history readable and stops ghost edits from becoming the default way work lands.
Debugging the ghost edit is less about catching a clever bug and more about tightening the contract between prompt, scope, and review. Ask for less surface area, inspect more of the diff, and refuse polish you did not request. The code that remains is then yours on purpose—not the model’s side quest.