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

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.

For me he plan mode is as useful as ever, even though I understand this is just a prompt. For large changes there are few problems exist such as context window limit and compaction, and even though models got better these are still detrimental to models performance. I found making one large high level plan and then splitting it into N plans grouped around distinct areas and then running N implementations if possible in parallel, or some consecutively, improves model "vision" far ahead. The workflow author suggests might be more useful for prototyping, but there are still types of work that are better done with massive pre-planning stages. And of course running exploratory prompt a.k.a. plan is useful even for smaller types of changes like small features or bugfixes.

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.

Personally I really like grilling before a big feature, it's a Matt Pocock skill that will iterate and ask you a lot of questions so you REALLY know what you are building. It's particularly good for complex and big changes, so you actually know what the AI is gonna build before it does. Of course, that's not always the case, sometimes you don't care about the specifics. But I think an integrated "plan mode" is really not needed, maybe a "brainstorming" skill would be more useful.

I still use plan mode. I use it for large features that I haven't fully thought out. Which I guess is like the author's "planning" phase. But I don't see the issue with using plan mode for planning. I welcome the agent to ask me for questions and clarifications. Do I read the full spec it produces at the end? Usually not. Usually the agent is smart enough to highlight the important tidbits and assumptions. I read those.

It's particularly important when you're making architecture changes or things other features will need to build on top of. I want to know what libs its going to use. The nitty gritty details I don't really care about.

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.

For an adhd mind that serial interface is a bless and hell at the same time. Great for the detailed planning discussion, bad for checking the results.

I am currently working on canvas-based interfaces for that reason and i would think the only way to really create value here is with a deep independent analysis and visualization of the changes afterwards to reach some ease of mind. Live would be cool (if you like that)

When it comes to planning itself, I recently tried the token-saving planning plus phases execution agents approach and had to find out that agents actually don't necessarily communicate better by prose-reduced specs than we do.

I had to go back to the planning agent to implement or fix things with our full planning context in mind. So if you want really high control for a "tight" implementation, I'd say just sharing plans is not enough. The probability of things getting filled in by the executing agents rises and you either find yourself holding those agents' hands or fixing things afterwards.

Actually phases are still to large and you would actually want the planning agent to hold that hand all the time, meaning small context is not the way to go, as you might need the full checking context much more often than current phases sizes suggested by the planning "doc" would use it.

Distributed building still is the way to go though, steady control by the overall context or one specifically thinned out for the particular job is. But don't go prose-based plans anymore. These are dead indeed.

Anecdotally, in the Opus 4.6 days, it felt like there was something special about using plan mode to discover the approach then clearing the context to execute on it.

A mixture of defending against a disastrous mid-implementation compaction (where suddenly things would veer off the rails) and also allowing the fresh execution to double-check the assumptions and notice any subtle mistakes before context was poisoned.

I’ve found that for large enough changes I still prefer having a parent theorizing about the root cause of issues based on evidence and then dispatching targeted child sessions to fixed based on theories and concrete telemetry examples.

There’s something clean about having sandboxed context and a session you can quiz about architecture while one is heads-down working against a spec.

I found the article interesting in that the author didn't baulk at receiving an unchecked uncheck-able bulk of code. If this is what is supposed to ship, am I just old-fashioned to think this should not be acceptable? There is no way I would ship code that a person had not read, let alone written.

A quick straw poll. Are most people here who use AI to code well-versed in their languages/software development? i.e. 10+ years experience doing it "by hand"? I think in ten years time there will be no developers with that 10 years experience behind them.

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 rely heavily on plan modes, first to think through product design from the 3-sentence descriptions handed to me as super-complex feature requests, and second to implement the technical requirements I want to build. Way before AI, I think the first idea, while sparked by inspiration, has always created a local minimum and suggested that something could be done around a problem, but it was rarely the best idea. I think the speed at which the models can turn a bad idea into code will lead to bad, design across systems and interfaces. I am also very pedantic about how the data models get implemented, and I want to be sure that things are built in the way I want them to. I'm also very pedantic about how specific if statements and dicts are created, and again, the models make it easy to do things a shitty way. These are hard-learned lessons of several decades of shooting myself in the foot and locking myself into less-than-ideal design patterns. I spent two days going through designing and planning for the LLM to build the actual feature in less than 2 hrs; once it's set, it's lost. It has made testing go very quickly and i am deploying a very complex feature and high risk feature in a 4 days when without the models it would have taken probably 4 weeks to get right.

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 can’t imagine working without a plan first.

