The AI just wrote nearly 100 lines for you, and only one of them needed to change. You hit ⌘Z once — and watched all 99 lines you actually wanted to keep vanish along with it. If you have used Antigravity for more than a week, that moment has probably already happened to you. It happened to me last week during a TypeScript refactor; the AI couldn't reproduce the exact same code on a second pass and I lost about 20 minutes staring at the screen.
This is not really an Antigravity bug. It is a structural mismatch between how AI-generated edits arrive at the editor and how the classic undo stack was designed. Once you understand the mismatch, you can prevent the disaster about 90 percent of the time, and the remaining 10 percent becomes recoverable rather than catastrophic.
Why a single Cmd+Z can erase so much
VS Code-derived editors group consecutive edits into a single "edit chunk" if they happen close together in time. When you type by hand, the editor breaks groups at sensible points — characters, words, line endings — so ⌘Z rolls things back in small, comfortable steps.
AI-driven edits arrive differently. Antigravity's models push code through the applyEdit API, and a typical pattern is "many edit operations in a very short window," sometimes collapsed into a single replaceFile operation that swaps the entire file contents in one shot. From the editor's point of view, that's indistinguishable from a single user action that happens to span the whole document. So the editor merges them into one undo group.
Press ⌘Z once, and that "one giant group" disappears in its entirety. Whether the group represents 100 lines or 1,000, Antigravity sees it as the user's most recent single action.
The risk is highest in three patterns:
- Asking the AI to "rewrite this whole file"
- Letting a Manager Surface agent edit several files in a single step
- Inline-chat requests that specify a wide range like "rewrite lines 40 to 220"
Whenever you are doing one of these, keep in the back of your mind that undo will not behave as gently as it does when you type by hand.
Three habits that prevent the bulk wipe
These are the three things I do without thinking now. None of them takes more than a minute to make a habit.
1. Draw a line in Git before any AI edit
The most reliable safety net is intentional staging right before you let the AI loose. You do not have to commit — staging alone gives you a recoverable snapshot.
# Run this before asking the AI for a large edit
git add -A
# This becomes your last line of defense if undo wipes too muchIf you use task files (.antigravity/tasks/*.md), drop a line into the prompt: "Before editing, the user has staged the working tree. Make atomic commits per logical change." Some agents respond by self-disciplining their commit granularity.
2. Lean on Manager Surface checkpoints
Whenever a Manager Surface agent edits files, Antigravity automatically inserts a checkpoint marker — the small flag icon you see next to each step in the agent timeline. Instead of hitting ⌘Z, click "Restore to this point" on the relevant checkpoint.
Checkpoints work at the granularity of an agent step, not an editor edit group. That means you can roll back exactly the change you regret without sacrificing surrounding work. Personally, even when I plan to use inline editing, I now prefer to invoke the agent once via Manager Surface first, just to anchor a checkpoint.
3. Don't let the AI do everything in one pass
Asking "rewrite this entire file" feels efficient but is fragile. Splitting the work into smaller logical units — "first refactor function A," then "function B," then "the tests" — keeps undo groups small and gives you finer-grained safety.
It also tends to produce better code. Generating 200 lines in a single shot dilutes the model's attention and frequently sacrifices small details. Breaking the request into 30–50 line slices generally yields tighter results, and your undo history mirrors the same shape. It feels slower in the moment; in my experience, it ends the day faster.
Make the undo stack itself a little finer
You can also tweak the editor's undo behavior. Open Settings → Editor and change Editor: Undo Stop Granularity (the underlying setting may be editor.undo.granularity on your build) to lineByLine or paragraph.
// settings.json — finer-grained undo for human typing
{
"editor.undo.granularity": "lineByLine",
"editor.undo.maxStackSize": 1000
}This setting only affects edits you make by hand. It does not split the single, massive operation that the AI submits via the API. The mental model worth keeping is: "what I typed gets reversed in fine slices; what the AI wrote is still one block."
Bumping maxStackSize higher means long sessions retain more history, which makes the recovery techniques below more reliable. On a workstation with comfortable memory I push it to 2,000.
Recovering when undo has already wiped you out
Even with these habits, accidents happen. Knowing the recovery path in advance keeps the panic short.
Try ⌘⇧Z (Redo) first. It sounds obvious, but if you act before doing anything else, redo is instant. The catch: any other edit will clear the redo stack. The moment ⌘Z wipes too much, freeze your hands and think before you type.
If redo is gone, the next stop is VS Code's Local History. Open the command palette with ⌘⇧P and run Local History: Find Entry to Restore. Antigravity inherits this feature, so per-file snapshots from before and after AI edits are usually still on disk.
# Local history location on macOS
~/Library/Application\ Support/Antigravity/User/HistoryA targeted grep -r "the function name you lost" ~/Library/Application\ Support/Antigravity/User/History/ can fish out the exact snapshot you need. I once recovered 80 lines of test code this way after thinking they were gone for good.
The last resort is the agent log itself. Manager Surface keeps the AI's full conversation history, including the code it generated. Ask the agent something like "Re-emit the code from your previous response, code block only," and you can usually retrieve the same content. Editor undo and agent history are stored separately, so the chat history survives even when the buffer does not.
Editing alongside AI is its own discipline
Putting it all together, here is the working rhythm I have settled into. Before any large agent task, run git add -A. Prefer Manager Surface agents over raw inline edits so that checkpoints exist by default. Cap each request at 30–50 lines and split larger refactors into explicit steps. Within a few minutes of every AI edit, drop a git commit -m "wip: ai-edit" and reshape the history later with git rebase -i.
If you want to dig further into how agents lose code or context, Antigravity Agent Code-Changes-Not-Applied Diagnostic Guide and Antigravity Codebase Context Diagnosis Guide cover related failure modes well. For a deeper look at retry behavior, see Mastering Antigravity's Smart Retry.
A short field guide to "what kind of AI edit is this?"
Not every AI request creates the same undo risk. Over the past few months I have started silently labeling each request before I press send, which has cut my recovery sessions almost to zero.
Inline single-line completions are essentially harmless: undo behaves normally because the editor sees one keystroke-equivalent edit. Inline range edits — when you select 30 lines and ask for a refactor — start to merge into larger groups, but they are still survivable with one or two ⌘Z presses. Whole-file rewrites and multi-file agent runs are the dangerous categories; treat them as you would treat a database migration, with a Git snapshot first.
A useful internal heuristic: if the edit will touch more than the screen's visible area, take the extra five seconds to stage. The cost of staging is rounding error compared to the cost of explaining to your future self why a working test file disappeared.
When a teammate hits this, what to share
If you maintain a team using Antigravity, paste a short note in your shared playbook. The framing matters more than the specifics: present this as an editor-model issue, not as someone's mistake. People stop reporting near-misses if they feel embarrassed, and the same accidental ⌘Z will keep happening to someone else next week. A culture that accepts "AI edits behave differently from typing" is a culture that recovers fast.
Pick one habit for today
Don't try to adopt all of these at once. Just lock in git add -A before every large AI edit, starting today. That single move removes about 80 percent of the felt cost of an accidental ⌘Z. Once it is automatic, layer in Manager Surface checkpoints, then the smaller-step request pattern. Move at your own rhythm.
Coding alongside AI is a slow rebuild of how we think about the editor itself. Take it gently — we are still all learning together.