HN

Comments (182)

• Menu

  bcherny
  [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.
• Menu

  taurath
  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.
• dbojan
  I have rules.md read on every start of the session, in which some of the rules are:Never start coding befire I say codenow, and add datetime. Before patch explain in plain English what it does. Each file has datetime added to the top of the file, and updated if exist. Each file has a backup copy, created with name.datetime and checked after patch vs backup file, and again with new .backup file for logic vs new backup
• pcblues
  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.
• Menu

  tcdent
  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.
• recroad
  “Plans are of little importance, but planning is essential” - Churchill
• bityard
  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.
• alightsoul
  I am not so sure honestly. You can still wreck a codebase if you don't plan because the ai can make assumptions you don't want, or as other people say it's all a matter of taste
• stephen_cagle
  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.
• loveparade
  For me the most useful thing about plan mode in Claude or Codex is not the plan, I usually barely read it, it's that it forces models to gather as much context as possible before implementing. Without plan mode models tend to implement wrong solutions because they are reading not enough context before writing code.Another useful property is the readonly nature. I can easily let multiple agents plan in parallel without having to worry about annoying worktrees or conflicts and then I can come back to the plans later.Of course this can be done with just another prompt, but that's exactly what plan mode is. It's nothing more than a predefined prompt in the harnesses with maybe some extra guardrails (that don't always work)
• biimugan
  For work, I primarily use Gemini CLI, and the one real awkward part of plan mode is that the harness can't run commands, even exploratory ones. So when I'm giving the harness a task in plan mode, it can't experiment and is either blind or relying on its training data and/or any other context (e.g. source code, documentation) I give it. And it often gets things wrong operating that way (depending on how detailed the context ends up being).For example, the ability for the harness to call into a Python one-liner just to experiment is pretty powerful. If I'm asking it to use D2 to build an SVG graph, it can write some Python to introspect the XML to see if things appear to be placed correctly (size, x-y coords, etc.). Which is a pretty cheap way for it to experiment and verify its results before I deign to examine the rendered SVG with my own eye balls.
• jfaat
  I'm using a set of skills for planning now which does something similar to plan mode but it's creating documentation that later skills reference it while building. It works so much better than anything else I've tried, because it keeps things on track throughout the feature buildout and across different agents/models/tasks. From what I read here (& in general) my take is that a lot of people haven't adopted something like this and it's just totally the wild west right now as everyone is cooking up their own flows.I agree that as I move away from holding agents' hands through actual coding I need a different way to monitor what's going on. What step of the plan are we on, what are the tests actually doing, what agent owns what, etc. I haven't found a product that does a great job of that yet and it seems like the next frontier of the 'IDE' to me. It'd be more like an IM(management)E really. The closest thing I've seen was whiteboard [0] but I didn't have a great experience trying it out.[0] https://dev.fast
• noelwelsh
  Using an LLM for any large project shows how useful it is to have data and functions that aren't siloed. That's why CLI apps have had a resurgence: because the LLM can interface with them. Yet the reaction from so many who are deep into LLM development is to build their own little silo: an app.We really need a better model. One alternative is to have an everything-app: a general purpose tool in which (almost) everything lives. The terminal is one of them. The text editor / word processor is another. (I use Emacs for everything.) In a business context the spreadsheet is probably the best choice.
• Menu

  bfung
  Disagree. While it's easier to 1-shot more things now, when there's more complicated interaction of components, a good plan from plan mode can make the project a "looks good, go" and run overnight thing vs. "steering" needed.
• nonasking_
  Maybe we need to figure out how humans should communicate with AI
• dsign
  Plan mode is still very useful to me, I just need to read the plan. Even if the model is smarter than me, it’s still working on my project, and thus I need to keep a mental view of the system. My solution has been to ask the assistant for far less than it can do and leave for myself a bigger bunch of the work, so that I’m forced to keep myself up to date on the project. Yeah I’m leaving productivity on the table but… am I really?
• joegibbs
  My problem with planning and having the models ask the user questions is that the questions the models ask are still often irrelevant: you’ll find yourself answering a bunch of questions like “Should I use the existing system or create a whole new one in a different language?” - yet it will then make assumptions about other things that were actually ambiguous.
• Menu

  nojs
  Claude code’s plan mode began its slow march towards deprecation when they hid the “clear context and implement” option behind a flag. From the discussion at that time it seemed that the developers considered it mostly a legacy feature, and that newer models are smart enough in long context not to need it.
• Bockit
  I don’t agree. I think the way maybe the author used planning to maintain an understanding of the changes is largely not necessary, but there are other good use cases.For example, it’s a great hook in the process for agentic review.Get a second agent to look at what will be implemented and check it for inconsistencies, check it against whatever decisions were made or provided previously in the chat, or against whatever technical rules you’ve written out for your project, before going ahead. It surfaces a large number of opportunities for refinement, and generally pushes the output closer to the direction you’re looking for.
