Plan first, execute second: the 80/20 rule for letting AI tackle big tasks

Overview

When you hand a capable AI a big task, the tempting move is to let it start working immediately. This module is about the discipline of refusing that — making the model produce a plan, and approving it, before it touches anything.

Why now. Through late 2025 and into 2026, Anthropic’s own Claude Code guidance hardened around a four-phase loop — explore, plan, implement, commit — built on a read-only “Plan mode” — the docs describe it as telling Claude to “research and propose changes without making them”, and nothing executes until you approve. 2026 releases wired the gate in deeper: an approved plan can now hand straight off to auto mode (March 2026) or run against a /goal completion condition (May 2026). The guidance grew up around coding agents — where a wrong approach compounds fastest — but the discipline ports cleanly to documents, analyses, anything big. The current best-practices page gives the order its own section — “Explore first, then plan, then code” — and the reason it gives is the notable part: “Letting Claude jump straight to coding can produce code that solves the wrong problem.”

What you’ll be able to do. Insert a human-approval-of-plan gate into any large AI task, and know the one case where adding it just wastes your time.

The content

The obvious read is that planning is overhead — a delay between you and the output. Overturn it: the plan is the cheapest place to be wrong. A flawed plan costs you a paragraph of reading. A flawed implementation costs you a review of everything the model already built on top of it, plus the work of unwinding it. That gap — words you can skim versus work you have to unwind — is the whole reason Anthropic’s guidance puts research and planning before execution.

That is the whole case for the plan gate: the model writes out what it intends to do, and nothing executes until you have read it and said yes. The gate is doing one specific job — catching a wrong approach while it is still just words. It is distinct from splitting a task into steps, and distinct from checking in partway through. It happens once, up front, before any work exists.

Practitioners often frame the leverage as an 80/20 split — most of your attention goes into getting the plan right, a little into supervising the build. Treat that as a directional rule, not a measured law; the real point is that effort spent before execution is worth far more than effort spent after. What makes a plan worth reviewing is the same thing Anthropic asks of a good spec: it should name the documents, files or sections it will touch, state what is out of scope, and end with a way to verify the result.

Now the limit, because it is the most credible thing here. The plan gate is overhead, and on small work the overhead costs more than it saves. Anthropic’s own guidance is blunt: if you can describe the finished change in one sentence, skip the plan. Forcing a plan onto a typo fix or a one-line rename is ceremony. The gate earns its keep when the approach is genuinely uncertain, when the change spans several files, or when you do not know the territory well enough to spot a bad plan from the output alone.

Try it

Use this on a real task you would otherwise have handed off in one shot — a multi-file change, a document restructure, an analysis across several sources. The point is to force the gate before any work happens.

Before you do any of the actual work, produce a plan only — do not start.

Task: [paste your real task here]

Your plan must include:
- The approach, in plain language, and why you chose it over alternatives
- Every file / section / artefact you intend to create or change
- What is explicitly OUT of scope
- The assumptions you're making that, if wrong, would change the plan
- How I'll be able to verify the result is correct

Stop after the plan. I will review and approve (or correct) it before you
execute. Do not begin until I reply "approved".

Where it breaks: do not use this on small, obvious work. If you can describe the finished change in one sentence, the plan gate is pure ceremony — just ask for the change directly and review the result.

Additional reading

• Best practices for Claude Code — Explore first, then plan, then code — the four-phase explore/plan/implement/commit workflow, the “solves the wrong problem” warning, and the “describe the diff in one sentence, skip the plan” rule.
• Permission modes — Claude Code docs — Plan mode as a read-only state: Claude researches and proposes changes without making them; nothing runs until approved.
• Auto mode — Claude Code blog (March 2026) — the other half of the gate: once a plan is approved, execution can run autonomously. The approval is the control point.
• What Actually Is Claude Code’s Plan Mode? — Armin Ronacher (Dec 2025) — a practitioner’s sceptical take: the value is having a plan you can read, review and edit before acting, more than the mode itself.

Editor’s note

Plan mode is my default for any substantial agent work now. The plan is where you catch the model solving the wrong problem, while the fix still costs nothing. For example, this site’s spec was corrected several times before a line of code existed; any one of those corrections would have been a rebuild if it had surfaced later. Read the plan for the assumption it didn’t flag and the scope it quietly widened. Plan anything that spans files or judgement; just ask for small changes directly.