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.

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

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.

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.