[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.
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.
* Only, then can I review it and send it it.
Said MCP server (missing the actual ops): <a href="https://github.com/clops-mcp/clops-mcp" rel="nofollow">https://github.com/clops-mcp/clops-mcp
bcherny · · focus · HN ↗
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.
SkyPuncher · · focus · HN ↗
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): <a href="https://github.com/clops-mcp/clops-mcp" rel="nofollow">https://github.com/clops-mcp/clops-mcp