[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.
I do the same, I don't use Claude Code or Codex planning because it is mostly pointless, even with Fable/Astra. I just have multiple agents work on a markdown file which I manually perfect, often breaking into multiple different files for large features or PRs. I also create design 'handoff' documents which I feed into Claude Design or Astra along with screenshots and wireframes. By the time an agent does something I'm well prepared.
I've tried doing the incremental, iterative approach with just Code and it's just not as effective unless you're working on something simple or experimental. Or you're shipping to something non-serious or perpetually beta.
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
Interesting, I don’t see this very often with the latest models. Are you using Opus 5.5/Fable 5.1?
Either way, plan mode isn’t going away. You can always /plan or ask Claude to enter plan mode. We might re-map the shift+tab keyboard shortcut to something else by default for people that don’t use plan mode.
Hey, well first off, congrats on making the greatest product ever probably.
I absolutely see fable and opus 5.5 misunderstanding intent, but that just seems to be a feature of necessarily underspecifying in a written prompt. Just today, I gave opus 5.5 a simple task to spin up a new environment for work. It read the ticket, which was decently specified and knowing the codebase as well as "Ghasp... reading the code" I had to correct it about 5 times to do it in a way that I would have expected it to. Getting the pipelines right, environment variables, and configs. It was all relatively straight forward imo. Then I had to prompt it to clean up its corrections, because it left a workflow variable in the github action that some intermediate step required but the final solution didn't. I definitely would not have caught that if I didn't read the output. Idk, there seems to be a natural limit as to how much it can infer and I have no idea how to fix it. I did write about it [here](https://javiergonzalez.io/blog/the-assumption-problem/) though.
I use fable 5.1 (tried opus but it lied to me 3 times in quick succession and ignored me in another)
This is weird to ask because I feel like of course the model isn't omniscient? Isn't the whole point of iterating on a plan to assess impact, risk, know your (the user) variables, user impact, product impact, etc for making a change? I cannot count the times even in the past few months where I start a conversation with my C suite because their desired outcome would have a potential negative impact elsewhere for other products or users.
Is this just not something that comes up at Anthropic?
I greatly prefer this, since it lets me iterate on the plan with Claude for a while without it repeatedly asking if I’m ready to implement the plan.
Once I’m satisfied, I usually start a fresh session and tell it to implement the plan.
For smaller plans, you don’t need the file. Just ask it to come up with a plan. I don’t recall the last time it just started implementing if I only asked for a plan.
It’s not that planning is dead, but rather that planning has outgrown the simple “Plan Mode” feature as models have become capable of taking longer turns.
In my experience, around the time the author describes as starting to not need plan mode is when erasing the chat history became an anti-feature. I found the agents were doing better when they had the context already, and with the history I no longer needed to micro-manage persisting various caveats and rejections to the plan artifact. The amount of prompt construction necessary went down overall.
By the time my plan’s done I’m usually between 200 and 350k context. Even if keeping that around gives a performance bump for the implementation (which I haven’t noticed to be the case) it balloons the cost. I would much rather put everything in a plan file and start fresh.
Plus, I usually plan with a more expensive model and guide implementation with a cheaper model (with smaller validation calls back to a more expensive model)
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.
FYI I had Clod attempt to corrupt a prod db the other day. (Opus 5)
I was experimenting with a rather complicated backfill operation, were I had a validation script I understand and have Clod come up with the backfill script. I was running against a local prod copy, and it proposed running the actual (unfinished) backfill script against prod.
It didn't have access to the secrets and I also caught the command, but a good reminder that this stuff needs guardrails.
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.
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
Awesome blog. You're a good writer. I enjoyed seeing your article on AI in 2018. Thank you for sharing your expertise.
Also I hope your delivery goes well. My wife (and co-founder) had a challenging delivery and it really put life in to perspective for both of us on a range of issues (how much women's pain is minimized in the health system requiring stronger personal advocacy than I would ever have expected).
As far as plan mode, I still find it essential in keeping agents on track. I build propelcode.app and have a variation on plan mode I still find useful, happy to trade notes on agentic coding if youre interested.
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).
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.
I'm actively watching understanding slip away from developers, code review getting paired down to no comment checkmarks, and codebases go to bloated messes that nobody can read. Axioms like engineers must understand and take responsibility for the code they ship are getting torn down, and the products coming out are reflecting conway's law, becoming impenetrably obtuse and always "so complex there are no obvious deficiencies" (as opposed to "so simple there are no obvious deficiencies" which used to be the aim).
The one thing plan mode helped is for the humans to get an understanding of the strategy, and be able to poke around and look at the design and architecture. You can achieve this with some self discipline and keeping shorter leashes on agents, but it feels like a losing battle. The best devs still put out good code, but the poor devs are learning nothing while their metrics look great. I can't help but think we are racking up immense amounts of debt that will very soon become due.
I feel the same way but I have successfully refactored some of the early experiments. Our team has settled on targeting a double output from the before times but more ambitious product vision because AI can teach us things we don't know. We actually target 2 days of coding and 3 days of learning with Ai so the increased efficiency allows upskilling rather than just pushing more code
Just like rushing made messes in the before times so too does rushing via LLM. The exact same outcome will happen, but at a far greater velocity and scale than anything we've seen in this industry before. Old Testament, Mr. Mayor, real wrath-of-God type stuff!
"The one thing plan mode helped is for the humans to get an understanding of the strategy"
For me, this phase still happens, but a distinct "plan mode" is unnecessary: I just tell the model, "This is discussion; no code changes yet." and spend hours figuring out what will and will not be done.
It's truly bizarre to read about all these people who just give up on any understanding about what they are working on.
I very regularly use plan mode not to even make a plan of action itself, but to better understand what possible issues might come up when implementing some feature or fixing some bug. And it is quite common for me to fix or rewrite certain findings that AI comes up because its assumptions are not quite right or don't align with overall goal.
And yet so many seem to be perfectly fine leaving all the decisions to AI - even if it's going in the wrong direction. I suppose that's all the people who got into software purely for money or status - never really caring about the actual thing they are working on.
> The best devs still put out good code, but the poor devs are learning nothing while their metrics look great. I can't help but think we are racking up immense amounts of debt that will very soon become due.
I agree with this, but the reality is that it's only the result of models empowering devs, and power in good hands amplifies positive results while power in mediocre hands amplifies technical debt.
It's a good time to choose wisely who you work with.
> It's a good time to choose wisely who you work with.
Very true, but this also makes me think what kind of ridiculous obstacle course future hiring process would look like.
In a land where anyone with a pulse can prompt AI to make an app for them - how would future hiring managers and team leads figure out who will drag codebase down with tech debt and who wouldn't?
I find a lot of value in using plan mode to get the LLM out of dead ends. If it's in Act and starting to spiral (evidence of looking for something or trying to better understand something), I'll kick into Plan and tell it to think a bit harder—also avoids it wasting tokens retrying the same techniques—which results in a much more considered, and more often than not, correct approach.
I'm probably just behind the curve, but I still use plan mode quite a bit in Claude Code. I iterate on the plan repeatedly until it largely agrees with what I want. Once it seems good I ask it to build the plan and open a PR when done.
My only critic of the plan mode is I wish it was easier to see the updates and changes easily in Claude Code as we iterate on the plan. It is wasteful to have to remember what parts I have reviewed and what parts are new (and need another pass). I have thought about fixing this but I also feel the review is the actual thinking (even if ineficient), and so I purposely have not removed it.
I still like plan mode in my harness because I restrict it's tool use so it can't go rogue and write documents outside of a specific folder. In my case it is /agile which contains a roadmap.md with epic1.md through is many epics as needed for the full vision. Then I often have one chat session per thread. If multiple agents take a sprint or a card it serves as a clear unified context for me and the agents to follow and then track what has been done.
Why is a plan "mode" needed? I really hate reading plans in conversation UI. One line in AGENTS.md is always better, and you can customize it to fit your document convention.
From the communication perspective, the planning process is most about creating clarity and alignment, on things like scope, constraints and decisions, among people (and agents now), often requiring multiple rounds. The planning tool built in Codex or Claude Code is not persisted, version-controlled, nor well accessible.
In practice, My AGENTS.md contains an instruction about writing a document before starting implementation. Usually I won't read that document, because I don't want to micromanage agents. That document mostly serves a historical purpose like ADR, helping me find out what agents missed, made mistakes on or misaligned on, if needed.
The real reason why plan mode is dead is because you can just conversationally instruct the agent to not make changes to the repository or to make changes to selected documents only, and it will listen. There was a time when we needed to enforce this via selected tool use, but we have surpassed that.
Plan mode does have different permission controls though? Its difficult for me to parse the docs on this but it does seem to imply more than just a prompt although less than a full sandbox. https://code.claude.com/docs/en/permission-modes#analyze-bef...
The way it worked originally was it would trigger a different system prompt, and then the permissions system would prompt you (even on YOLO mode) before running any non-readonly actions.
Cursor would also write a plan document, which was useful when working on larger tasks (due to context size). I still find that part useful today.
It also doesn't allow leaving an audit trail of plans and decisions (by default, anyway). Most of my mutating prompts look like "Propose a plan for change X and write to file Y" and "Execute steps M-N from file Y".
RE the article: I don't think it's obvious why this process is worth following until you find your time and attention wasted. Conversationally-building is the express train to waste. I'm not sure why you would even be talking to claude if you don't understand what you want to build.
I agree. Plan mode came about because earlier models were loose cannons, doing what they pleased. Today's models follow instructions better enough to not need a separate mode. However, there is still value in using a separate, smarter model for planning than execution, and persisting it for auditing on completion.
I typically converse with the default model to point the plan in the right direction, then have it iterate with a smarter reviewer to find flaws until the plan file is converged.
When I draft my idea for the implementation of a feature or bug fix, I don't even trust a _human_ to understand what I mean the first time. There are _always_ either errors on my part, or erroneous assumptions on theirs. Everything from "this accounts for X and Y, but not Z which breaks the whole thing" to "this part of the idea directly contradicts what with you said earlier, what do you want to do about it?"
I can't bring myself to trust that an LLM understands what I mean better than any human would, no matter how "good" people claim they are getting.
TFA seems to be advocating for regular old vibecoding. Code now and ask questions later. Which is their choice, and is perhaps even a valid choice in many cases. But at least call it what it is.
Using an LLM for any large project shows how useful it is to have data and functions that aren't siloed. That's why CLI apps have had a resurgence: because the LLM can interface with them. Yet the reaction from so many who are deep into LLM development is to build their own little silo: an app.
We really need a better model. One alternative is to have an everything-app: a general purpose tool in which (almost) everything lives. The terminal is one of them. The text editor / word processor is another. (I use Emacs for everything.) In a business context the spreadsheet is probably the best choice.
I still use plan mode, but during plan mode I will spin out sub agents to implement the current draft in a tmp dir and bring back lessons. I feel this keeps me grounded in my original starting point, rather than ending up with a implemention that meanders through the agents own discovery process. It also lets me ask concrete questions about (possible) implementation
Plan mode is still very useful to me, I just need to read the plan. Even if the model is smarter than me, it’s still working on my project, and thus I need to keep a mental view of the system. My solution has been to ask the assistant for far less than it can do and leave for myself a bigger bunch of the work, so that I’m forced to keep myself up to date on the project. Yeah I’m leaving productivity on the table but… am I really?
I only really used it because the harness was way too trigger happy to start making changes. Even if I just asked a question some times I would come back and it refactored the whole codebase. Now it doesn't seem to do that any more.
I still would appreciate a "read-only" mode. It's not uncommon that I start a harness ONLY to explore and understand the code and I don't really want one typo to have it off building something, or even to save a plan document.
Disagree. While it's easier to 1-shot more things now, when there's more complicated interaction of components, a good plan from plan mode can make the project a "looks good, go" and run overnight thing vs. "steering" needed.
I like writing spec files exclusively by hand and just asking the agent to surface questions about it, which I then clarify by editing the spec file further by hand. It keeps the spec file more manageable than having the agent generate the spec file from your conversation.
Claude code’s plan mode began its slow march towards deprecation when they hid the “clear context and implement” option behind a flag. From the discussion at that time it seemed that the developers considered it mostly a legacy feature, and that newer models are smart enough in long context not to need it.
This part I find a little disappointing. The plan is the perfect boundary to cut context which still isn’t free, even if models can handle a lot of it now.
This is why open harnesses and open models will always be superior, it's only a matter of time until someone decides that something you use isn't worth maintaining anymore. The reply from the Anthropic employee up above doesn't give me much confidence that Claude users will be able to continue using plan mode forever.
I use Claude's Plan mode daily and it's great. I almost always have feedback to refine the plan and I want a clean separation of planning time before writing code. I don't get what the problem is.
I also find this "kill Plan mode" push on Twitter odd, because developers have been complaining about AI supposedly killing their jobs, yet they want to take away the main feature that lets them be an active collaborator and participator in the process. Weird.
I also don’t get what the problem is. Claude’s plan mode is great, especially when you add interviewing into the equation. It means I can get to a point where I’m confident all the changes proposed make sense, and that I understand them, before anything is actually changed.
I feel like this post is hawking for commercial reasons more than it’s based in reality, especially a reality that takes into account the extremely varied experiences engineers seem to have with agents. Not to mention it ignores capabilities that, for example, Claude’s VS Code addin have had for ages (specifically select and annotate in plan mode, as I mentioned in another comment).
As such I’m not inclined to take it very seriously. More than that, the “X is dead” trope was overdone 10 years ago and I don’t think it’s been long enough to warrant a resurgence.
I see what you’re saying. That’s actually why I built Nuanced (https://www.nuanced.dev), I wanted a better way for humans and agents to work through intent before the code got written.
but I think I overfit the interface to how I used to work without agents. when I was at GitHub, I wrote a lot of ADRs, RFCs, and design docs, and I liked that because writing is how I clarify my own thinking. with agents though, I’m often not doing the writing myself. I give the model a rough intent and it fills in a bunch of gaps, and then I get back a long, polished plan containing decisions I didn’t explicitly make.
That’s the part that feels broken to me. The plan can be detailed and technically correct, but still be hard to review because the important bits are buried and feel distant from my own thinking. All the assumptions and tradeoffs and questions may or may not be legitimate, but it’s hard for me to get into flow state and carefully check them.
So I still want the collaboration step. I’m just less convinced that generated prose à la plan mode is the right interface for it.
There are many ways people solve this. I use spec directories, and the agents just keeps updating it as I make decisions. It isn't a single file, it's a directory; sometimes nested based on the size of the project. I'll have the directory open in my editor of choice. It being a directory allows me to use an arsenal of text tools, and also optionally commit it for history/tracking.
This tool is a difficult sell. Users _might_ consider an Open Source version, but switching people away from familiar tools is not easy.
I likewise don't understand this push. Surely it's a trivial feature to keep enabled. It mostly seems like advertising that "our models are so smart you don't need to plan". But I find it to be a great mental review process for my workflow.
It sounds like the Ant perspective is "you can just ask claude to plan", but at the same time that's a little more tedious than shift+tab
> developers have been complaining about AI supposedly killing their jobs, yet they want to take away the main feature that lets them be an active collaborator and participator in the process.
Goomba fallacy. These are two distinct groups of people.
Yeah, honestly, I'm wondering, not even why people are against plan-mode, but how they're getting stuff done without it.
Maybe it's me (it usually is), but I don't give an LLM small tasks that a human could knock out in a half-day. I give them big tasks, stuff that would take a human a few months to a year - and then I ask it to give me a plan, as a living document, and we spend a good hour or two iterating over the plan.
Then, when its finally at the point where I'm happy with the plan, and I've talked it down from wherever it first wanted to go, or pointed out that we don't need to be all-things-to-all-(wo)men and focus is important, I get it to start going through it.
Likewise, I get it to maintain TODO.md with lists of known bugs, separate lists of future-features, and again, I make a rule that this file must be updated whenever something material changes. I just asked Claude "where are we ?" and got back stuff like:
The ## Still-open detail section lists two items:
- Task #1070: the ported back end doesn't fold offsets into vector loads, so it emits an extra add on 11 files (from 892) at -O3. The output is correct, just longer.
- Task #1080: array sizes must constant-fold. For example, u8 buf[EVSZ * MAXEV] is rejected because size expressions only accept a literal.
This is for 'xc' [1] - a compiler for an Objective-C-like language (but without the excessive []). The language has ARC, blocks and bound-functions/methods named 'block' and 'callback', automatic parsing of DWARF data so you can #use a shared-object, so there's no header files - just read enums/types/functions/methods from the shared object. It's a cross-compiler, runs on mac,windows,linux and creates executables for mac,windows,linux,ios,android,WASM (amongst others). I have a binary running on my iPhone which was written on, and signed on a Linux box - no Apple software used at all. Oh, and it produces code that is very comparable to clang in speed on both arm64 and x86_64.
You can appreciate it's a reasonably large project. It's taken actual months(!) [grin] for me to get working. Months! There's no way I'd approach a problem like this without detailed plans of what I wanted the language to do, where we were going with it
FWIW, "I" wrote blewit.net [2] entirely in xc - both the server back-end (#use <psql> was very useful for binding to Postgres) and the WASM client - which share classes between client and back end, to make it very difficult to get out-of-step between them. No Apache (#use <tls>), no scripting, just a lean-and-mean daemon talking to postgres via valkey (#use <valkey>) - a reddis-alike. Oh yeah, blewit.net has a plan too. Actually it has lots of planning :)
I have never used plan mode and always worked by planning. I just say 'don't write any code yet. I want to [describe usage]. Ask me the top ten relevant questions to doing this well. We're working up a planning .md we'll handoff to a fresh agent.'
Lately, I've been using Matt Pocock's “/grill-me” skill more and more, rather than plan mode or a complex, spec-driven set of skills. I made a personal fork of the skill to use Claude’s ask tool, which has a nicer UX.
I used plan mode for two reasons: to review the choices before execution, and to execute with another model (i.e., using the barely documented opusplan feature).
The grill-me skill is much better for reviewing and clarifying choices (and modifying it to use the ask tool makes you go faster). Instead of opusplan, you can explicitly tell Claude to start a subagent with another model to divide the tasks.
A plan means it preps all work for the agents up front, tests that evals work, makes sure the dev environment is right for each agent, then finds and fixes each before the distributed tasks even begin.
What I thought would take minutes took hours as a supervisor or one agent did the prep / pre flight work.
My solution so far has been to drop all but basic setup and force the supervisor to ask before every op - if this is not the design choices, can this be run in parallel? If so, hand it off NOW.
I'm still iterating this workflow, but less setup for all the minions plus handing them work that may be incomplete/ broken is caught and fixed by the minion and its own qa gates.
This can mean a number of minions end up replicating the same fixes, but in general the time cost of that is small Vs the supervisor working in parallel instead of too sequentially.
Yeah, it's way better when you do design documentation, or even ticketing, to instruct it not to include any implementation specifics. You're not doing the deep dive on the zero shot that writes the ticket or the document and so it is much less informed than the agent doing the work will be.
- Inefficiencies in delegation, necessitating workflow patterns for small projects (big AIs hide this problem until you scale and they hit the same issues).
- Limits of the AI would be harder to find or notice (e.g. where time - and cost - is being spent needlessly).
With Claude, most tasks do not require discussion, I know exactly what to ask and what approach I want to take but for especially complex functionality with multiple possible options, I will ask it to list the tradeoffs and suggest an approach. It's still kind of 50/50 whether I take its suggestion or not; it's still a bit off in terms of weighing up importance, but it's really good at listing out relevant constraints and tradeoffs. It sometimes misses opportunities but it always sees the tradeoffs and the issues.
> While the ease of generating code this way triggered a greater dopamine reward
I get zero dopamine rush from this. I get a dopamine rush from building something or figuring something out myself. I don't get a dopamine rush for generating thousands of lines of code that I then have to try to understand.
I'd like a brainstorming mode, with limited side effects.
I want it to go and read stuff but also invoke some commands and generate reports and discuss on the results. Latest GPTs in codex plan mode always go.. write a plan. Shocking, i know, but thats not what i want on every turn when im in that mode.
Plan mode isn’t that useful but planning is, I never used it much, but in the agent build mode, I lay down the specs, the architecture, and everything I can think of, and I ask the agent to make the blueprint with the specs that will be used throughout the project, I review them, make the needed edits and revisions, then code and review follow. This is good because you can use the blueprint in any other model or agent, even humans can read it and understand it, sure, sometimes it gets overly verbose but it’s better than nothing.
I can't speak for Claude, but in Codex, plan mode is very useful for finding serious issues with one's spec. I use it to improve my spec. I keep rerunning plan mode over my updated spec until it stops finding issues. It is only then that I execute the spec.
> This cut-and-paste workflow felt clunky and made it arduous to work through an idea while keeping track of the current plan.
I mean, it is, and if that were the workflow I’d be very fed up of it by now, but the plan mode in Claude’s VS Code extension has supported select and annotate directly since at the very least early 2026.
oh interesting! I haven’t used vscode for anything meaningful since shortly after leaving GitHub (2023). I generally find it overwhelming but codex added the annotations too and I love it.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
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.
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.
I've tried doing the incremental, iterative approach with just Code and it's just not as effective unless you're working on something simple or experimental. Or you're shipping to something non-serious or perpetually beta.
Either way, plan mode isn’t going away. You can always /plan or ask Claude to enter plan mode. We might re-map the shift+tab keyboard shortcut to something else by default for people that don’t use plan mode.
I absolutely see fable and opus 5.5 misunderstanding intent, but that just seems to be a feature of necessarily underspecifying in a written prompt. Just today, I gave opus 5.5 a simple task to spin up a new environment for work. It read the ticket, which was decently specified and knowing the codebase as well as "Ghasp... reading the code" I had to correct it about 5 times to do it in a way that I would have expected it to. Getting the pipelines right, environment variables, and configs. It was all relatively straight forward imo. Then I had to prompt it to clean up its corrections, because it left a workflow variable in the github action that some intermediate step required but the final solution didn't. I definitely would not have caught that if I didn't read the output. Idk, there seems to be a natural limit as to how much it can infer and I have no idea how to fix it. I did write about it [here](https://javiergonzalez.io/blog/the-assumption-problem/) though.
This is weird to ask because I feel like of course the model isn't omniscient? Isn't the whole point of iterating on a plan to assess impact, risk, know your (the user) variables, user impact, product impact, etc for making a change? I cannot count the times even in the past few months where I start a conversation with my C suite because their desired outcome would have a potential negative impact elsewhere for other products or users.
Is this just not something that comes up at Anthropic?
I greatly prefer this, since it lets me iterate on the plan with Claude for a while without it repeatedly asking if I’m ready to implement the plan.
Once I’m satisfied, I usually start a fresh session and tell it to implement the plan.
For smaller plans, you don’t need the file. Just ask it to come up with a plan. I don’t recall the last time it just started implementing if I only asked for a plan.
It wastes a ton of tokens as well and those are not cheap.
I miss that. It worked really well, and it kept the context clean.
Plus, I usually plan with a more expensive model and guide implementation with a cheaper model (with smaller validation calls back to a more expensive model)
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
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 was experimenting with a rather complicated backfill operation, were I had a validation script I understand and have Clod come up with the backfill script. I was running against a local prod copy, and it proposed running the actual (unfinished) backfill script against prod.
It didn't have access to the secrets and I also caught the command, but a good reminder that this stuff needs guardrails.
https://innerloop.test/breadcrumb (for reference)
Is this what happens when you vibe code long enough?
https://innerloop.works/breadcrumb
What a rookie mistake!
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
Also I hope your delivery goes well. My wife (and co-founder) had a challenging delivery and it really put life in to perspective for both of us on a range of issues (how much women's pain is minimized in the health system requiring stronger personal advocacy than I would ever have expected).
As far as plan mode, I still find it essential in keeping agents on track. I build propelcode.app and have a variation on plan mode I still find useful, happy to trade notes on agentic coding if youre interested.
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.
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.
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 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 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.
The one thing plan mode helped is for the humans to get an understanding of the strategy, and be able to poke around and look at the design and architecture. You can achieve this with some self discipline and keeping shorter leashes on agents, but it feels like a losing battle. The best devs still put out good code, but the poor devs are learning nothing while their metrics look great. I can't help but think we are racking up immense amounts of debt that will very soon become due.
For me, this phase still happens, but a distinct "plan mode" is unnecessary: I just tell the model, "This is discussion; no code changes yet." and spend hours figuring out what will and will not be done.
I very regularly use plan mode not to even make a plan of action itself, but to better understand what possible issues might come up when implementing some feature or fixing some bug. And it is quite common for me to fix or rewrite certain findings that AI comes up because its assumptions are not quite right or don't align with overall goal.
And yet so many seem to be perfectly fine leaving all the decisions to AI - even if it's going in the wrong direction. I suppose that's all the people who got into software purely for money or status - never really caring about the actual thing they are working on.
I agree with this, but the reality is that it's only the result of models empowering devs, and power in good hands amplifies positive results while power in mediocre hands amplifies technical debt.
It's a good time to choose wisely who you work with.
Very true, but this also makes me think what kind of ridiculous obstacle course future hiring process would look like.
In a land where anyone with a pulse can prompt AI to make an app for them - how would future hiring managers and team leads figure out who will drag codebase down with tech debt and who wouldn't?
My only critic of the plan mode is I wish it was easier to see the updates and changes easily in Claude Code as we iterate on the plan. It is wasteful to have to remember what parts I have reviewed and what parts are new (and need another pass). I have thought about fixing this but I also feel the review is the actual thinking (even if ineficient), and so I purposely have not removed it.
Cursor would also write a plan document, which was useful when working on larger tasks (due to context size). I still find that part useful today.
You can use Docker’s sbx or similar VM/containers for that.
RE the article: I don't think it's obvious why this process is worth following until you find your time and attention wasted. Conversationally-building is the express train to waste. I'm not sure why you would even be talking to claude if you don't understand what you want to build.
If you do use plan mode you might like https://plannotator.ai/
I typically converse with the default model to point the plan in the right direction, then have it iterate with a smarter reviewer to find flaws until the plan file is converged.
I can't bring myself to trust that an LLM understands what I mean better than any human would, no matter how "good" people claim they are getting.
TFA seems to be advocating for regular old vibecoding. Code now and ask questions later. Which is their choice, and is perhaps even a valid choice in many cases. But at least call it what it is.
https://github.com/samelie/claude-plugin-pnpm/tree/main/skil...
We really need a better model. One alternative is to have an everything-app: a general purpose tool in which (almost) everything lives. The terminal is one of them. The text editor / word processor is another. (I use Emacs for everything.) In a business context the spreadsheet is probably the best choice.
I still would appreciate a "read-only" mode. It's not uncommon that I start a harness ONLY to explore and understand the code and I don't really want one typo to have it off building something, or even to save a plan document.
/s
This is why open harnesses and open models will always be superior, it's only a matter of time until someone decides that something you use isn't worth maintaining anymore. The reply from the Anthropic employee up above doesn't give me much confidence that Claude users will be able to continue using plan mode forever.
I also find this "kill Plan mode" push on Twitter odd, because developers have been complaining about AI supposedly killing their jobs, yet they want to take away the main feature that lets them be an active collaborator and participator in the process. Weird.
I feel like this post is hawking for commercial reasons more than it’s based in reality, especially a reality that takes into account the extremely varied experiences engineers seem to have with agents. Not to mention it ignores capabilities that, for example, Claude’s VS Code addin have had for ages (specifically select and annotate in plan mode, as I mentioned in another comment).
As such I’m not inclined to take it very seriously. More than that, the “X is dead” trope was overdone 10 years ago and I don’t think it’s been long enough to warrant a resurgence.
but I think I overfit the interface to how I used to work without agents. when I was at GitHub, I wrote a lot of ADRs, RFCs, and design docs, and I liked that because writing is how I clarify my own thinking. with agents though, I’m often not doing the writing myself. I give the model a rough intent and it fills in a bunch of gaps, and then I get back a long, polished plan containing decisions I didn’t explicitly make.
That’s the part that feels broken to me. The plan can be detailed and technically correct, but still be hard to review because the important bits are buried and feel distant from my own thinking. All the assumptions and tradeoffs and questions may or may not be legitimate, but it’s hard for me to get into flow state and carefully check them.
So I still want the collaboration step. I’m just less convinced that generated prose à la plan mode is the right interface for it.
This tool is a difficult sell. Users _might_ consider an Open Source version, but switching people away from familiar tools is not easy.
It sounds like the Ant perspective is "you can just ask claude to plan", but at the same time that's a little more tedious than shift+tab
Goomba fallacy. These are two distinct groups of people.
Maybe it's me (it usually is), but I don't give an LLM small tasks that a human could knock out in a half-day. I give them big tasks, stuff that would take a human a few months to a year - and then I ask it to give me a plan, as a living document, and we spend a good hour or two iterating over the plan.
Then, when its finally at the point where I'm happy with the plan, and I've talked it down from wherever it first wanted to go, or pointed out that we don't need to be all-things-to-all-(wo)men and focus is important, I get it to start going through it.
Likewise, I get it to maintain TODO.md with lists of known bugs, separate lists of future-features, and again, I make a rule that this file must be updated whenever something material changes. I just asked Claude "where are we ?" and got back stuff like:
The ## Still-open detail section lists two items:
- Task #1070: the ported back end doesn't fold offsets into vector loads, so it emits an extra add on 11 files (from 892) at -O3. The output is correct, just longer.
- Task #1080: array sizes must constant-fold. For example, u8 buf[EVSZ * MAXEV] is rejected because size expressions only accept a literal.
This is for 'xc' [1] - a compiler for an Objective-C-like language (but without the excessive []). The language has ARC, blocks and bound-functions/methods named 'block' and 'callback', automatic parsing of DWARF data so you can #use a shared-object, so there's no header files - just read enums/types/functions/methods from the shared object. It's a cross-compiler, runs on mac,windows,linux and creates executables for mac,windows,linux,ios,android,WASM (amongst others). I have a binary running on my iPhone which was written on, and signed on a Linux box - no Apple software used at all. Oh, and it produces code that is very comparable to clang in speed on both arm64 and x86_64.
You can appreciate it's a reasonably large project. It's taken actual months(!) [grin] for me to get working. Months! There's no way I'd approach a problem like this without detailed plans of what I wanted the language to do, where we were going with it
FWIW, "I" wrote blewit.net [2] entirely in xc - both the server back-end (#use <psql> was very useful for binding to Postgres) and the WASM client - which share classes between client and back end, to make it very difficult to get out-of-step between them. No Apache (#use <tls>), no scripting, just a lean-and-mean daemon talking to postgres via valkey (#use <valkey>) - a reddis-alike. Oh yeah, blewit.net has a plan too. Actually it has lots of planning :)
1: https://compile-xc.org/compiler/
2: https://blewit.net/
This has never not worked as expected.
I used plan mode for two reasons: to review the choices before execution, and to execute with another model (i.e., using the barely documented opusplan feature).
The grill-me skill is much better for reviewing and clarifying choices (and modifying it to use the ask tool makes you go faster). Instead of opusplan, you can explicitly tell Claude to start a subagent with another model to divide the tasks.
Qwen 3.8 27b is the supervisor
Qwen 3.5 4b are the 6-15 minions it controls
Gemma 4 e4b is the validator for the supervisor.
A plan means it preps all work for the agents up front, tests that evals work, makes sure the dev environment is right for each agent, then finds and fixes each before the distributed tasks even begin.
What I thought would take minutes took hours as a supervisor or one agent did the prep / pre flight work.
My solution so far has been to drop all but basic setup and force the supervisor to ask before every op - if this is not the design choices, can this be run in parallel? If so, hand it off NOW.
I'm still iterating this workflow, but less setup for all the minions plus handing them work that may be incomplete/ broken is caught and fixed by the minion and its own qa gates.
This can mean a number of minions end up replicating the same fixes, but in general the time cost of that is small Vs the supervisor working in parallel instead of too sequentially.
- Cold starts impact, context length issues, task lifecycle management
- Inefficiencies in delegation, necessitating workflow patterns for small projects (big AIs hide this problem until you scale and they hit the same issues).
- Limits of the AI would be harder to find or notice (e.g. where time - and cost - is being spent needlessly).
Some people are resource constrained.
Also, since sometimes an AI can be a busy beaver, I added instructions to not edit any checked-in files if the prompt contains a question.
“discuss your plan with me before implementing anything”
theres your plan mode
I get zero dopamine rush from this. I get a dopamine rush from building something or figuring something out myself. I don't get a dopamine rush for generating thousands of lines of code that I then have to try to understand.
I want it to go and read stuff but also invoke some commands and generate reports and discuss on the results. Latest GPTs in codex plan mode always go.. write a plan. Shocking, i know, but thats not what i want on every turn when im in that mode.
I mean, it is, and if that were the workflow I’d be very fed up of it by now, but the plan mode in Claude’s VS Code extension has supported select and annotate directly since at the very least early 2026.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.