Plan mode is actually the product

After a year-and-change of IDE-agent tools as a daily-use surface, the thing I'd point at as "the actual product" isn't the model, isn't the IDE integration, isn't the autocomplete, isn't the chat interface. It's plan mode. The workflow where the agent describes what it's about to do, you read and adjust the plan, and only then does it execute. The tools that ship this well have stuck around in my daily rotation. The tools that don't (whatever else they're good at) have steadily faded.

Worth being plain about why this matters and why the keynote framings keep undervaluing it.

The plan-mode loopPlanagent proposesstepsConfirmhuman or policygatesExecutethe approved planonlyObservewhat reallyhappenedWithout the Confirm step, you have an agent. With it, you have a tool.The plan-confirm-execute-observe loop.

What plan mode actually is

The pattern, in its concrete form: you ask the agent to do a thing. Instead of doing the thing, it shows you a plan, files it will touch, changes it will make, tools it will call, the order of operations. You read the plan. You can edit it, accept it, reject it, ask questions about it. Once you accept it, the agent executes against it.

The execution still uses the same model, the same context, the same tools. The only difference from "execute immediately" mode is the explicit pause for review.

That sounds small. It changes everything.

What it prevents

Three categories of failure that plan mode catches before they happen.

Over-eager scope expansion. You asked it to fix one bug in one file. The plan reveals it's about to refactor four other files because it noticed they have the same pattern. You either approve the broader change plainly or constrain the plan back to the original scope. Without plan mode, the broader change happens silently and you discover it at commit time.

Wrong-tool selection. The plan shows the agent is going to call the database-migration tool when you wanted it to call the schema-validation tool. You catch the mistake in the plan rather than in the destruction. Without plan mode, you find out by running the migration.

Misunderstood intent. Your prompt was ambiguous; the agent picked the wrong interpretation; the plan reveals the misinterpretation in seconds. You re-prompt before any work is done. Without plan mode, the wrong interpretation gets executed and you have to undo it.

The pattern across these: the plan exposes the agent's reasoning before that reasoning becomes durable changes. The cost is the read-and-approve friction. The benefit is not having to undo the wrong work.

What it enables

A few patterns plan mode unlocks, on top of the failures it prevents.

Trust calibration. You learn over time which kinds of tasks the agent plans well and which it doesn't. The plan output is the signal, if it's consistently good for refactor work and consistently weird for migration work, you adjust your usage. Without plan mode, you don't get the calibration signal until the work is done.

Plan-as-spec. A clean plan from the agent is often a better functional spec for the work than the prompt was. You can hand the plan to a teammate (or a future-you) and they understand what the agent intended to do. The plan becomes documentation.

Step-by-step narrowing. Complex tasks benefit from "show me the plan, narrow to step 1, execute step 1, show me the plan for step 2." The plan-mode loop is the natural unit for the planner-executor pattern that holds up across agentic systems generally.

What the platforms get right and wrong

Specific reads on the IDE-agent tools I've used heavily this year.

Claude Code (since it shipped in February). Plan mode is first-class. The default for non-trivial tasks. The plan output is structured (files to touch, changes to make, tools to call) and easy to read. The thing that makes Claude Code reliable for daily use is exactly this, plan-then-execute as the default path, autonomous-execute as the explicit opt-in.

Cursor (current). Plan mode improved meaningfully through the year. Earlier versions were too autonomous-by-default; the current version's "plan first" toggle is on by default for the agent surface and the difference is visible in how consistent the day-to-day feel is.

GitHub Copilot agent mode. Plan mode exists; it feels less central to the workflow. The product still leans toward immediate-execute as the natural path. The plan surface is there; the discoverability and friction patterns push users away from it.

JetBrains AI Assistant. Improved over the year. Plan mode is present in the agent surface; the default behavior depends on the JetBrains tier and configuration. Mixed user experience as a result.

The smaller players. The pattern is consistent: the tools that ship plan mode well stick. The tools that emphasize the "look how autonomous it is" demo without the safety-rail of plan-first execution have churn.

Why the framing matters

The keynote framing for IDE-agent tools tends to be "the agent does the work for you." That's the demo version. The real version is "the agent proposes the work, you approve, the agent executes." The first sounds better; the second is what works.

This isn't a knock on autonomy. The agent doing the work autonomously is great when the task is bounded enough that the autonomy can't surprise you. It's terrible when the task has any of the failure modes the runaway-tool-call piece covers, and most non-trivial tasks do.

The right read on the IDE-agent category in mid-2025: the autonomous-execution surface is a feature. Plan-then-execute is the product. The tools that get this right are the ones that earn daily use over months. The tools that don't are the ones that produce wins on the easy 80% and burn trust on the harder 20%.

What I'd want to see next

A few extensions of the plan-mode pattern that would make the next year of IDE-agent tools meaningfully better.

Plan diff. When the user adjusts the plan and asks the agent to revise, show me the diff between the prior plan and the revised plan. Right now I have to compare manually.

Plan templates. Common workflows (migration, refactor, test addition, dependency upgrade) could ship with structured plan templates that the agent fills in. Less freeform; more reliable.

Plan history. Save the plans the agent produced for past work, alongside the actual changes that resulted. The history becomes a useful retrospective surface and a way to spot patterns in agent behavior.

Plan review by another agent. Have a second agent review the plan before execution, a critic against the planner's output. The cost is one more model call; the benefit is catching the cases where the planner is confidently wrong.

None of these is exotic. The category is mature enough that the next-tier features are about making plan mode richer, not about making it more central. The centrality is already settled in the products that work.

The honest summary

Plan mode is the actual product. The model matters; the IDE integration matters; the autocomplete matters. None of those is what makes the tool durably useful for daily work. Plan mode is. The tool that gets plan mode right is the one that survives the second month of usage, when the novelty has worn off and the actual work is what's getting done.

The version of IDE-agent tooling that ships in 2026 will have plan mode as a non-negotiable. The current generation is the one where the leaders separate from the rest by ship-quality on this specific feature. Finally, worth being plain about it now because the marketing layer is still elsewhere and the practitioner conversation has moved on.