How to Review an AI Agent Plan Before It Runs

Two plans for the same task. The first says: "I'll refactor the authentication module to use the new session helper." The second says: "I'll change 6 files under src/auth/, replacing getSession() with resolveSession(). No database migrations. No changes to token expiry. src/auth/legacy.ts has two callers I will leave alone. Rollback is reverting one commit." Both plans describe the same work. Only one of them can be reviewed. Knowing how to review an AI agent plan before it runs is mostly the skill of noticing which of those two you have been handed, and refusing to approve the first.

Why the plan is the cheapest place to intervene

Reviewing generated code after the fact is real work: you are reading a diff of unfamiliar changes with no memory of the intent behind each one. Reviewing a plan takes thirty seconds and happens before any of it exists.

The economics are lopsided enough to be worth stating plainly. A bad plan caught at review costs you one rewritten sentence. The same bad plan caught after execution costs a revert, a re-run, and whatever the agent touched that you did not notice. This is a different activity from reviewing AI-generated code before you ship it, and it does not replace it. It reduces how often you have to do it badly.

The five things a plan must name

A reviewable plan answers five questions. If any answer is missing, the correct response is to send it back rather than approve and watch.

1. Blast radius. Which files and directories will change, and roughly how many. "The auth module" is not a blast radius. src/auth/*.ts, 6 files is. The number matters as much as the paths: a plan that says 6 files and then touches 40 has diverged in a way you can detect immediately.

2. Irreversible operations. Database migrations, deletions, anything that writes outside the repository, anything that calls a third-party API with side effects. These deserve to be listed separately from ordinary edits, because they are the operations where "just revert it" stops being true.

3. Secrets and credentials. Whether the work involves reading environment variables, config files, or anything under a .env. An agent that needs to touch credentials to do the job is not automatically wrong, but you want to have decided that on purpose.

4. What it will not do. The most underrated line in any plan. Explicit non-goals prevent the most common failure, which is not the agent doing the task badly but the agent doing the task plus four adjacent improvements nobody asked for.

5. The rollback. One sentence describing how to undo it. If the honest answer is "revert the commit", say so. If the honest answer involves a migration that cannot be reversed, that is exactly the thing you needed to know before approving.

Two plans worth rejecting, and why

Plan A. "I'll update the dependencies to fix the vulnerability warnings, then run the tests and fix anything that breaks."

The problem is not the goal, it is that the plan has no bounded scope. "Fix anything that breaks" is an open-ended mandate across the entire codebase, and dependency upgrades are precisely where an agent's changes stop being reviewable, because a legitimate fix for a breaking API change is indistinguishable at a glance from a workaround that disables a check. The rewrite: name the specific packages, cap the work at those packages plus their direct call sites, and require that any test change be listed separately for review rather than made silently.

Plan B. "I'll add the new orders table and update the models to match, then backfill existing records."

Two irreversible operations sit inside that sentence and neither is flagged. Creating a table is fine. Backfilling existing records is a write across production data that no revert undoes. The rewrite: separate the schema change from the backfill entirely, make the backfill its own reviewed step with a stated row count, and require it to be idempotent so a partial run can be repeated safely.

The common thread is that neither plan is dishonest. Both are the sort of summary a competent engineer writes to a colleague. They fail as plans because the agent is not a colleague who will stop and ask when something looks odd.

How to review an AI agent plan before it runs, in order

A practical review pass, in the order that finds problems fastest:

1. Read the file list first, not the prose. Unexpected paths are the highest-signal warning available. A plan about the checkout flow that touches src/auth/ has misunderstood something.

2. Count the steps. More than about eight and the plan is really several tasks. Split it. Long plans drift, and the drift compounds because each step builds on the last.

3. Search for irreversible verbs. Delete, drop, migrate, rename, publish, deploy, send. Each one should be flagged in the plan or removed from it.

4. Check the plan solves your problem. Agents reliably produce excellent plans for adjacent tasks. This is the failure that gets approved most often, because a coherent plan reads as a correct plan.

5. Look for what is missing. Does it mention tests? Does it mention the one place in your codebase this always breaks? Absence is harder to spot than error, which is why it is worth checking last, deliberately.

Set the conditions before you ask for the plan

Plan quality is largely determined by what the agent knows before it starts. Three things raise it more than any review technique.

Give it the project conventions in a file it reads automatically, which is what an AGENTS.md file exists for. An agent that already knows your migration policy will write plans that respect it.

Ask for the plan in a fixed shape. If you always want files, non-goals, irreversible steps and rollback, say so once in the project instructions rather than re-asking each time. A consistent format makes deviations visible at a glance.

Run the work somewhere isolated. Reviewing a plan is much less stressful when the execution cannot touch your working tree. A separate git worktree gives the agent a real checkout on its own branch without disturbing what you have open, which turns "approve and hope" into "approve and inspect the branch".

When approving without a careful read is fine

Not every task needs this. Reviewing the plan for a one-line copy change is theatre, and treating every task as high-stakes trains you to skim, which is worse than not reviewing at all.

Scale the scrutiny to the blast radius:

The bottom row is worth taking literally. If a plan involves an operation you would want to watch, the answer is not a better review, it is doing that step by hand.

What to do when execution diverges from the plan

Approval is not the end of the review. The most useful habit is checking the plan against what actually happened before you read the diff in detail: if the agent said 6 files and changed 21, that gap is the finding, regardless of whether the code looks reasonable.

Divergence is not automatically wrong, because an agent that discovers a genuine dependency mid-task should follow it. It is a signal that the task was underspecified, and the productive response is to tighten the plan and re-run rather than to review 21 files of changes you did not sanction. When it has already gone further than you wanted, rolling back a bad agent change is a cleaner recovery than trying to unpick it by hand.

Frequently asked questions

Is reviewing the plan enough on its own?

No. Plan review reduces how often you get a bad diff, it does not verify the diff you get. Both checks are needed, and the plan review is the cheaper of the two, which is the argument for doing it consistently rather than for skipping the other one. What you check the diff against matters too: how to write acceptance criteria for an AI coding agent covers the definition of done that turns a diff review into a real check rather than a skim.

What if the agent does not produce a plan by default?

Ask for one before execution and state the format you want: files, steps, irreversible operations, non-goals and rollback. Most agents will comply with a standing instruction in the project configuration, which is more reliable than remembering to ask each time.

How long should a plan be?

Long enough to name files and non-goals, short enough to read in under a minute. Roughly eight steps is a natural ceiling. Beyond that the task should be split, because a long plan is a prediction over a longer horizon and predictions degrade.

Should I let an agent execute a plan unattended?

Only when the blast radius is bounded and the work is reversible, which in practice means an isolated branch or worktree and no irreversible operations in the plan. Where that is not possible, containment matters more than review, and sandboxing the agent is the mechanism.

Does plan review slow things down?

Marginally per task and substantially less in aggregate, because the time it costs is measured in seconds while the failures it prevents are measured in reverts. It also tends to stop the specific annoyance of an agent changing code you did not ask it to touch, which is a scope problem that a non-goals line fixes directly. For the wider landscape, see AI coding tools.