Firstly I find it’s an excellent way for me to get very good clarity about what will be built and whether it’s going to be done in a sensible way.

Very often I don’t really know what the work will need to look like until I’ve explored the problem with the LLM towards first making the plan.

Without a plan I find myself having to do the initial understanding through code review of its generated code which is much harder than reviewing a plan, and then I invariably need the LLM to fix up what it did which is much slower when it’s doing code than working on a plan, never mind the next review I need to do.

And when the plan is good enough, I clear the context before telling it do it, which I’ve found vastly improves the quality of the LLM output.

For me the most useful thing about plan mode in Claude or Codex is not the plan, I usually barely read it, it's that it forces models to gather as much context as possible before implementing. Without plan mode models tend to implement wrong solutions because they are reading not enough context before writing code.

Another useful property is the readonly nature. I can easily let multiple agents plan in parallel without having to worry about annoying worktrees or conflicts and then I can come back to the plans later.

Of course this can be done with just another prompt, but that's exactly what plan mode is. It's nothing more than a predefined prompt in the harnesses with maybe some extra guardrails (that don't always work)

I once tried to build something similar to your product on top of Codex, and I failed.

But my conclusion on plan mode is slightly different. I agree that plan mode itself may be a dead end, but I still believe there might be another way to achieve the same goal.

When I was building my product, I found that the biggest issue wasn't capability, but taste. The agent could build something that worked, but it often wasn't what I actually wanted. And behind that "taste" is a huge amount of implicit context — preferences, past decisions, product intuition, and trade-offs that live in my head. Distilling all of that into context takes a lot of effort, and I suspect giving it all to a single agent may eventually become overwhelming.

I've been wondering whether a better approach is to have multiple agents with different roles, prompts, and perspectives, and find a way for them to work together efficiently.

It's still just a hypothesis though. There are a lot of complicated coordination problems to figure out, and I don't have the answer yet.

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.

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.

It is? I still found it invaluable, when having a lot of externally managed knowledge. Basically the only gate before it goes on a certain failure, when dealing with proprietary libraries, tools and services

So planning is tied to the spec. This much is clear.

What the author I think is hinting at is not planning alone but "the development and evolution of any program and the state of this program throughout the planning, elaboration, and eventual runtime".

I chuckle at the thought that throwing an md file or a prompt at this problem is sufficient.

So, I posit that if we want any agentic code to evolve meaningfully in the short future and over the long run, we have to have a system which holds and presents this information, the state of a program, in a coherent manner to a human operator. No other way. No other way. And this I say to both nay and yay sayers.

You can argue also that this is part of an even bigger thing. But it is not part of the current discussion on planning and speccing in agentic systems.

OpenAI and anthropic can throw all the billions they don't have at this and adjacent issues, but if this is not solved then they don't have anything.

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.

I still find plans to be useful for big changes. I first ask to create a plan for the specific feature i have in mind. Then i ask for a second round of research with the current project in mind. Then i ask if it can make improvements on the plan. Then i read the plan and note issues down and let it correct them.

In my experience the problem with plans is that llms (at least gpt and claude) are really lazy and will stop at the first solution without even understanding your project. I had plans that wanted to add a few thousand lines of code just to support a very minimal part of a feature. After asking for a second round of research with the project specific limitations in mind it recommended a very small change to the existing codebase that did the same thing.

This is probably also the reason why most llm generated code stacks thousands of lines of code.

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?

Planning largely doesn't work because it's extrapolation. You don't know for sure how that remote system or compiler will react to the proposed change until it actually occurs.

Execution is the answer. All the complex success stories I've seen involved the LLM iteratively probing live data sources with varying filters, throwing code changes at the compiler over and over, or invoking shell commands until it succeeds.

I believe there is a Yoda quote regarding this.

For work, I primarily use Gemini CLI, and the one real awkward part of plan mode is that the harness can't run commands, even exploratory ones. So when I'm giving the harness a task in plan mode, it can't experiment and is either blind or relying on its training data and/or any other context (e.g. source code, documentation) I give it. And it often gets things wrong operating that way (depending on how detailed the context ends up being).

For example, the ability for the harness to call into a Python one-liner just to experiment is pretty powerful. If I'm asking it to use D2 to build an SVG graph, it can write some Python to introspect the XML to see if things appear to be placed correctly (size, x-y coords, etc.). Which is a pretty cheap way for it to experiment and verify its results before I deign to examine the rendered SVG with my own eye balls.

Plan mode is for me not the agent.

I also bounce around to lots of different models. Some are cheap and dumb, some not. When unfamiliar with a model, the last thing I want it to allow file edits and destructive tool calls. Having a mode explicitly for that is helpful.

I disagree that more intelligent models make plan mode no longer useful. Even with superhuman AI, I would still like to iterate on a plan and understand all the important decisions before changing the code. AI cannot read minds, no matter how intelligent it is. Hell, often I don't even know exactly what I want before the planning phase is finished.

And yes, you can say that I can do this without an explicit plan mode.. But it's such a useful and common workflow that it deserves a special mode, IMHO.

I've been using superpowers:brainstorming skill with claude for a while and have found the process to work well for me. I generally spend 10-30 minutes typing my requirements and ideas for a feature and then I feed it into brainstorming skill which asks questions to fill in the gaps before starting to build things. I don't bother reading the spec it creates. I have been consistently happy with the results.

However, since everything changes every 5-minutes now; I am curious what is now a better process than using superpowers? What works for you?

I use plan mode for anything that touches more than 2-3 files because I want to know what code will be added beforehand.

I guess people don't even look at code anymore

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.

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.

At work, we use Claude Code with superpowers which organizes most work into planning followed by review followed by implementation and superpowers applies a fairly high level of scrutiny at every step. It's really quite effective, I don't generally read the code that comes out. In that workflow I have never used plan mode. I don't know what I'd use it for.

On my hobby projects I use Antigravity CLI and almost always start with /plan. This is a builtin skill - not a mode. It generates a plan artifact that I review and approve. Once approved the implementation speed is uncanny compared to Claude.

I tried using superpowers with Antigravity CLI but that slowed the agent down considerably without much benefit (plan quality was much worse).

I feel old. These days any new thing I try is dead by the time I actually start using it.

I work on long horizon scientific tasks with expensive computational tools. In that case users are basically asking for the harness to stop and confirm the cost (and plan) before it goes ahead

Fascinating piece, puts in words what I've been feeling for a while..

Over time I found some useful patterns (indeed after not getting what I want from plan mode), but this piece convinced me to double down on them and always try to find (and let the LLM construct) clarifying abstractions that have a deterministic relation to the code.

2 examples I recently build while I'm developing a large Django system with a complex datamodel and RBAC (spending quite some time to make it look good):

A script that makes an svg of my data model with all the classes/tables laid out and their relations encoded in the line ends (1 to 1, many to 1, many to many) and their on_delete relations encoded in colors. This also helps me discuss with stakeholders. The visual is also in the README.

For the RBAC model I decided it should be declarative so a TOML in the code that seeds the DB with the roles. I quickly landed on small script that translates the TOML to a markdown table with roles as columns and perms as row. It's also in the README.

After reading this piece I'm going to actively think how I can build these visualization more often and consciously, on different levels. Great realization.

I’ve been waiting for some kind of steering mode.

Imagining a mode where the agent is very transparent about its direction and process, and I can passively interject at any time to steer the outcome, without having to wait my turn or hard-interrupt.

It's quite interesting. I use blend mode pretty heavily. On both claude code and codex.

But it's no longer to plan a single PR that can be done easily without plan mode.

It is mostly because I am more geared towards having my system work on initiative level changes where it works for days and plan is a good document to maintain to keep the agent aligned with the original goal and avoid unnecessary drift.

In Claude Code it started to feel like it just asks 2 questions and sometimes there isnt really needed 2 questions so the options there often felt like choosing to downgrade or do something actually dumb because it was forced to suggest 2 things.

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.

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.

I'm using a set of skills for planning now which does something similar to plan mode but it's creating documentation that later skills reference it while building. It works so much better than anything else I've tried, because it keeps things on track throughout the feature buildout and across different agents/models/tasks. From what I read here (& in general) my take is that a lot of people haven't adopted something like this and it's just totally the wild west right now as everyone is cooking up their own flows.

I agree that as I move away from holding agents' hands through actual coding I need a different way to monitor what's going on. What step of the plan are we on, what are the tests actually doing, what agent owns what, etc. I haven't found a product that does a great job of that yet and it seems like the next frontier of the 'IDE' to me. It'd be more like an IM(management)E really. The closest thing I've seen was whiteboard [0] but I didn't have a great experience trying it out.

[0] https://dev.fast

YES, and I also find that plan mode incentivizes bad practices and results in steadily reduced thought. On bad practices, I refer to zero/one-shot big bangs over iterative features/bugfixes. On reduced thought, assuming the plan was sufficiently comprehensive because it seemed to ask reasonable questions.

It can still be used in ways that I personally consider correct, but I think the parts I personally consider incorrect are so inherently alluring that I find plan mode to be an overall net negative for software development. I celebrate its apparently impending default removal (at least Claude Code and OpenCode are openly stating that they think it's time for it to go).

My own tool has a Project Starter, that takes users from idea to todo list in a number of very specific phases. I've been using it for small to medium sized projects for a year now and it still works great for me.

Just don't expect to end up with a finished project; it's more like a first draft. Once it's there, it's much easier to determine what it is you actually want, since you can directly experience what works and what should be changed.

One important caveat is that I do not work with agents; each step goes through a fairly rigid manual review phase.

I think with Claude Code plan mode has value even if Fable “gets it” off the bat. It’s a chance to explicitly disambiguate intent through AskUserQuestion tool as well as utilizing the option to clear content when plan is approved. The automatic disambiguation step is RLHF’d out of the model even when it’s needed.

I have been using this super simple skill[0] to make Claude ask exhaustive questions about the implementation of larger features. It has been absolutely amazing and felt like a step change in the output quality.

For complex features there can be 10 or more questions but I have a very strong sense of understanding the changes about to be made and Claude is very good at following all the decisions exactly. It's like working with an engineer who is both excellent at soliciting requirements and fast at implementation.

[0]https://github.com/mattpocock/skills/blob/main/docs/producti...

I will try to update this repositorysoon, but I had to stop because the ahem compatibility failure of Claude Code env features; observer; agent workflow message passing LACKING on installed marketplace plugins

I am still actively working on thesis : a self-directed plan mode to generate artifacts that can go through multiple evaluations of interactive interrogation is valuable

https://github.com/samelie/claude-plugin-pnpm/blob/main/skil...

> We still haven’t solved how to help people stay oriented as hundreds of increasingly capable agents change a system at once…

Building an issue tracker that addresses this. It can replay the workflow after the fact like a movie, and pin down the parts that require human input via tagging and inline diffs in the tickets. It is git-native, lives in your repo alongside the code doesn’t require any external service.

https://ljtn.github.io/epiq/

I'm going through the same problem right now

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.

A bit late to this party but what the heck.

I too have started using plan mode less, mainly for two reasons: 1. I plan my prompt more carefully and think about architecture up front 2. I found with more recent powerful models, the clarifying questions were generally not useful because it was pointing out issues it obviously knew the answer to and would have resolved in implementation anyway. So essentially they became time-wasting and anxiety inducing for no good reason

The mental shift I made was to not accept poor understanding of a code base on my part when writing the prompt - if I don’t understand it, I can’t predict what assumptions the model will make even on a basic level.

I used to tell myself that plan mode mitigated that, but I usually ended up mentally glossing over the generated plans anyway.

That just resulted in pure anxiety-driven engineering, where I’d often spend extra cycles verifying what was built and worrying about the design.

So invest the time understanding the system, at an appropriate level. That level will change over time as models get better.

I am not so sure honestly. You can still wreck a codebase if you don't plan because the ai can make assumptions you don't want, or as other people say it's all a matter of taste

I find it interesting that what the author arrives at is the OODA loop.

The final form became: understand → act → inspect → clarify → adjust → act again

But he says that "understand" isn't really fitting (or something like that), so we are at: act → inspect → clarify → adjust → act again

That can be understood as "observe, orient, adjust, act" - but with other words.

That is the method to use when you are IN the sh*t rather than removed from it and making some theoretical plan.

I thoroughly enjoyed the read <3

I don’t agree. I think the way maybe the author used planning to maintain an understanding of the changes is largely not necessary, but there are other good use cases.

For example, it’s a great hook in the process for agentic review.

Get a second agent to look at what will be implemented and check it for inconsistencies, check it against whatever decisions were made or provided previously in the chat, or against whatever technical rules you’ve written out for your project, before going ahead. It surfaces a large number of opportunities for refinement, and generally pushes the output closer to the direction you’re looking for.

Yes, a conversation can be the plan. It helps if you ask it what the commits will be and then tell it to use subagents to implement them.

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.

Plan mode is not dead, it just moved to OpenSpec and other similar tools.

If you’re not using those either… I pray for your codebase.

I have rules.md read on every start of the session, in which some of the rules are:

Never start coding befire I say codenow, and add datetime. Before patch explain in plain English what it does. Each file has datetime added to the top of the file, and updated if exist. Each file has a backup copy, created with name.datetime and checked after patch vs backup file, and again with new .backup file for logic vs new backup

I also noticed this personally. Consider when an agent says

"Should I start with the spec, or go straight to building it?

Unless you're working on a super crucial piece of engineering, you can probably get away with going straight to building it. Even if something doesn't go the way you intended, I find that it's usually faster to correct the agent later, once the initial implementation is in place. It's more of an iterative approach to building and I feel that it is less cognitively demanding.

I haven't used plan mode for a long time. I do still plan, I usually ask claude to make a plan with me first an explain how it will work, then I iterate with it until I am satisfied and then just let it go. So far it has not started implementing on it's own before I told it to.

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.

I think Plan mode is very useful when building something that needs step by step validation, but also needs a broad strategy before starting.

For instance, in games where I work, we often need to manually test work out by playing or by using tools in ways that aren't feasible for the AI to do. In that case, getting the human in the loop between steps is an organized process when it's following a staged plan.

My problem with planning and having the models ask the user questions is that the questions the models ask are still often irrelevant: you’ll find yourself answering a bunch of questions like “Should I use the existing system or create a whole new one in a different language?” - yet it will then make assumptions about other things that were actually ambiguous.

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 curious if anyone has used automations for any kind of regular refactoring and cleanup tasks? Most agent guis support it.

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

Still working on and with this but had to move it private because marketplace installed plugins loose capability

https://github.com/samelie/claude-plugin-pnpm/tree/main/skil...

Switched from opencode to pi and I do kinda miss planning mode. I like spending a bit more time in that phase and having multiple providers LLM look at the spec doc etc

That’s very much coming from a desire for improved quality than understanding though

I have noticed this in practice the past month. It’s interesting because goals and plans are obsolete. Skills too.

Much of what distinguished a knowledgeable AI dev a year ago is now an anti pattern.

The second I discovered the plan start hook I hijacked it and replaced the built-in planner with my own. The built-in planner is useless.

It's been a while (well, 8 months) since I used Claude Code, but what I can say is that I greatly enjoy using the plan mode that comes baked into omp (oh my pi), especially for tasks around firmware development. I recognize that has a very different workflow than webapps though.

I dont know about Claude Code, but I'm using Amp Code since November 2025 and it don't need the mode at all, just conversation.

The Planning vs Plan is the core of the post.

“Plans are of little importance, but planning is essential” - Churchill

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.

Use instead:

   npx skills add mattpocock/skills --skill=grill-me

   npx skills add imbue-ai/blueprint

Maybe we need to figure out how humans should communicate with AI

> how do humans maintain a coherent mental model of a software system

This is the core question and it is wrong. Because it focuses on the software system rather than the problem you are trying to solve. A better version would be:

  How do humans maintain a coherent mental model of the solution they want to create?

It seems people will never tire of finding out that writing code isn't the hard part of making useful software.

>We still haven’t solved how to help people stay oriented as hundreds of increasingly capable agents change a system at once.

Engineer, meet business school.

I disagree I want a proper read only mode, a lot of times models are still trigger happy.

i disagree, i think it is very useful to have the ability to ask anything about the code and have the confidence that it WONT execute supid stuff

I generally only work with the default claude auto and see that it does pretty well for my needs

Ironically enough Google Antigravity added plan mode this week.

I would have assumed plan modes make use of tools to keep the goal/plan persistent across compaction etc. Is that not the case?

I totally disagree. This perspective only works if you don't care about token cost.

I'm using Astra for some homelab work and I tell it I want to do something and then it burns through a giant percentage of my 5-hour allowance (on the £20/mo subscription) doing that in a really weird way. I've had to tell it to stop zooming off and doing things, calling loads of tools and looking up websites, and just have a quick conversation first. It's much better now, but I've basically just reimplemented plan mode via AGENTS.md.

In other news, Antigravity (the one that isn't the IDE or CLI) just added plan mode: https://x.com/antigravity/status/2103611698800140697

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

Cool article from a cool founder. Her other posts are great.

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.

yeah plan mode never was really alive to begin with

i find astra's every other message is a small plan, and i have to confirm for it to go

I don’t think it’s dead at all. I use it as a phase transition to let the agent decide when discovery is sufficient, as an intermediate phase between that and implementation. Even as a human dev you rarely go tinkering with files all over without first forming a plan.

why do you even need plan mode?

“discuss your plan with me before implementing anything”

theres your plan 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.

Waterfall is dead. Agile iteration is the future.

That’s the amazing realization?

"AI-generated text is painful to read"

We experienced another step function in model quality over the summer. Models are now one-shotting medium sized tasks that require significant engineering judgement. We're moving into an era where the production of software will be done entirely by machine, requiring only an abstract description of the need the system is to fulfill in business language. This has been the goal since the 1970s. "Plan mode" isn't necessary when the model can suss out what you need from a few sentences of prompt and make competent engineering decisions to fulfill that need.

Brooks was wrong. We have a silver bullet now.

Maybe, I always say "let's write a plan and refine it" which ends up being a nice rubber duck session to keep claude and friends from going off the rails implementing things like privacy or encryption or some other rabbit hole when I just need it to do a few features at a time so I can review while it starts the next few things. Maybe this is slower to deliver, but I don't spend a lot of time unwinding commits.

I don't necessarily use plan mode explicitly for this, but I might turn it on if I think something destructive is coming up, like a schema change or some other devops thing where claude may decide "oh we copied it all over so I can delete it from source" "oh I'm sorry I didn't catch that error code and assumed success, your data is now gone" lol. This happens a lot less but I've been bit right on the face by it before.

Are plans the wrong abstraction? You can use a big enough plan to spam tickets into linear and have claude burn them down. I find it increases subagent accuracy.

hard no for sufficiently complex existing codebases. even astra misses nuances in my moderately high loc app. plan, then implement is much better and, more importantly, much safer. at least i review the plan.

I've been working on a custom orchestration system which starts by creating an overall work plan, then splitting up development tasks among agent/model combos depending on their capabilities/expense, then coordinating their output, testing, etc. with various adversarial agents acting as gates throughout the process. It's really satisfying to watch the task board as agents go through their little routines.

It's been an absolutely fantastic way to set tokens on fire and watch them burn, and produce pretty much nothing of value.

[flagged]