Method vs. Mode: ADD and Claude Code's Plan Mode

There is a question I keep seeing, phrased a dozen ways: should I use ADD, or should I just use Claude Code’s Plan Mode? It sounds like a fair comparison — two ways to make an AI coding agent slow down and think before it writes. But the question has a hidden flaw. It compares a methodology to a mode: a project-spanning discipline against a single-session toggle. Asking which to use is a little like asking whether you should adopt test-driven development or turn on your editor’s “preview the diff” button. They are not on the same axis, and choosing between them is a category error.

This piece takes both seriously, names what they actually are, and then makes the case that the useful relationship between them is not rivalry but composition. By the end the question reshapes itself: not ADD or Plan Mode, but which layer does this task need — and, more often than people expect, both.

The instinct they share

Start with what unites them, because it is the more important half of the story.

Both ADD and Plan Mode are answers to the same failure mode: an agent that, handed a vague prompt, starts editing immediately and confidently in the wrong direction. The marginal cost of writing code with a capable model has fallen close to zero, and when generation is that cheap, the expensive mistakes move upstream — to building the wrong thing, fast, and discovering it only after the diff is large enough to be painful to unwind. Both tools attack this by inserting a deliberate pause between intent and mutation. Fix the direction before you let the agent build.

That shared instinct is why they feel comparable. It is also why, once you see that they operate at different altitudes, they stop competing and start stacking. The instinct is the same; the scale at which each one applies it is not.

What Plan Mode actually is

Plan Mode is a feature of the Claude Code harness — a session-level operating mode you toggle on (Shift+Tab cycles the input modes). While it is active, the harness withholds its mutating tools: Claude can read files, search the codebase, and reason, but it cannot edit, write, or run state-changing commands. The agent is mechanically constrained to look, not touch.

The loop is short and entirely in-session:

1. You describe a task and enter Plan Mode.
2. Claude investigates — reads the relevant files, traces the code — and drafts a plan in prose.
3. It presents that plan for your approval (the ExitPlanMode step).
4. You approve, and only then does Claude leave the read-only mode and begin making changes. Or you reject, and it re-plans.

Three properties define it. It is mechanical — the read-only restriction is enforced by the tool, not by the agent’s good intentions; an agent under pressure to “just fix it” cannot edit while the mode is on. It is ephemeral — the plan lives in the conversation; close the session and it is gone unless you saved it somewhere yourself. And it is single-turn in scope — it governs the stretch between “here is a task” and “the change is approved,” and nothing beyond that. Once you approve and execution begins, Plan Mode’s job is finished.

That is exactly the right shape for what it does: a fast, low-ceremony guardrail that stops premature edits and gives you one approval gate per task. It costs almost nothing to use, which is its great virtue.

What ADD actually is

ADD — AI-Driven Development — is not a mode you toggle. It is a methodology with a state machine behind it. Each feature lives in a single TASK.md under .add/, and the work moves through eight steps that never change: Ground → Specify → Scenarios → Contract → Tests → Build → Verify → Observe. A small tool (add.py) tracks where you are so that context survives across sessions — you can close the laptop mid-feature and the method tells the next session exactly where to resume.

The discipline is front-loaded into artifacts, not held in a conversation:

• Specify and Scenarios turn a request into ranked rules and concrete Given/When/Then cases.
• Contract freezes the interface — and freezes it literally, with a checksum tripwire, so the agent cannot quietly reshape the surface it was told to build.
• Tests must go red for the right reason before any implementation begins. No build starts against a green or vacuous suite.
• Build is where the agent finally writes code — against tests it is forbidden to weaken.
• Verify ends in exactly one recorded outcome: PASS, RISK-ACCEPTED (signed, never for security), or HARD-STOP. Trust comes from evidence, not from the diff reading plausibly.
• Observe folds what production teaches back into the foundation, so the method improves across loops.

The human’s role is concentrated where judgment matters: one approval at the contract freeze, and the verify gate on residual risk. The agent does the building. Everything else is enforced by the pipeline and the artifacts, which is what lets the discipline hold even when the agent is fast and eager. (For where this sits among TDD, DDD, spec-kit, and GSD, see Where ADD Sits.)

Side by side

Laid against each other on the dimensions that matter, the two are not close substitutes — they barely overlap:

Read that table honestly and the asymmetry is the point. Plan Mode owns one row that ADD does not: mechanical read-only enforcement during planning. ADD’s gates live in the pipeline and the artifacts, not in a restriction on the agent’s tools mid-task — so nothing in ADD stops an agent from touching a file while it is supposed to be thinking. Plan Mode does exactly that, and cheaply. Meanwhile ADD owns six rows Plan Mode has no answer for: tests-first, the frozen contract, evidence-based verification, the fold loop, cross-session persistence, and a disciplined story for what “changing your mind” costs. Each covers ground the other leaves open.

