Preemptive Plan Review

A plan before execution is the cheapest deliverable to fix.

Problem

An agent starts building as soon as it receives instructions. Even when there's a mismatch in understanding, it usually only surfaces once the deliverable is complete. By then, a large amount of work has already been piled on top of the mismatched premise. Fixing it isn't just fixing the mismatched part — the judgments stacked on top of it collapse along with it. The later a mismatch is caught, the more there is to throw away.

Context

Applies when:

• Redoing the work is expensive — work where a redo costs real time and money
• The instruction is abstract, and there are multiple valid ways to proceed
• The human's intent wasn't fully put into words at the time the instruction was written — the plan becomes a way to see "how the agent understood it"

Does not apply when:

• Redoing the work is cheap. The cost of reading a plan exceeds the cost of a redo
• The plan is obvious. An unambiguous one-file fix doesn't need a round trip on a plan
• Exploration itself is the goal. If the job is to find out what should be done, no plan can exist before that finding is done

Boundary with neighboring patterns:

• Diff Review and Incremental Adoption — the time axis differs. That pattern is how to receive what already came out; this pattern is how to intervene before it comes out. Both are human checkpoints — they just sit at different points
• Making the Verification Target Explicit — this pattern verifies the plan before the work happens; that pattern decides what to verify after it happens
• Matching Thinking Depth to the Task — Official (VS Code) recommends a reasoning model for planning and a fast model for implementation (source: in Practice section). The phase split this pattern draws is one reason to change depth
• Read-and-Discard Isolation — the investigation needed to build a plan can itself be isolated. What comes back to the main context is the plan

Solution

Why this works. Two reasons.

First, the asymmetry of correction cost. For the same mismatch, the cost of fixing it depends heavily on when it's caught. A mismatch at the planning stage costs a rewrite of text. A mismatch caught after implementation costs a code rewrite, and the judgments stacked on top of it collapse along with it.

Placing the same check at an earlier point alone lowers the cost. This isn't specific to agents — human design review exists for the same reason.

That said, the effect is larger with agents. Agents move fast, so if left unchecked, the amount of work stacked on a mismatched premise grows far larger than it would for a human.

Second, a plan is "understanding made visible." Human instructions are ambiguous almost without exception, and the human side usually doesn't notice their own instruction was ambiguous until seeing the resulting deliverable. A plan presents, in short form, what the agent took the instruction to mean and how. A mismatch found here is, in most cases, not the agent's error but a hole in the instruction.

So this pattern's payoff isn't only correcting the agent's course. It's also finding the holes in one's own instructions, cheaply.

The staircase in the figure isn't a continuous slope — it's a jump at each stage boundary crossed. Moving the boundary one stage earlier alone drops the price paid by one step. The "preemptive" in this pattern's name means choosing the lowest step among these jumps to intervene at, not introducing verification that wasn't there before.

Trade-offs

Advantages

• A redo can be fixed at its cheapest point. As the staircase in the figure shows, the same fix costs more the further along the process it's caught. What gets thrown away at the planning stage is, at most, a few hundred words of text.
• Ambiguity in the instruction becomes visible. Most mismatches surface not as the agent's error but as a hole in the instruction. This payoff holds even though the plan was written by the agent — it's the human who notices it.

Costs

• Reading the plan takes time. For small work, it's faster to just let it build and throw it away than to read a plan. Each round trip needs a human's hand, so cutting things into too many small pieces turns this pattern itself into a source of rework.
• A plan looking right and the execution being right are different things. Approving a reasonable plan doesn't guarantee the implementation follows it — the same way instruction compliance only works non-deterministically. Approval is not a guarantee. Verifying the plan is no reason to skip verifying after execution.

GitHub Copilot in Practice

Copilot isn't a single product. As far as this catalogue could confirm in the primary sources, the equivalent of this practice shows up as a feature in Copilot CLI and as operational advice in VS Code. Don't lump this together as "Copilot has plan mode."

Copilot CLI — plan mode as a feature

Source: CLI command reference (retrieved 2026-07-16) Official:

--mode=MODE | Set the initial agent mode (choices: interactive, plan, autopilot). Cannot be combined with --autopilot or --plan.

