Instead of approving a Planning-mode plan wholesale, cut the one risky step and keep the rest. A field-tested look at partial plan editing from a solo developer's desk.
Late one night I was about to swap out the store descriptions for one of my four apps in a single pass.
I asked Antigravity to lay out the work in Planning mode, and it returned a tidy seven-step plan. Most of it was exactly right. But step five quietly slipped in a line: "for consistency, also update the billing configuration files." I never asked for that.
Throwing the whole thing back with "start over" would have been wasteful. The other six steps were accurate and matched my intent. What I needed was to remove step five alone — to prune that single move before approving the plan. This small gesture prevents a surprising share of agent mishaps.
Why edit, not regenerate
A Planning-mode plan is something the agent assembled after reading your context. Usually eighty percent of it is correct. The trouble is the remaining twenty percent, where a move into territory you wanted left alone tends to hide.
Leaning on a re-prompt here means rebuilding the eighty percent that was already right. There is no guarantee the next plan is better. More often, it repeats the same misunderstanding in a different shape.
Partial editing exploits that asymmetry. You lock in the correct part and surgically remove only the risky step. When you're an indie developer running several repositories solo, review time is finite. Spotting and cutting one dangerous move is far faster — and safer — than re-reading an entire plan.
It helps to frame the decision as a choice between three actions: approve, edit, or reject.
Situation
Action
Why
Every step matches intent
Approve
No editing needed; go straight to execution
Mostly right, one stray move
Partial edit
Keep the good part, remove the risky step
The premise itself is wrong
Reject and re-brief
If the foundation is off, rebuilding is faster
The tiebreaker is simple: are you fixing a step or a premise? A step means edit; a premise means reject. In the store-description case the premise was sound and one step was extra, so editing was the right call.
Spotting the move to cut
When I scan a plan, my eyes go first to three kinds of steps. These are where a stray move likes to hide.
The first kind touches an area you want protected — payment configuration, the AdMob setup, production redirect rules, anything around authentication, places where breakage spreads in ways that are hard to predict. When a step is prefaced with "for consistency" or "just to be safe," I watch it especially closely.
The second kind is hard to undo: bulk file deletion, a push to a remote, a deploy to production. When one of these sits casually in the middle of a plan, stopping it after execution starts is difficult.
The third kind bundles in an unrelated change — the "while we're here, let's also refactor" line. The intent is kind, but it coarsens your review granularity all at once and makes the diff hard to follow later.
Find a step that fits any of the three, and cut it on the spot. That alone heads off most of what gets called an agent going rogue.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦When to surgically edit a plan instead of regenerating it from scratch
✦Three concrete edits — delete, reorder, and constrain — with exact steps
✦Why a deleted step comes back during execution, and how to keep it gone
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
In practice, partial editing comes in three shapes. Let's walk through them.
Delete
The most basic move. You literally remove a step. Antigravity presents the plan as editable text, so you select the line and delete it.
But deletion alone is sometimes not enough. For reasons I'll cover below, it pays to add a one-line note about why you cut it. Rather than just erasing step five, rewrite it:
Before:5. For consistency, also update labels in pricing.tsAfter (stated as a negative constraint):Note: pricing.ts and payment-related files are out of scope.Do not modify them.
Convert the step from "do this" into "do not touch this." That little bit of extra effort is what holds.
Reorder
Plenty of plans park the verification step at the very end. But the riskier the change, the earlier you want to verify.
If the order reads "rewrite all files, then build and check at the end," reorder it to "rewrite one file, build and check, then rewrite the rest." If the approach is wrong, the damage stops at one file.
Reordering is easier to overlook than deletion, but on plans that contain irreversible operations it is a high-leverage edit.
Constrain
Here you add a constraint at the top of the plan that applies to the whole run. Rather than touching an individual step, you declare a guardrail over the entire execution.
While executing this plan, strictly observe:- Only files under content/ may be changed- Do not touch src/config/ at all- Report the list of changed files after each step
Declaring this once at the top tends to raise the agent's compliance more than scattering notes across individual steps. In particular, writing the allowed scope as an allowlist leaves fewer gaps than enumerating files to protect, and it fails toward the safe side.
The deleted step that comes back
This is where partial editing trips people up most.
Even after you cut step five, the agent may decide mid-run that it is "needed for consistency" and quietly add the deleted work back. A plan is, after all, a plan — not a contract that binds execution.
The defense is the "convert to a negative" trick from earlier. Instead of erasing the step, leave it behind as a constraint: "pricing.ts must not be changed." You replace the blank with an explicit prohibition. An agent will try to fill a blank, but it will not fill a stated prohibition.
When the run finishes, always confirm with the diff.
# List only the files that changedgit status --porcelain# Check that no protected paths slipped ingit status --porcelain | grep -E 'pricing|config|checkout' || echo "No changes to protected paths"
If grep returns nothing and you see "No changes to protected paths," the deleted step stayed deleted. If something is caught, revert that change and revisit how you wrote the constraint.
In my own routine, the days I skipped this diff check were precisely the days an extra change crept in. I think the relief of having edited the plan is what tempts you to skip the final look. I try to treat editing and verification as a single pair.
So you stop cutting the same step twice
If you find yourself deleting the same payment-related move from every plan, that is the signal to promote it into a project rule.
Antigravity lets you record constraints you want applied repeatedly in a project rules file such as AGENTS.md. Write "do not modify src/config/ unless explicitly instructed" once, and Planning mode will build plans with that constraint already in mind. A manual deletion turns into a premise of the design.
That said, ruling out everything makes plans rigid in turn. I run a loose threshold: if I cut the same step three times, it moves to AGENTS.md. In-the-moment judgment and a permanent rule — keeping those two layers distinct quietly lowers the review burden over time.
After running this habit for about two weeks, one thing changed clearly. The number of times I rejected a plan outright and typed "start over" dropped by more than half. I used to throw back the whole thing over even ten percent of unease; now I lift out the one stray move and keep the rest. It feels less like restarting from zero each time and more like growing the plan the agent handed me into something usable.
Your next step
Before you approve today's plan, pause once. "Is there a step in here that wanders into territory I wanted protected?" If there is, don't erase it — rewrite it as a "must not change" constraint. Then check your answer after the run with git status --porcelain.
Once that small habit sets in, the range of work you can comfortably hand to an agent widens on its own. Thank you for reading.
Share
Thank You for Reading
Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.