Plan Mode Is Dead: Why AI Planning Tools Failed and What Comes Next

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.

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.

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.

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.

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

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