The real relationship: composition, not rivalry

Here is the reframe. Plan Mode is a tactical guardrail that governs a single turn. ADD is a strategic engine that governs a feature’s whole life. They are not two answers to one question — they are answers to two different questions, asked at two different scales:

Plan Mode asks: “What am I about to change right now, and do you approve?” ADD asks: “Is this the right thing to build, and can I trust that it shipped correctly?”

Because they sit at different altitudes, the natural move is not to pick one — it is to nest the small one inside the big one. Plan Mode fits cleanly inside ADD’s Build step. When the agent reaches Build and starts implementing against the red tests, running that implementation in Plan Mode gives you a per-diff preview and approval within a step whose direction is already locked by a frozen contract and a failing suite. The contract says what; the red tests say correct; Plan Mode lets you eyeball the how one change at a time before it lands.

The diagram is the whole argument in one frame: Plan Mode is a box inside a box. It sharpens the moment of execution; ADD supplies the spec, the contract, the tests, the verification, and the loop that the moment of execution sits within. Used together, Plan Mode covers the one thing ADD’s gates do not — a mechanical “look before you touch” at the point of the edit — while ADD covers everything Plan Mode never reaches.

When to reach for which

The category distinction becomes practical the moment you ask what a given piece of work actually needs.

Reach for Plan Mode alone when the task is a one-off, fits in a single session, and has a small blast radius — a refactor you’ll review by eye, a script, an exploratory change in a repo with no ADD setup. The thing you mainly want is to stop the agent from editing before you’ve seen its approach. Plan Mode delivers that for the price of a keystroke, and dragging a full methodology over a ten-minute task is the ceremonial over-application that gives process a bad name.

Reach for ADD when the result has to be trusted, not merely plausible: work that crosses sessions, touches a load-bearing interface, carries security or concurrency risk, or needs production signal to feed back in. A single in-session approval cannot give you a frozen contract, a tests-first gate, an evidence-based PASS, or a fold loop — and those are exactly the guarantees that matter when “looks right” is not good enough.

Reach for both when you are doing serious work and want a tactile checkpoint at the point of the edit — the common case for a high-stakes feature. Let ADD frame the feature; let Plan Mode govern the individual diffs inside Build. The method keeps you honest about what and whether; the mode keeps you in the loop on how.

What each one is missing

The cleanest way to hold the two in mind is by their symmetric blind spots.

Plan Mode, used by itself, gives you a per-task approval and nothing durable. There is no record of why the plan was chosen, no test that pins the behavior, no frozen surface the next session must respect, and no mechanism for a production surprise to re-enter your process. It is a guardrail, not a memory. That is not a flaw — it is the correct scope for a session-level mode. But it means Plan Mode alone leaves the trust problem untouched: it ensures you saw the plan, not that the result is correct.

ADD, used without anything like Plan Mode, leaves one specific gap open inside Build: the agent can edit while it works, and ADD’s enforcement is downstream — in the red tests it must satisfy and the verify gate it must pass — not in a restriction on the agent’s hands mid-step. For most ADD work that is fine, because the tests are the backstop. But when you want to watch the implementation arrive one reviewed diff at a time, a turn-level read-only checkpoint is a genuinely useful thing to drop into the step, and ADD does not supply one on its own.

Put plainly: Plan Mode guarantees you looked; ADD guarantees the result is trustworthy. Neither guarantee implies the other, which is the whole reason they compose instead of compete.

The takeaway

The framing to keep is the one the title points at: ADD is a method, Plan Mode is a mode, and the slash between “method” and “mode” is not a versus — it is a layer boundary. They share the instinct that direction must precede speed, and they apply it at different scales: one to a turn, one to a feature’s whole life. The honest answer to “which should I use” is both, at the layer each fits — Plan Mode as a cheap, mechanical checkpoint for a single change; ADD as the durable, evidence-gated discipline around the feature that change belongs to.

If you adopt only one, adopt the one that matches the cost of being wrong. If you adopt both, nest the small inside the big and let each cover what the other cannot.

To see where ADD sits in the wider lineage of methods it draws from — TDD, DDD, BDD, spec-kit, GSD — read Where ADD Sits. To start from the thesis underneath the whole approach, begin with How AI-Driven Development Fixes the SDLC. And the next time the question arrives as ADD or Plan Mode, you can answer the better question instead: which layer does this task need?