Plan first, execute second

Wrong direction is the most expensive outcome available in agentic work, because you pay for it twice: once producing the wrong thing and again undoing it. Everything else is cheaper than that, including the planning pass people skip to save time.

Why the plan is disproportionately cheap

In the workflows measured on this site, planning is a small share of the tokens and governs the rest. In a multi-file refactor it is around seven per cent of the input and every subsequent step executes it. See the refactor workflow for the numbers.

That asymmetry is the whole argument. A cheap step that determines an expensive one deserves attention out of proportion to its cost.

What to ask for

Not a plan in the abstract. A plan you can disagree with:

Before changing anything: read the relevant code, then tell me the approach, which files change, what you are deliberately not doing, and what could go wrong. Stop there.

Four elements, and the third and fourth do the work. "What you are deliberately not doing" surfaces scope assumptions before they become commits. "What could go wrong" surfaces the assumption you would otherwise discover at step nine.

Then actually stop

The gate only functions if you use it. A plan produced and immediately acted on in the same turn is a narration, not a checkpoint.

Read it against your own understanding of the codebase. The failure worth catching here is the plan that is internally coherent and built on a wrong premise, which reads perfectly well and is the most expensive kind to discover later.

Approve, redirect, or narrow

Three useful responses:

Approve when the approach matches and the scope is right.

Redirect when the approach is wrong. Cheap now; the same correction after implementation costs the implementation.

Narrow when the plan is broader than you wanted. The most common of the three and the one people forget they can do. "Do step one only, then stop" is a complete instruction.

Keep the plan out of the conversation

For anything beyond a few steps, have it written to a file. A plan that exists only in the conversation degrades as the context fills, which is precisely when a long execution needs it most.

It also gives you something to check the final diff against. See Verifying before done for what that check looks like.

When to skip it

Be honest rather than ceremonial. A single-file change with an obvious approach does not need a planning round, and demanding one teaches you to skip the gate when it matters.

The threshold worth using: if you cannot predict which files will change, plan first. That uncertainty is exactly what the plan resolves.

What goes wrong

Asking for a plan and letting it continue. The gate exists at the stop.

Plans with no out-of-scope section. Scope then has no boundary to cross.

Approving a plan you skimmed. A coherent plan on a wrong premise is the expensive case, and skimming is how it passes.

Improvising when a step turns out wrong. Stop and revise the plan. Working around it is how a three-file change becomes a nine-file change nobody agreed to.

Planning everything. Ceremony on trivial tasks devalues the gate.

How to check it worked

Compare the final diff against the plan's own scope section. Files outside it are the finding, and they are the thing no summary will volunteer.