--plan | Start in plan mode. Shorthand for --mode plan. Cannot be combined with --mode or --autopilot.

It can also be switched mid-conversation (source: Running tasks in parallel with the /fleet command, retrieved 2026-07-16) Official:

Press Shift + Tab to switch into plan mode and work with Copilot CLI to create an implementation plan.

Plan mode is a mode for "having the plan come out first," and that alone is only half of this pattern — the agent side's preparation. This pattern is completed only once the human reads that plan and fixes it. There's a path to enter plan mode wholesale at launch (--plan), and also a path to switch into it mid-conversation once the need is noticed (Shift + Tab). Having both a way to decide upfront and a way to switch after noticing mid-task means this pattern's applicability isn't limited to "work known from the start."

Copilot CLI — an adversarial critic on plans, enabled by default

The same CLI has a built-in agent for verifying the plan itself (source: CLI config dir reference, retrieved 2026-07-16) Official:

builtInAgents.rubberDuck | boolean | true | Enable the rubber-duck subagent that provides adversarial feedback on agent plans.

The default is true. Adversarial verification of a plan ships enabled by default in the product. This directly enacts this pattern's core — "verify the plan before executing" — with the verifier swapped from a human to an agent. What this catalogue could confirm is only this setting key's default value; it doesn't go so far as to establish at what point in the conversation this check gets inserted.

VS Code — advice as a practice

What this catalogue could confirm on the VS Code surface is operational advice, not a feature name (source: Optimize your AI usage, retrieved 2026-07-16) Official:

Jumping straight into code generation can lead to wasted effort if the approach is wrong. It also requires a model with enough reasoning capability throughout the process, which can consume more credits. Instead, separate the planning and implementation phases. This allows you to use a reasoning model for planning, and then switch to a faster, more efficient model for implementation once the plan is solidified.

Jumping straight into code generation wastes effort if the approach is wrong — this single line is the exact structure of the loss described in Problem. The proposal here isn't a feature name but a practice — a sequencing discipline of leaving only the planning stage to a reasoning model, then switching to a fast model once the plan is solidified.

Differences across surfaces

Surface	What exists	Status
Copilot CLI	A plan mode feature (--mode=plan / --plan) plus a rubberDuck subagent for adversarial plan verification (enabled by default)	Confirmed as a feature
VS Code	Advice to "separate the planning and implementation phases"	Confirmed as advice

The same aim — handling the plan before execution — shows up as a feature on one surface and as operational advice on the other. Both can be set side by side, but they aren't the same feature. In practice, the CLI lets a human explicitly switch modes, have the plan come out first, and approve before moving to implementation. In VS Code, a reasoning-strong model is chosen only for the planning stage, then swapped for an implementation model once the plan is solidified. The names and the operations differ, but what's being paid for is the same — the decision itself to allocate time and model compute to the planning stage.

Also Known As

Name	Source
Plan mode	Primary — Copilot CLI's official mode name (--mode=plan / --plan; source: in Practice section). But this names the mechanism, not this pattern
Preemptive Plan Review	Descriptive — a descriptive name coined by this catalogue; no primary source uses it

The official docs give a name only up to the mode that produces a plan. The practice of "the human reading the resulting plan and fixing it" has, as far as this catalogue could confirm, no established name. Even after switching into the mode, approving the resulting plan without reading it means this practice isn't happening. The mode is the container; this pattern is how the contents are used (the same structure as the Also Known As section of Failure as Institutional Memory — using the container's name as the practice's name invites the misreading that "having the mode" equals "doing this practice").

Related

• Diff Review and Incremental Adoption — verifying the plan before execution is this pattern; verifying the deliverable after execution is that pattern. Same category of human checkpoint, different point in time
• Making the Verification Target Explicit — this pattern verifies the plan before the work happens; that pattern decides what to verify after it happens
• Matching Thinking Depth to the Task — Official (VS Code) recommends a reasoning model for planning, a fast model for implementation (source: in Practice section). The phase split this pattern draws is one reason to change depth
• Read-and-Discard Isolation — the investigation needed to build a plan can itself be isolated. What comes back to the main context is the plan
• If reading just one more next: Diff Review and Incremental Adoption — having seen intervention before execution, it's next to look at intervention at the receiving end