[I work on Claude Code] I broadly agree with the author’s point: plan mode was useful, and is no longer useful.

In Claude Code, all plan mode does is add a little reminder to every user message along the lines of “you’re in plan mode, please don’t code yet”. It’s something I came up with late on a Sunday night many months ago, when I got tired of asking Claude to plan with me first before coding in each new session. Something people might not realize is plan mode has always been a prompt — it has never changed the toolset because doing so would break the prompt cache, and so would be expensive for users.

This worked well for a while, until a few months ago, using early versions of Fable, I realized that I wasn’t using plan mode anymore because the model just got it, and because for the increasingly complex work I asked the model to do, planning had become interactive and iterative. With Opus 5.5, I feel Opus has gotten to that point too.

For codebase understanding, I sometimes ask Claude to generate an artifact that explains some aspect of its changes. For complex diffs to core parts of the system, I will often ask it to make diagrams or even interactive demos so I can better understand the change and alternatives considered. I don’t do this very often, but it’s a useful way to explain code when you need it. I ask Claude to attach these artifacts to its PRs also, so others can understand and future Claudes have the context.

> This worked well for a while, until a few months ago, using early versions of Fable, I realized that I wasn’t using plan mode anymore because the model just got it, and because for the increasingly complex work I asked the model to do, planning had become interactive and iterative. With Opus 5.5, I feel Opus has gotten to that point too.

For me it’s actually the opposite, and Claude Code’s plan mode isn’t nearly sufficient. Personally I ask Claude to write down a markdown file with its plan, then review the plan using plannotator, and then go back and forth (most of the time it’s actually the comments that are the problem, not the code).

Then start a fresh session, seed it with the plan, tell Claude to find ambiguities / friction points / oversights, resolve those, and then implement it.

Review once again with plannotator, go back and forth, and then send PR.

Maybe not the “vibe coding” that was once imagined, but this does ensure I am fully aware of the code and architecture, the quality, and this also prevents long term degradation.

It's useful because it let's me see the decisions the model will make before it wastes a ton of time implementing them. The model is smarter now but that doesn't solve for underspecification if it guesses my intent wrong

I disagree with the assertion that the model gets it. Here’s a practical example I just tried with Fable 5.1. I gave it this prompt: “Write a Go function that can be used to establish secure communication to a remote system using a certificate. Keep it short, single function, and explain how to use it.” The output forced the use of a private key stored in a file even though that wasn’t specified anywhere as a requirement. The function Claude wrote takes a private key file argument and calls a Golang function that requires a private key file (tls.LoadX509KeyPair) even though Go has crypto.Signer which could support private keys in various other manifestations like HSM or KMS. I argue that a person who “gets it” (or who is reasonably experienced in security) would have opted for not requiring private key material for this to work.

For the record, this isn’t unique to Claude. ChatGPT and Gemini do the same, each with its own quirks. ChatGPT got extra credit for being the only one who allowed the function to also take a CA file for server authentication.

Don’t get me wrong: LLMs are the future (maybe even the present) of software development but I think there’s some way to go before they can be entirely hands-off in some areas. I still find myself having to course correct designs and plan mode helps me with that.

And of course, thank you for your work on Claude. :)

Hi, thanks for Claude Code. I use it, and it works well. Have you considered changing it so the text comes down from the top of the screen, in green, like The Matrix?

I always append something along the lines of “evaluate”, “investigate” or “report only” to my prompts when I want to see what the agent is gonna do. Because especially with the new models they tend to go easily off rail and do stuff I didn’t ask. To say that they just “get it” is highly dependent on the task, scope and blast radius.

hi I’m the author of the post. I think that’s basically the distinction I’m trying to make.

Historically, plan mode served two different roles:

1. making the agent’s instructions precise enough to execute 2. helping the human understand what was about to happen

I think #1 is less necessary as agents get better. #2 is going the other direction, it becomes more important as the model is able to do more on its own because larger chunks of work are happening with increasing complexity.

Where I’ve changed my mind is the interface for #2. I increasingly think an interactive, iterative workflow is closer to how people actually build understanding than being handed a long generated document, especially one they didn’t author themselves.

The human-understanding problem is very real though

My team has been struggling to understand whether or not we should do "spec-driven" development or not. It makes a lot of sense to me to have one developer iterate with the model/harness to generate a markddown document that is a high-level of what will be implemented, and then have the team PR review it before and agent attempts to do the actual implementation work. Do you think this is a good practice?

> plan mode has always been a prompt — it has never changed the toolset because doing so would break the prompt cache, and so would be expensive

seems like plan mode could turn off some tools, even if it doesn't change the set offered to the model, the ones that they have which would mutate your codebase could just not work with an error message, and plan mode could change permissions in the security approval prompt for "auto"

anyway, isnt the right way to know if plan mode helps or not, to run an experiment? we're all guessing unless we have data

