Either way, plan mode isn’t going away. You can always /plan or ask Claude to enter plan mode. We might re-map the shift+tab keyboard shortcut to something else by default for people that don’t use plan mode.
Strange response. I agree with the parent comment here, plan mode lets me ensure that I have specified everything correctly before it gets built which is far too late. I don't see how an improved models even matter to this workflow. Is Fable going to read my mind?
Boris is saying that you don't need /plan to get the model to plan, you can just say "Let's plan this out" or similar, which at least matches my experience. Your experience may differ, of course, but it's not even clear we are talking about the same thing.
Maybe some people have not been long enough on this rodeo: This used to be an actual issue. You told the model "DONT START CODING YET" and yet, surely enough, starting to code it did. That is what /plan etc were supposed to fix.
Sounded to me like you need a plan.
My approach is to take the statement of work or problem definition and iterate on that myself until I'm really clear on what is the goal. I therefore have a good some good ideas about what the plan should be.
If extending an existing application, which is usually the case, then make use of the plan documents that I had written before AI arrived on the scene. These sre documents in markdown form that say step-by-step how to, for example, add a new report to the system.
It makes some plausible choices and you can retroactively ask it to make different ones later, if you want.
This hasn't been my experience.
> Or it will litter the code base with defensive code and comments about the path not chosen.
I've definitely seen this, though.
Basically every big tech company maintains "codebases with millions of lines built upon decades." Talk to your friends at a FAANG and ask them how they're using Claude/Codex.
Merging after reading the PR description is just how it's done these days, and if you can't do it reliably, your harness, devloop, or model is simply behind the times.
But you're doing the same with your "how it's done these days".
These days things are done in many contradicting ways, and it probably will take at least a few years to settle on common normal.
I mean, you're discussing this with a marketer/someone wearing a marketing hat, who works for a company which needs people to use as many tokens a possible. That's their reality
I see you didn't disagree with the main thrust of my post.
You'll also note their 'About' is empty. Regardless, engaging with HN in this manner is de facto marketing/PR. Trillion dollar companies don't just let anyone post on high-profile social media websites for any length of time without permission from marketing/legal/PR.
Which is fine because it just put together a plan and didn't spend 10 minutes rearchitecting everything.
It tends to be small decisions way down the stack that bubble up, or an incoherent data model that can’t handle what you’re asking for cleanly.
Eg I was messing with a state tracker the other day. The state tracker assumes a container is either currently running, or fully removed from disk.
The LLM chose to remove the state file when the container is stopped and then to remove it after, which leaks container storage.
The LLM is kind of stuck though, because every option other than “rewrite the data model” has negative outcomes and it probably violates user expectations to launch a massive rewrite there.
0. https://github.com/mattpocock/skills/blob/main/skills/produc...
/plan is still useful, I still need to review what it's going to do and still make revisions. But there's two phases: hammer out key design decisions then write and amend the document.
If I knew exactly how I was going to build something, I would have built it myself. But since there's some ambiguity in the portions of the project I'm less familiar with, I rely on the plan to not only help me understand the decisions Claude has made for me but to keep Claude constrained to the decisions I've made. It's very frustrating to waste tokens on having to refactor something because
> But for larger things, I try to take a waterfall approach with well defined milestones.
> If I knew exactly how I was going to build something, I would have built it myself
Aren't these contradictory? If you don't know exactly what/how to build, how can you do waterfall?
1) "Maybe waterfall works now" - plan mode, take care of all the nits and issues that the bot leaves on your PR, wildly overengineered "enterprisey" solutions with a lot of bells and whistles all over the place but very poor end-to-end user story test coverage that results in user experiences with a lot of good test coverage of the edge cases of how a given step might fail but little thought towards overall user flow and throughput. Because part of the issue with waterfall was assuming you could design the right tool for your user up front.
2) "Maybe code doesn't matter anymore" - The just ask for something when you need it approach, which results in weird janky individually-sorta-working but strangely-overlapping six-variants-of-the-same-thing that makes it hard for your users to develop a single consistent mental model of the thing they're using, and that changes super frequently.
They both end up with a lot of other bad-for-velocity things that I assume are inherent to how the tools have been refined in response to last year's criticism, too. Super verbose comments. Extensive - without much eye toward runtime - low-level test coverage that might miss the forest for the trees and also slows down the next round of iteration cycles. A plethora of new proper nouns all over the place that make the documentation an ouroboros without a good entry point.
This is weird to ask because I feel like of course the model isn't omniscient? Isn't the whole point of iterating on a plan to assess impact, risk, know your (the user) variables, user impact, product impact, etc for making a change? I cannot count the times even in the past few months where I start a conversation with my C suite because their desired outcome would have a potential negative impact elsewhere for other products or users.
Is this just not something that comes up at Anthropic?
It would be nice if with new model releases claude code also gave a bit of a model 101 that tells you evolving ways of prompting it that the insiders have picked up. I know there’s the prompting guide in the claude docs, but this is often very broad and most people don’t know about it.
I absolutely see fable and opus 5.5 misunderstanding intent, but that just seems to be a feature of necessarily underspecifying in a written prompt. Just today, I gave opus 5.5 a simple task to spin up a new environment for work. It read the ticket, which was decently specified and knowing the codebase as well as "Ghasp... reading the code" I had to correct it about 5 times to do it in a way that I would have expected it to. Getting the pipelines right, environment variables, and configs. It was all relatively straight forward imo. Then I had to prompt it to clean up its corrections, because it left a workflow variable in the github action that some intermediate step required but the final solution didn't. I definitely would not have caught that if I didn't read the output. Idk, there seems to be a natural limit as to how much it can infer and I have no idea how to fix it. I did write about it [here](https://javiergonzalez.io/blog/the-assumption-problem/) though.
OP wasn’t even actually critical of LLMs, they were just saying that plan mode was helpful to stop the model from making incorrect assumptions when you want you don’t specify everything you should.
Summaries that don't tell me when it's changed direction in a timely fashion, but I am only told way later, when I have to undo. Really bad judgement calls regarding where to fix bugs, changes in implementation decisions, taking action when I am asking a question directly, not passive aggressively asking for action... when 5, 3 days ago, was proven to be untrustworthy, switching to very little supervision sounds like a strange thing for a customer to do.
5.5 and 5.1 have major Rain Man (savant) syndrome. Excellent at many hyper-technical things, absofuckinglutely boneheaded at anything that a human (or an earlier model) would understand - like how to write copy, what a human would expect in a given situation, various types of norms...
it's infuriating because it's a sophies choice - dumber model but better human understanding, or better technical model that you have to explain things to over and over like a toddler.
I greatly prefer this, since it lets me iterate on the plan with Claude for a while without it repeatedly asking if I’m ready to implement the plan.
Once I’m satisfied, I usually start a fresh session and tell it to implement the plan.
For smaller plans, you don’t need the file. Just ask it to come up with a plan. I don’t recall the last time it just started implementing if I only asked for a plan.
It wastes a ton of tokens as well and those are not cheap.