I recently came across a post on Hacker News that said plan mode is dead. One of the reasons I like plan mode is that it maps out what the AI is going to do before it jumps into action, burns through a lot of activity, and eats up a lot of tokens, especially when you’re working on an existing project.
It’s also a bit of insurance against the agent doing something you didn’t intend or misunderstanding what you meant. In that way it keeps what you want the coding agent to do aligned with what it understands you want it to do. For that, I think it still works to some degree. It also helps you understand what you’re building, which decisions are being made, and why they’re being made that way.
The author of the post wrote:
“While the ease of generating code this way triggered a greater dopamine reward, it obfuscated the uncomfortable work of understanding why building something mattered, whether it mattered at all, and rigorously evaluating product design and infrastructure decisions.”
Planning has to be iterative
Planning needs to happen in the right phases, and it needs to be iterative. The author describes this very well. (He mentions Nuanced here, which was his product: a planning add-on for AI coding tools.)
“Real thinking doesn’t happen this way, and the separation between these parts felt artificial and forced. Usually you’ll understand a part of the problem, try something, the initial generation teaches you something new, which might make you change your mind about it and try something else. Each step exposes a new question. Planning and building are interleaved and emerge more organically than plan modes allow, especially how we built it in Nuanced. Our interface forced users to prematurely “finish thinking” so that they could start building. Once implementation began, returning to the earlier chat-based reasoning felt like moving backward in the workflow. There was no going back up the waterfall.“
When a plan meets reality, especially several steps into the implementation, the plan needs to adjust. If you plan everything meticulously up front and then insist on executing it exactly as planned, the gap between how the project actually develops and how the plan imagined it would develop gets bigger and bigger. You need an iterative planning process that doesn’t look too far ahead.
The author then describes how the way AI coding tools work has shifted as they’ve become more powerful and capable:
“When you look at how Codex currently works, the boundary between planning and execution is disappearing as they collapse into one. Earlier on, coding agents benefited from the workflow where humans would do the following:
plan → approve → execute
Back then, the cost of going in the wrong direction was significantly higher. But as agents got better at understanding systems, they also got better at acting autonomously and testing their own work. They’re also good at revising their approach after inspecting the result. This enables a different loop:
understand → act → inspect → clarify → adjust → act again
There is still an enormous amount of planning happening inside that loop, but it doesn’t necessarily need to appear as a document called “the plan”.“
How a 10x coder actually works
I couldn’t help but think of a friend of mine who is absolutely what Silicon Valley calls a 10x coder. I watched him work with Codex, and his prompts were so simple. Literally stuff like “fix this” or “why is this broken.” He offloaded the bulk of the work to the coding agent.
Every once in a while he would look at what it was doing, skimming it rather than reading the entire output. And every so often he’d catch something, mostly an architectural decision the agent had made, and say something like: “Don’t do this. This is completely unnecessary. We can do this much simpler. Just use…” Then he’d suggest some other tooling that I didn’t understand, because I’m not technical enough. For him it was obvious.
What I did notice is that most of his prompts pushed the agent toward simplifying how it did things.
Boris Cherny agrees
On Hacker News, Boris Cherny himself chimed in with a comment that I’ll quote in full:
“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.“
Where I land
I’ve definitely found myself less and less satisfied with plan mode lately. Still, it mostly serves as a way to align my intention with what the coding agent will actually do.
One thing I believe to be true: plan mode is more useful for non-technical users like me, who don’t have a fundamental understanding of how all the technical stuff works. A good developer who understands the inner workings of the machine probably sees the right path intuitively and can articulate it with more clarity than someone who doesn’t.
I do find the methods Boris shared very interesting, though. Asking Claude to generate an artifact that explains some aspect of its changes, asking for diagrams or even interactive demos for complex diffs to core parts of the system so you better understand the change and the alternatives considered, and then attaching those artifacts to the PR is a great idea.