> 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.

> 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

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

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.

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

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)

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

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.

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).

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.