read only agent mode sounds straightforward and useful to me

Early versions of plan mode would erase the chat history and present the plan as the start of a new session when you approved it.

I miss that. It worked really well, and it kept the context clean.

for me it basically all boils down to:

1. I dont want to have to accept every time Claude touches our DB

2. I'm scared out of my mind it might do something bad to the DB

Plan mode gives me enough confidence that it wont do (2) --> allowing me to give it enough permissions to do (1)

I think over time more and more will be peeled back to just the model and markdown. I have a beautiful factory running with key personas all it is is a few markdown files it is building a mac app fantastically well.

https://innerloop.test/breadcrumb (for reference)

As someone that never used the built-in plan mode, but did use a lot of spec-driven development, I’m still finding that even with Fable having “plan” docs is still quite helpful.

They’re most useful for broad changes (new features, refactors, etc.) where it’s helpful to avoid breaking changes or unnecessary scope expansion.

The new models are great, but they do more by default, which means I’m finding myself explaining what _not_ to do more often than with previous models (where they’d often end too early).

In my case, the previous plan mode was too ephemeral, and I like having one source of “truth” that sits across context windows without loss/compaction.

I like plan mode personally. I only use claude code for the web, and the questions claude asks me to clarify are usually pretty important - mostly because I was too vague or contradictory in my prompt, or what I was asking for conflicted with something else in the code. I don't know how claude would resolve that without plan mode.

Also for session planning, as in when-can-I-walk-away-from-computer, its nice to know the particular rhythm of initial crunch - ask questions - make plan - do it. Especially with a 5 minute cache timeout.

Plan mode was great, but I realized I progressed well beyond it. I found that I was getting these categories repeated errors and oversights from Claude (and frankly it hasn't gotten much better about this). Skills were too generic and got lost to context.

I ended up building out tool an MCP server that I use as a bit of a psuedo harness for Claude. I have a variety of multi-step workflows that are basically micro-skills stacked on top of each other. This helps me make sure that I can get Claude to think in a repeatable and reliable manner.

For coding, I've found that I have a few specific steps that Claude needs to do before I'm comfortable letting it loose:

* It must extensively explore the code base (including certain areas that it misses)

* It must think about what it doesn't know or is making assumptions about

* It MUST scaffold out it's intentions. Essentially, it can write comments, classes, and method stubs - but no actual content. Very much like a spec, but since it's in and alongside other code, it's much easier to identify problems.

* It must spike and validate key assumptions. This, plus the prior step, are the only way I've figured out how to avoid it ending up in a confusion loop. Too often it looks at poor-quality code it's written and thinks it's a long-term solution. By avoiding writing code as much as possible, it knows that it's draft content.

* Only, then can I review it and send it it.

Said MCP server (missing the actual ops): https://github.com/clops-mcp/clops-mcp

Yeah, as a user I came to the same conclusion as I naturally used plan mode less and less over time.

I still use plan mode in Astra to come up with a plan that I then feed into Fable. I feel like OpenAI models still do better big picture investigation and planning, while Claude is the better software engineer, if that makes any sense.

Of course this could well come down to my own biases and the specific things I’m working on.

I really wonder what I’m missing because my general rule to plan first unless explicitly instructed works perfectly fine with all models I use.

“I want to ...” / “Let’s ...” -> Plan

“Do X” -> Actually Act.

But then again I also have it configured to only ever answer questions instead of inferring them to be instructions (which I’ve seen others do differently).

I use plan mode, because my current project benefits from "pair programming."

I have one session define a task, and provide a formal specification plus context in a "cover letter."

The session B, in plan mode, produces the plan back.

Session one reviews the plan and clears it, ratifying portions and often specifying specific changes.

Session one then executes.

What has been striking to me in this approach is that even with two instances of the same model (currently Opus 5.5), there are regularly corrections made. I use "project chat" for session A and Code for session B atm; it is very typical that Code finds and corrects details or oversights in the task spec; it is also typical (though less so with 5.5) that session A (chat) pushes back or clarifies things Code doesn't have the context for.

I have been afraid to open up the potential of negotiation beyond what this is costing as it is. But I am also afraid to simply skip the formalisms, because of the consistent correction that occurs in this back-and-forth.

Each component of the pattern is schematized, generated from a template, and validated, to keep things tight.

Lots of tokens! But I trust this process far more than "just typing" :)

For me its like a dry-run.

As a long time user of Claude Code, I've just naturally stopped using it because the model figures it out, and i prompt it accordingly like 'come up with a plan'. Glad to see your experience matches

Plan mode still earns its keep when the blast radius is high.

For a one-file change I don’t bother. For anything that touches auth, payments, or a shared schema I still want the plan written down first — not because the model can’t figure it out, but because I need a moment where I can still say “no” before it starts editing.

The mode was never really about making the model smarter. It was about making the human stop and look.