• ed_mercer
  I also noticed this personally. Consider when an agent says"Should I start with the spec, or go straight to building it?Unless you're working on a super crucial piece of engineering, you can probably get away with going straight to building it. Even if something doesn't go the way you intended, I find that it's usually faster to correct the agent later, once the initial implementation is in place. It's more of an iterative approach to building and I feel that it is less cognitively demanding.
• anon
  undefined
• bentt
  I think Plan mode is very useful when building something that needs step by step validation, but also needs a broad strategy before starting.For instance, in games where I work, we often need to manually test work out by playing or by using tools in ways that aren't feasible for the AI to do. In that case, getting the human in the loop between steps is an organized process when it's following a staged plan.
• digitaltrees
  I still like plan mode in my harness because I restrict it's tool use so it can't go rogue and write documents outside of a specific folder. In my case it is /agile which contains a roadmap.md with epic1.md through is many epics as needed for the full vision. Then I often have one chat session per thread. If multiple agents take a sprint or a card it serves as a clear unified context for me and the agents to follow and then track what has been done.
• Menu

  dbbk
  I use Claude's Plan mode daily and it's great. I almost always have feedback to refine the plan and I want a clean separation of planning time before writing code. I don't get what the problem is.I also find this "kill Plan mode" push on Twitter odd, because developers have been complaining about AI supposedly killing their jobs, yet they want to take away the main feature that lets them be an active collaborator and participator in the process. Weird.
• spamizbad
  It's been a while (well, 8 months) since I used Claude Code, but what I can say is that I greatly enjoy using the plan mode that comes baked into omp (oh my pi), especially for tasks around firmware development. I recognize that has a very different workflow than webapps though.
• rglover
  I find a lot of value in using plan mode to get the LLM out of dead ends. If it's in Act and starting to spiral (evidence of looking for something or trying to better understand something), I'll kick into Plan and tell it to think a bit harder—also avoids it wasting tokens retrying the same techniques—which results in a much more considered, and more often than not, correct approach.
• zmmmmm
  I only really used it because the harness was way too trigger happy to start making changes. Even if I just asked a question some times I would come back and it refactored the whole codebase. Now it doesn't seem to do that any more.I still would appreciate a "read-only" mode. It's not uncommon that I start a harness ONLY to explore and understand the code and I don't really want one typo to have it off building something, or even to save a plan document.
• samradelie
  Still working on and with this but had to move it private because marketplace installed plugins loose capabilityhttps://github.com/samelie/claude-plugin-pnpm/tree/main/skil...
• Seattle3503
  I still use plan mode, but during plan mode I will spin out sub agents to implement the current draft in a tmp dir and bring back lessons. I feel this keeps me grounded in my original starting point, rather than ending up with a implemention that meanders through the agents own discovery process. It also lets me ask concrete questions about (possible) implementation
• Menu

  SillyUsername
  I'm going through the same problem right nowQwen 3.8 27b is the supervisorQwen 3.5 4b are the 6-15 minions it controlsGemma 4 e4b is the validator for the supervisor.A plan means it preps all work for the agents up front, tests that evals work, makes sure the dev environment is right for each agent, then finds and fixes each before the distributed tasks even begin.What I thought would take minutes took hours as a supervisor or one agent did the prep / pre flight work.My solution so far has been to drop all but basic setup and force the supervisor to ask before every op - if this is not the design choices, can this be run in parallel? If so, hand it off NOW.I'm still iterating this workflow, but less setup for all the minions plus handing them work that may be incomplete/ broken is caught and fixed by the minion and its own qa gates.This can mean a number of minions end up replicating the same fixes, but in general the time cost of that is small Vs the supervisor working in parallel instead of too sequentially.
• diegof79
  Lately, I've been using Matt Pocock's “/grill-me” skill more and more, rather than plan mode or a complex, spec-driven set of skills. I made a personal fork of the skill to use Claude’s ask tool, which has a nicer UX.I used plan mode for two reasons: to review the choices before execution, and to execute with another model (i.e., using the barely documented opusplan feature).The grill-me skill is much better for reviewing and clarifying choices (and modifying it to use the ask tool makes you go faster). Instead of opusplan, you can explicitly tell Claude to start a subagent with another model to divide the tasks.
• anon
  undefined
• skybrian
  Yes, a conversation can be the plan. It helps if you ask it what the commits will be and then tell it to use subagents to implement them.Also, since sometimes an AI can be a busy beaver, I added instructions to not edit any checked-in files if the prompt contains a question.
• socketcluster
  With Claude, most tasks do not require discussion, I know exactly what to ask and what approach I want to take but for especially complex functionality with multiple possible options, I will ask it to list the tradeoffs and suggest an approach. It's still kind of 50/50 whether I take its suggestion or not; it's still a bit off in terms of weighing up importance, but it's really good at listing out relevant constraints and tradeoffs. It sometimes misses opportunities but it always sees the tradeoffs and the issues.
