[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.
> 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 me it’s actually the opposite, and Claude Code’s plan mode isn’t nearly sufficient. Personally I ask Claude to write down a markdown file with its plan, then review the plan using plannotator, and then go back and forth (most of the time it’s actually the comments that are the problem, not the code).
Then start a fresh session, seed it with the plan, tell Claude to find ambiguities / friction points / oversights, resolve those, and then implement it.
Review once again with plannotator, go back and forth, and then send PR.
Maybe not the “vibe coding” that was once imagined, but this does ensure I am fully aware of the code and architecture, the quality, and this also prevents long term degradation.
> (most of the time it’s actually the comments that are the problem, not the code).
I wonder if it's just a consequence of a gigantic training set full of comments completely out-of-date with the code, leading to the model considering this "normal"
I don't usually see Claude leaving comments that are obviously out of date compared to the code. The problem is that the comments are just a dumping grounds for Claude's stream of consciousness, verbosely recording random bits of history and context that are true and at least somewhat relevant, but without cohesively explaining why the code is the way it is. And some sentences in the comments will be beginner-style restating what's obvious from reading the code.
Exactly. Comments are basically its scratchpad for whatever it wants. Ask it to change a number in a TOML config and it'll also add 2 new comment lines above it with some Claudeslop about it being changed and what that accomplishes, as a useless note to itself.
I now make sure to do a big decommenting pass before every PR.
This kind of stuff annoys me too, and I have instructions in agent.md to avoid it, which helps.
But I also am starting to just let go and stop caring. It’s not clear to me that it causes problems down the road, it’s easy to strip out en-masse if needed, and in my experience, agents now are really good at read git blame, the commit log, even prior agent transcripts if available to sleuth out when a change was made and why. So yeah, it’s annoying, but the code agents write for me is increasingly never read by a human, so does it matter?
This. Be honest: who reads the human-written comments? ;)
When I read, I skip most comments, especially the larger "Javadoc" style. My brain sees them colored differently in the editor and it doesn't even take mental effort. Then, when I have a question about the code, I look back up for a relevant comment. That doesn't happen very often.
If Claude writes great code and leaves a garbled Claudese-but-accurate comment ... I can read and comprehend (with like 5x the effort of a human comment) ... that's a small price to pay.
Yes, comments might be my biggest gripe with CC due to what you said. 9 out of 10 of my revisions to Claude's work is deleting or rewriting comments. Such a silly thing for it to fail on.
(I do have detailed instructions for it on how to comment (or not) but it has not fixed this.)
Nah, it’s the typical Claude-isms, and way too much info, info in the wrong places, and putting lots of planning discussions into comments that are completely irrelevant.
It’s always “you explain only what but not why” or “this is way too much prose” or “these comments don’t belong here, they should be inline comments” or “this is completely redundant as it’s already obvious from the code”.
I do find that once I beat it into submission and the codebase is “clean”, the new code it generates gets better and better, which makes sense gives its pattern-prediction nature. But it seems like there is work to do for Anthropic in terms of getting Claude to not confuse code comments with dumping its interactive discussion state into there.
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.
stingraycharles · · focus · HN ↗
For me it’s actually the opposite, and Claude Code’s plan mode isn’t nearly sufficient. Personally I ask Claude to write down a markdown file with its plan, then review the plan using plannotator, and then go back and forth (most of the time it’s actually the comments that are the problem, not the code).
Then start a fresh session, seed it with the plan, tell Claude to find ambiguities / friction points / oversights, resolve those, and then implement it.
Review once again with plannotator, go back and forth, and then send PR.
Maybe not the “vibe coding” that was once imagined, but this does ensure I am fully aware of the code and architecture, the quality, and this also prevents long term degradation.
jcelerier · · focus · HN ↗
I wonder if it's just a consequence of a gigantic training set full of comments completely out-of-date with the code, leading to the model considering this "normal"
wtallis · · focus · HN ↗
meowface · · focus · HN ↗
I now make sure to do a big decommenting pass before every PR.
senordevnyc · · focus · HN ↗
But I also am starting to just let go and stop caring. It’s not clear to me that it causes problems down the road, it’s easy to strip out en-masse if needed, and in my experience, agents now are really good at read git blame, the commit log, even prior agent transcripts if available to sleuth out when a change was made and why. So yeah, it’s annoying, but the code agents write for me is increasingly never read by a human, so does it matter?
hungryhobbit · · focus · HN ↗
When I read, I skip most comments, especially the larger "Javadoc" style. My brain sees them colored differently in the editor and it doesn't even take mental effort. Then, when I have a question about the code, I look back up for a relevant comment. That doesn't happen very often.
If Claude writes great code and leaves a garbled Claudese-but-accurate comment ... I can read and comprehend (with like 5x the effort of a human comment) ... that's a small price to pay.
theritik12ee1 · · focus · HN ↗
[dead]
sfjailbird · · focus · HN ↗
(I do have detailed instructions for it on how to comment (or not) but it has not fixed this.)
Shadowmist · · focus · HN ↗
stingraycharles · · focus · HN ↗
It’s always “you explain only what but not why” or “this is way too much prose” or “these comments don’t belong here, they should be inline comments” or “this is completely redundant as it’s already obvious from the code”.
I do find that once I beat it into submission and the codebase is “clean”, the new code it generates gets better and better, which makes sense gives its pattern-prediction nature. But it seems like there is work to do for Anthropic in terms of getting Claude to not confuse code comments with dumping its interactive discussion state into there.