• jacobobryant
  I like writing spec files exclusively by hand and just asking the agent to surface questions about it, which I then clarify by editing the spec file further by hand. It keeps the spec file more manageable than having the agent generate the spec file from your conversation.
• ChicagoDave
  The second I discovered the plan start hook I hijacked it and replaced the built-in planner with my own. The built-in planner is useless.
• 6thbit
  I'd like a brainstorming mode, with limited side effects.I want it to go and read stuff but also invoke some commands and generate reports and discuss on the results. Latest GPTs in codex plan mode always go.. write a plan. Shocking, i know, but thats not what i want on every turn when im in that mode.
• TechSquidTV
  I would have assumed plan modes make use of tools to keep the goal/plan persistent across compaction etc. Is that not the case?
• 8note
  i find astra's every other message is a small plan, and i have to confirm for it to go
• Menu

  apical_dendrite
  > While the ease of generating code this way triggered a greater dopamine rewardI get zero dopamine rush from this. I get a dopamine rush from building something or figuring something out myself. I don't get a dopamine rush for generating thousands of lines of code that I then have to try to understand.
• digitaltrees
  Cool article from a cool founder. Her other posts are great.
• txhwind
  Why is a plan "mode" needed? I really hate reading plans in conversation UI. One line in AGENTS.md is always better, and you can customize it to fit your document convention. From the communication perspective, the planning process is most about creating clarity and alignment, on things like scope, constraints and decisions, among people (and agents now), often requiring multiple rounds. The planning tool built in Codex or Claude Code is not persisted, version-controlled, nor well accessible. In practice, My AGENTS.md contains an instruction about writing a document before starting implementation. Usually I won't read that document, because I don't want to micromanage agents. That document mostly serves a historical purpose like ADR, helping me find out what agents missed, made mistakes on or misaligned on, if needed.
• bitwize
  We experienced another step function in model quality over the summer. Models are now one-shotting medium sized tasks that require significant engineering judgement. We're moving into an era where the production of software will be done entirely by machine, requiring only an abstract description of the need the system is to fulfill in business language. This has been the goal since the 1970s. "Plan mode" isn't necessary when the model can suss out what you need from a few sentences of prompt and make competent engineering decisions to fulfill that need.Brooks was wrong. We have a silver bullet now.
• anarticle
  Maybe, I always say "let's write a plan and refine it" which ends up being a nice rubber duck session to keep claude and friends from going off the rails implementing things like privacy or encryption or some other rabbit hole when I just need it to do a few features at a time so I can review while it starts the next few things. Maybe this is slower to deliver, but I don't spend a lot of time unwinding commits.I don't necessarily use plan mode explicitly for this, but I might turn it on if I think something destructive is coming up, like a schema change or some other devops thing where claude may decide "oh we copied it all over so I can delete it from source" "oh I'm sorry I didn't catch that error code and assumed success, your data is now gone" lol. This happens a lot less but I've been bit right on the face by it before.Are plans the wrong abstraction? You can use a big enough plan to spam tickets into linear and have claude burn them down. I find it increases subagent accuracy.
• b0rtb0rt
  why do you even need plan mode?“discuss your plan with me before implementing anything”theres your plan mode
• Menu

  OutOfHere
  I can't speak for Claude, but in Codex, plan mode is very useful for finding serious issues with one's spec. I use it to improve my spec. I keep rerunning plan mode over my updated spec until it stops finding issues. It is only then that I execute the spec.
• russellbeattie
  I've been working on a custom orchestration system which starts by creating an overall work plan, then splitting up development tasks among agent/model combos depending on their capabilities/expense, then coordinating their output, testing, etc. with various adversarial agents acting as gates throughout the process. It's really satisfying to watch the task board as agents go through their little routines.It's been an absolutely fantastic way to set tokens on fire and watch them burn, and produce pretty much nothing of value.
• Menu

  bartread
  > This cut-and-paste workflow felt clunky and made it arduous to work through an idea while keeping track of the current plan.I mean, it is, and if that were the workflow I’d be very fed up of it by now, but the plan mode in Claude’s VS Code extension has supported select and annotate directly since at the very least early 2026.
• tamimio
  Plan mode isn’t that useful but planning is, I never used it much, but in the agent build mode, I lay down the specs, the architecture, and everything I can think of, and I ask the agent to make the blueprint with the specs that will be used throughout the project, I review them, make the needed edits and revisions, then code and review follow. This is good because you can use the blueprint in any other model or agent, even humans can read it and understand it, sure, sometimes it gets overly verbose but it’s better than nothing.
• Transformanshen
  [dead]
• Menu

  vikash-hn
  [flagged]
• Ozzie-D
  [flagged]