Hacker News

> 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.

It's useful because it let's me see the decisions the model will make before it wastes a ton of time implementing them. The model is smarter now but that doesn't solve for underspecification if it guesses my intent wrong

Plan mode is critical in the beginning, because there's a lot of long tail decisions that haven't been considered, let alone resolved.

But as skills and memory are populated over time, Plan mode isn't as necessary. It becomes simpler to let Claude just build and get something general in place that works, and then refine from there. Auto mode will ask essential questions.

I still use Plan mode for big feature changes, to confirm that I've asked for what I want in the right way. I tend to prompt casually, with only a few specific details. Plan mode helps me see the whole picture before committing. In a few cases, it also helped me decide the feature I asked for was wrong.

I realize there are already a ton of comments, but I think you're missing the idea of _precision_.

Most people aren't precise when initially describing their problem.

Jumping straight into implementation skips the part where we refine and better define what it is we're trying to do, and think through the implications of those changes.

I suspect "trusting the model" doesn't really work at scale with finite resources.

Fascinating! I literally never use Claude without plan mode and I find it's basically useless without it, constantly wasting tokens going in circles on irrelevant things. Fable or Opus. I feel like neither has a good sense for how to architect things and if I don't use plan mode it usually wastes hours of time chasing it's tail or implementing kludges on kludges to get something working that would be a much simple fix elsewhere, especially when working on a larger codebase.

So my Claude Code workflow for a ticket is:

* Scoping discussion - do research and figure out approach (auto mode)

* Planning - take the scoping and convert it to a concrete plan for review (plan mode)

* Implementation - put the plan into action (auto mode)

I find this works really well for my workflow, and it is really easy to trigger each phase because the model has clean boundaries. (This workflow is articulated in my user CLAUDE.md) Plan mode is still useful to me as it forces the model to double-check its plans (I find even with Opus 5.5 it still discovers gaps), and it gives me an opportunity to clear context at a really good spot.

So I would still consider plan mode to be useful. It would make me sad to see it go.

PS- I have a Claude Marketplace directory submission for an MCP server that has been sitting in review hell for six(!) months. I've never received any outcome other than "In Review". I hope I'm not asking too much but would it be possible to put me in touch with someone who might be able to help here. Nobody has ever replied to messages sent to mcp-review@anthropic or the "Anthony at Platform Operations" inquiring about status, and we are getting frustrated

I've had Claude generate me videos of before & after to better convey new features or bugfixes, that's been quite helpful.

In case anyone else is interested, the skill is public: https://github.com/Mudlet/Mudlet/blob/development/docs/demo-...

hi I’m the author of the post. I think that’s basically the distinction I’m trying to make.

Historically, plan mode served two different roles:

1. making the agent’s instructions precise enough to execute 2. helping the human understand what was about to happen

I think #1 is less necessary as agents get better. #2 is going the other direction, it becomes more important as the model is able to do more on its own because larger chunks of work are happening with increasing complexity.

Where I’ve changed my mind is the interface for #2. I increasingly think an interactive, iterative workflow is closer to how people actually build understanding than being handed a long generated document, especially one they didn’t author themselves.

The human-understanding problem is very real though

> In Claude Code, all plan mode does is add a little reminder to every user message

I was quite surprised when I learned this (when Claude Code edited a file despite being in plan mode). I had previously assumed "plan mode" was a harness level concern, and restricted what tools could be used. I didn't expect that it was simply an addendum to the prompt.

But I think it gave me some good insight into where the heads are at of Anthropic employees building this. Basically, leaning on pushing everything to the model. That's why alignment is so important: a "sufficiently advanced" model doesn't require any tooling infrastructure around it, and I suppose Claude Code devs are targeting that future. I had previously thought there was more to a harness, but with "auto" mode these days, it seems like there's no desire to build in that direction.

It seems unsurprising that if your definition of "plan mode" is as tiny as appending "but don't write code yet", that it would not be that useful for that long. There have to be more sophisticated versions of what "plan mode" means out there.

Also if you are working in a heavily vibe-coded codebase, as Claude Code reportedly is, it's not that surprising if the human doesn't really understand it or have anything useful to add in a collaborative context.

Good to hear, this is my experience also:

I haven't reached for Plan Mode in awhile--maybe, on some blank folder/canvas and I just want that cute "questionnaire" DX to get me going...

But on the whole, CC is smart enough to know when to "rush off and act" and when to "pushback", which is great--and it's no big deal to tell it to pause/stop by adding "what's your thoughts?" or "feel free to pushback" etc to my prompts to make it start a back-and-forth with me (the fact that you say that Plan Mode was really nothing more than a prompt anyways is reassuring).

And yeah, when you're deep in the weeds, you could (and can!) have multiple threads of thought/work going on in the same convo, that stopping and starting a plan in Plan Mode seems like a regression.

(happily using Claude Code Opus 5.5 on High rn)

I disagree with the assertion that the model gets it. Here’s a practical example I just tried with Fable 5.1. I gave it this prompt: “Write a Go function that can be used to establish secure communication to a remote system using a certificate. Keep it short, single function, and explain how to use it.” The output forced the use of a private key stored in a file even though that wasn’t specified anywhere as a requirement. The function Claude wrote takes a private key file argument and calls a Golang function that requires a private key file (tls.LoadX509KeyPair) even though Go has crypto.Signer which could support private keys in various other manifestations like HSM or KMS. I argue that a person who “gets it” (or who is reasonably experienced in security) would have opted for not requiring private key material for this to work.

For the record, this isn’t unique to Claude. ChatGPT and Gemini do the same, each with its own quirks. ChatGPT got extra credit for being the only one who allowed the function to also take a CA file for server authentication.

Don’t get me wrong: LLMs are the future (maybe even the present) of software development but I think there’s some way to go before they can be entirely hands-off in some areas. I still find myself having to course correct designs and plan mode helps me with that.

And of course, thank you for your work on Claude. :)

Well that explains why I was able to coax it to partially execute on some things without actually exiting plan mode.

I get the idea here, but I find planning very useful as a phase when I'm doing things I am not intimately familiar with (e.g. AppKit programming).

That's when I need to learn about implied patterns, do's and don'ts; not from theory but in the context of my own project. Unfortunately, the model tends to keep implicit knowledge implicit. But I can ask during planning.

The feature did get less useful over time when the model started babbling in newspeak more and more. When it threw a thousand words at me even in concise mode.

So I don't want to let the toolmakers off the hook here. There's a lot to win that would make plan mode much much better without changing plan mode itself.

> 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"

Can't help but think if plan mode isn't useful as you say because it's implementation is lacking in claude code, hypothetically speaking.

What I can say is that with other harnesses plan mode helps stabilize my workflows. Actually synthesizing code is only part of the process, lots involved in taking a work-item to production end-to-end and plan mode helps give this flow structure. More than that it's an opportunity to regroup before committing to changes. It slows down the process to a rythim that's sustainable and smooth, which ends up speeding up the process.

So if plan mode in claude was designed to speed up code churn, while oh my pi for instance designed plan mode to be strategic, that might account for the different perceptions here.

And it's not to say you should force yourself to use it, but if you are planning on cutting this mode off the loop just beware of the possible side effects.

I would have agreed a few months ago before opus 5 but I'm back to plan mode and lots of the old tricks trying to get that insolent model to follow instructions. 5.5 so far is better but certainly doesn't feel under my control (had it go off and read other repos and make changes just yesterday while in "plan mode").

To be honest the new behavior is convenient when I just say "X is broken, please fix". But I find myself more and more adding "please do not do anything yet, just tell me what you would do" and please feel free to ask if anything is unclear", especially if is making decisions that are a fork in the road.

I would really like a dry run mode that just disables all external commands from the outside so Claude doesn't proactively go about changing things.

What I do nowadays, for large changes, is have Fable create a HTML explainer for what we're gonna do with code snippets, which is not that fat from plan mode only much more convenient for me and modern models have no issue using that HTML artifact as the source of truth, and then before I get into execution - I interactively build an end to end test that also includes pieces of the plan.

When a test case fails, the relevant part of the plan is surfaced in the error. I find this helps Claude stay on track for longer - I've been able to do 12h most times and even up to 48h unattended (11h of API time) with good results.

Then whenever I do check in, I ask it to update the HTML with current state in an append only fashion (sort of like it's writing a blog), and then based on that, we iterate on the end to end test (I think of it as a "test harness") - update the test cases and error messages.

I've been able to build some truly large projects this way, both greenfield and up to spec (for example, a video game I've always wanted to play), and brownfield while staying within the conventions and design of the codebase, and with very little attention required on my part.

> 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

seems like plan mode could turn off some tools, even if it doesn't change the set offered to the model, the ones that they have which would mutate your codebase could just not work with an error message, and plan mode could change permissions in the security approval prompt for "auto"

anyway, isnt the right way to know if plan mode helps or not, to run an experiment? we're all guessing unless we have data

read only agent mode sounds straightforward and useful to me

for me it basically all boils down to:

1. I dont want to have to accept every time Claude touches our DB

2. I'm scared out of my mind it might do something bad to the DB

Plan mode gives me enough confidence that it wont do (2) --> allowing me to give it enough permissions to do (1)

Early versions of plan mode would erase the chat history and present the plan as the start of a new session when you approved it.

I miss that. It worked really well, and it kept the context clean.

I am not seeing this and I’m wondering why. Maybe how I plan is different then you? Maybe what we each mean by plan is different? Maybe you trained yourself to write more effective prompts than old you? Maybe the problems you’re solving don’t need planning and the problems I’m solving do? Maybe I’m pickier about solutions?

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): https://github.com/clops-mcp/clops-mcp

I frequently ask claude to write and review org-mode files. I've found it useful to maintain knowledge decisions both for claude and myself. Less so for other members of my team who wont use emacs or (n)vim. But thought I'd share.

Yeah I think this is a natural consequence of longer task horizons. When I was chaining 4h tasks, I can mostly plan them up front.

Now that I’m frequently designing and delegating day/week scale features, the flow has to change; having the agent go off and build a spike can be a quicker way of us understanding the design space and constraints (especially in a huge codebase). I still have the agent write and update a spec doc as I go, but it’s not waterfall anymore.

At least for my kinesthetic learning mode a rough code PR stack is usually way better than a plan doc anyway, and tokens are cheap enough (vs my time) that going further than just a plan is often cost-effective overall.

The dream of course is (say it with me) loops, but that doesn’t tend to work for me on new features often.

Honestly I don't agree with this. A few reasons why I feel like I will always want a plan mode:

1. I want to know whats going to happen, at least at a high level, before changes are actually made. 2. Plan mode helps me flesh out the missing details of my plan before being mid-execution 3. In situations where I have a limited budget for AI usage I will often times use a high powered model like Opus 5.5 or Fable to make a detailed plan, then scale down to a cheaper model for implementation. I feel like this saves cost in the end.

I get plan mode is basically just a small hidden prompt. I get that I can basically just preface my prompts with "make a plan only, don't make actual changes." Maybe this is just a UX trick, but it works well for my brain.

Plan mode is what makes it easy for me to update my mental model of the codebase, and helps me decide if the mental overhead of all the changes that are needed are even worth doing, which are now the biggest limiting factors (reading the code diffs just doesn’t scale anymore).

> It’s something I came up with late on a Sunday night many months ago

Aider, Cline and many other agents had plan mode before Claude Code existed.

> planning had become interactive and iterative

I find myself endlessly ctrl+c ing claude now as it flies off doing deep first principles analysis to work out how to find a thing it isn't sure about but I know the answer. Being able to give it that answer without needing to ctrl c would be a massive improvement

I'm not an Anthropic model user, and the true frontier of the frontiers is beyond my budget. Maybe it's better in the rarefied atmosphere of Astra, Fable and Opus 5.5?

But with GPT 5.6 Sol, I'm still finding that the model makes conceptual mistakes, or gets edge cases wrong, or assumes incorrectly (making an ass out of both user and model). In many cases, I need to at least refine the proposed approach, or amend, correct, or flat out just stop and start over. Not planning and catching these errors, and just letting the agents code their code, would mean I'd have to rollback and redo many times. What a waste!

For a current project, which is ~33k lines of code, I'm also finding that I know the codebase better than the model, and that's vital at the planning stages too. If I wasn't in the planning loop, the model would have reinvented various wheels a few times over. How much spaghetti do you want with your code?

As always, I may simply be doing this wrong. But I'm personally not convinced that the plan is dead, or that I want the plan to be dead. Planning is also good for me -- it keeps me thinking about the code, prompting better, guiding the model better.

If I'm no longer on top of the codebase, then at some point my prompts will devolve to "Do the thing with the thing, that does thing". And I don't want that.

what worked for me is a frontend driving the agent, capturing every user message, every commit, every pull request, putting them in a graph (uses a frontend because I didn't want to load a coding agent with tools + responsibility of book keeping) and the agent get tools to search reason behind code changes and see the high quality user input underneath instead of the sloppy self written justifications

I don't really use plan mode, but I do have Fable write a lot of docs, particularly when the work involved is long and multistep, because I may need to do it across multiple sessions.

Oh I thought it blocked tool calls like editing files...

You don't need to actually change the tool schema or break the prompt cache to do that. In the tool itself you could just check if it's in plan mode and reject the tool call...

As someone that never used the built-in plan mode, but did use a lot of spec-driven development, I’m still finding that even with Fable having “plan” docs is still quite helpful.

They’re most useful for broad changes (new features, refactors, etc.) where it’s helpful to avoid breaking changes or unnecessary scope expansion.

The new models are great, but they do more by default, which means I’m finding myself explaining what _not_ to do more often than with previous models (where they’d often end too early).

In my case, the previous plan mode was too ephemeral, and I like having one source of “truth” that sits across context windows without loss/compaction.

I m a bit surprised by this as - during the last 2 months - I 've encountered more often models going ahead of what I have asked from them. It's gotten so annoying that now instead of just saying "Let's plan X" I will also say, "Stop once you 've written the plan." because otherwise there is a distinct (~35% anecdotally) probability that the model will go ahead and implementing the plan as well. [This applies to both Anthropic and OpenAI models btw.]

Plan mode is a useful shortcut when I want to have an agent do read-only work without having to worry about giving it appropriate stop conditions.

I was thinking of making (locally) an “artifact mode” along those same lines. It’s a much better way to see proposed changes

I like plan mode personally. I only use claude code for the web, and the questions claude asks me to clarify are usually pretty important - mostly because I was too vague or contradictory in my prompt, or what I was asking for conflicted with something else in the code. I don't know how claude would resolve that without plan mode.

Also for session planning, as in when-can-I-walk-away-from-computer, its nice to know the particular rhythm of initial crunch - ask questions - make plan - do it. Especially with a 5 minute cache timeout.

I created a skill "feasibility", which is basically "evaluate feasibility of this idea and propose solution options". So I can check that Claude's idea of how to implement the requirement is close enough to my own before it starts working. It is a lot more lightweight than plan mode, because the skill says not to build a detailed plan, just a high-level summary.

My team has been struggling to understand whether or not we should do "spec-driven" development or not. It makes a lot of sense to me to have one developer iterate with the model/harness to generate a markddown document that is a high-level of what will be implemented, and then have the team PR review it before and agent attempts to do the actual implementation work. Do you think this is a good practice?

I keep forgetting that CC has access to the "question" tool, even outside plan mode, which is mostly why I still use it sometimes. This isn't (or wasn't until recently) the case for Codex.

Thanks for the context, and makes sense a lot. That’s my primary reason to use plan mode.

However how about decisions? Do we expect the model to read our minds, just assume the best practice will be followed and that’s what the user want? Plan mode solves those, what is that am I missing?

I just tell Claude to write an md file and do research first anyway… makes sense

I urge you to have a look at tools like tuicr and hunk. It’s a missing component in the chat. I really want a proper chat interface, leave comments on the code and have them replied to. No clue how to implant it tho, it’s a hard UX problem IMO

I always append something along the lines of “evaluate”, “investigate” or “report only” to my prompts when I want to see what the agent is gonna do. Because especially with the new models they tend to go easily off rail and do stuff I didn’t ask. To say that they just “get it” is highly dependent on the task, scope and blast radius.

> it has never changed the toolset because doing so would break the prompt cache, and so would be expensive for users.

It could still make the tools into no-ops or disabled if it actually tries to use them, without changing the context history at all.

Yeah, as a user I came to the same conclusion as I naturally used plan mode less and less over time.

I still use plan mode in Astra to come up with a plan that I then feed into Fable. I feel like OpenAI models still do better big picture investigation and planning, while Claude is the better software engineer, if that makes any sense.

Of course this could well come down to my own biases and the specific things I’m working on.

I’m always telling the model “don’t write code yet” so I maybe ill try plan mode if it’s just a prompt change

Reading the replies, it's interesting how idiomatic everything is, eh? We must all opine about our specific setups, panes, prompts, and how they're the true way, or the true alternative to plan mode.

I really wonder what I’m missing because my general rule to plan first unless explicitly instructed works perfectly fine with all models I use.

“I want to ...” / “Let’s ...” -> Plan

“Do X” -> Actually Act.

But then again I also have it configured to only ever answer questions instead of inferring them to be instructions (which I’ve seen others do differently).

that's the problem though: - LLM now output good enough results without a plan.. for coding at least. I'm not saying amazing results..just good enough. it works fine.

- Most people suck at planning anyway

- LLM still don't give you a way to verify and understand to iterate.. you have to ask and then formulate and way so people barely do it, they just trust the vibe

IMO the current successor to plan mode should be the harness knowing when to tell the use "ok here's our overall current state in a simple diagram", auromatically

except the fact that claude code in plan mode does destructive operations, requiring a hook to tell it not to do stupid things, so its not really a "read only" or "dont code yet" tool, imho.

I think over time more and more will be peeled back to just the model and markdown. I have a beautiful factory running with key personas all it is is a few markdown files it is building a mac app fantastically well.

https://innerloop.test/breadcrumb (for reference)

So planning mode is dead, long live planning?

Hi, thanks for Claude Code. I use it, and it works well. Have you considered changing it so the text comes down from the top of the screen, in green, like The Matrix?

> so I can better understand the change and alternatives considered. I don’t do this very often,

# YOLO mode

It’s been like that with me in Grok 4.6 for the last couple of months as well.

I just start my day writing about 20 queues /goal prompts and then check the work at the end of the day. It’s almost always right!

Btw random question about Claude Code. Is it just me, or has it become a lot slower in the last 2-3 months? I am on Fable but also latest Opus.

For me its like a dry-run.

I use plan mode, because my current project benefits from "pair programming."

I have one session define a task, and provide a formal specification plus context in a "cover letter."

The session B, in plan mode, produces the plan back.

Session one reviews the plan and clears it, ratifying portions and often specifying specific changes.

Session one then executes.

What has been striking to me in this approach is that even with two instances of the same model (currently Opus 5.5), there are regularly corrections made. I use "project chat" for session A and Code for session B atm; it is very typical that Code finds and corrects details or oversights in the task spec; it is also typical (though less so with 5.5) that session A (chat) pushes back or clarifies things Code doesn't have the context for.

I have been afraid to open up the potential of negotiation beyond what this is costing as it is. But I am also afraid to simply skip the formalisms, because of the consistent correction that occurs in this back-and-forth.

Each component of the pattern is schematized, generated from a template, and validated, to keep things tight.

Lots of tokens! But I trust this process far more than "just typing" :)

As a long time user of Claude Code, I've just naturally stopped using it because the model figures it out, and i prompt it accordingly like 'come up with a plan'. Glad to see your experience matches

I ask Codex (I am not using Anthropic anymore) to always generate a plan file first, unless explicitly told otherwise.

I also tell it to write deviations and rename plans accordingly once done.

That way I keep the codebases I have to or enjoy to work on in my head and don't become too dependant on any provider or on stochastic parrots in general.

Plan mode still earns its keep when the blast radius is high.

For a one-file change I don’t bother. For anything that touches auth, payments, or a shared schema I still want the plan written down first — not because the model can’t figure it out, but because I need a moment where I can still say “no” before it starts editing.

The mode was never really about making the model smarter. It was about making the human stop and look.

> I work on Claude Code

So basically you don't know what the fuck you're talking about. Not everyone is employed to burn money.

100% this. Some people are basically adding AI as a dependency for their projects. They no longer understand the code

I feel the same way but I have successfully refactored some of the early experiments. Our team has settled on targeting a double output from the before times but more ambitious product vision because AI can teach us things we don't know. We actually target 2 days of coding and 3 days of learning with Ai so the increased efficiency allows upskilling rather than just pushing more code

Just like rushing made messes in the before times so too does rushing via LLM. The exact same outcome will happen, but at a far greater velocity and scale than anything we've seen in this industry before. Old Testament, Mr. Mayor, real wrath-of-God type stuff!

The last couple of weeks, I’ve got rigorous about making the agent refactor old code. We’ve removed, moved, consolidated, reordered loads of cruft. It has made the code much tidier and reduced the chance that the next feature will build on top of cruft.

E.G. over time we’d gained two client-side caches of related server state. This started out as two different parts of the same model, because we couldn’t get all the data we needed from one microservice and had to merge in the client. Over time, more and more features used both caches for different aspects of related processes. At some point one of the microservices changed so as to return all the data in one call. The update to consume that kept both caches, adding code to sync them, because so many parts of the code were using one as a fallback for the other, so they both looked “necessary”. Because they were separate, and “live” sometimes they’d go out of sync after the initial load. Worse: the consumers alternated about which cache was treated as the fallback, making it very hard to see that either might be redundant. Eventually I noticed they were filled by the response to a single call. We all know paying back tech debt never gets prioritised, so I rolled the payback into two feature tasks, and just took longer about them.

My employer expects we use LLMs and provides some budget, but it’s not enough to use even Open4.7 or GLM-5.2 on every task. I do the bulk of my work with Composer 2.5. It’s quite good for “going forward” on smallish tasks and it’s written most of my code this year. It’s possible smarter models would spot these refactorinh opportunities and action them proir to building features or fixing bugs. But I wouldn’t know because I can’t afford it. I’ve never seen even a 4.8 era model spot a refactor and plan to do it prior to a “new build”.

I’m pleased I’ve spotted these trends and started to build the habit of (telling the agent to)“refactor to make the change easier”, but my percieved productivity will go down and I risk the ire of my leaders.

It's truly bizarre to read about all these people who just give up on any understanding about what they are working on.

I very regularly use plan mode not to even make a plan of action itself, but to better understand what possible issues might come up when implementing some feature or fixing some bug. And it is quite common for me to fix or rewrite certain findings that AI comes up because its assumptions are not quite right or don't align with overall goal.

And yet so many seem to be perfectly fine leaving all the decisions to AI - even if it's going in the wrong direction. I suppose that's all the people who got into software purely for money or status - never really caring about the actual thing they are working on.

FWIW, our codebase is growing, and the size of each change is also growing, but it's because AI is making us fix all the bugs we'd previously check in because our code long ago surpassed what even our best developers can reason about.

The funny thing is that the AI adopters are in the middle of the bell curve. Our worst devs continue to perform worse than AI yet refuse to use it and our best devs continue to insist AI sucks despite it finding issues in their code and the reviews and designs they've approved.

people actively deskilling themselves and becoming totally dependent on an ai pay to play service.

I see this complaint frequently about losing track of what the agents are doing, and I agree you do need to understand your system. But there seems to be this baked in assumption that if you lose track, you now need to manually wade through this massive mess to untangle it and maybe that is impossible. I don't agree.

If you don't understand the codebase, ask the agent to explain it to you. I'm not not kidding. Modern frontier models are fantastic as this - even more so than actually writing the code. It can tell you in words. It can generate architectural diagrams and sequence diagrams. It can write tests and scripts that prove it's assumptions. It can happily refactor so that the system design is aligned with your preferences.

Once you accept this, you can stop worrying so much about it and instead focusing on building the architectures and tools that lets the agents succeed better and faster - so called closed loops or agents prompting agents. Build systems that are more easily verifiable and deterministic so the agent can write very powerful property based tests. Focus more on what and why you are building, how to make sure all external properties are verifiable and leave the internals to the agents. The code is not really for us anymore.

Pretty embarassing state of affairs for this "engineering" discipline

2026: you're going to forget how to code and spend your entire career writing documentation, and you're gonna love it

> "so complex there are no obvious deficiencies" (as opposed to "so simple there are no obvious deficiencies"

The quote is "so simple that there are obviously no deficiencies"

> 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.

I agree with this, but the reality is that it's only the result of models empowering devs, and power in good hands amplifies positive results while power in mediocre hands amplifies technical debt.

It's a good time to choose wisely who you work with.

We cannot blame just LLM models, it is brains nature to save energy. If agent did tasks consistently good, our brain try to delegate cognitive load to the model to save energy. After consistent use of LLMs anyone can have tendency commit slop just reviewing at high level, this is specially true with busy lifestyle. Also AI generated code do not give dopamine just like solving problems we did before LLMs, we tend to get lazy. Strict discipline is necessary to make good use of LLMs in order to not commit slop and not to make us dumb.

And what happens when it becomes due?

"The one thing plan mode helped is for the humans to get an understanding of the strategy"

For me, this phase still happens, but a distinct "plan mode" is unnecessary: I just tell the model, "This is discussion; no code changes yet." and spend hours figuring out what will and will not be done.

Unfortunately what's happening is people just can't help themselves. Just like an addict reaching for another hit, it's really difficult to make yourself do work when you could just not. I've said it before but LLMs are our cigarettes. It's going to get a lot worse before it gets better.

Plan mode, for me, is my opportunity to develop and understand my own plan. Sometimes, rarely, Claude demonstrates it misunderstood my intentions by writing a plan to address the wrong problem. But usually it's about me fleshing out the scope and boundary of the intended changes.

I find that faster than code first, ask questions later. But it takes more time up front.

Coding with plan mode is still vibe coding. No-one outside HN calls it things like "agentic engineering" or whatever. Everyone just says they are vibe coding regardless of how hands on they are.

It seems unwise not to implement sandbox measures just because the chance of misuse has gotten lower.

Do you really trust it with a production code base or database? Telling it not to make changes feels an awful lot like "Make no mistakes". I also like how Plan mode on Codex asks clarifying questions. I'm in management now so I've used Work more than Code lately.

It also doesn't allow leaving an audit trail of plans and decisions (by default, anyway). Most of my mutating prompts look like "Propose a plan for change X and write to file Y" and "Execute steps M-N from file Y".

RE the article: I don't think it's obvious why this process is worth following until you find your time and attention wasted. Conversationally-building is the express train to waste. I'm not sure why you would even be talking to claude if you don't understand what you want to build.

I agree. Plan mode came about because earlier models were loose cannons, doing what they pleased. Today's models follow instructions better enough to not need a separate mode. However, there is still value in using a separate, smarter model for planning than execution, and persisting it for auditing on completion.

If you do use plan mode you might like https://plannotator.ai/

I typically converse with the default model to point the plan in the right direction, then have it iterate with a smarter reviewer to find flaws until the plan file is converged.

true dat

For me, it was the agent that decided about plan mode, when that happened. Most of the time I didn't invoke it but kept discussing and tweaking and if the context was close to full, make it dump it out to disk and start a new session. I felt like that worked more flexibly for me because I could keep steering and adjusting until it was what I wanted. At that point I made it write a detailed spec. Like my homegrown plan mode.

The "standard" plan mode felt too stifling.

I did everything by hand for so long and miss it, now I just read thousands of lines day in day out. But there are interesting gains such as lowered barrier to quickly run adhoc perf tests, do some formal verification, you can just add more guardrails for the thing that gets shipped. The thing I hate though is when managers sell their generated code and you are left shoehorning it to production, they take away the interesting part of the job.

Completely agree with your first paragraph and a point I've made repeatedly here is that I want agents to work more like pair programming and less like code review. I want to delegate typing, not thinking.

But what I've noticed is that lots of people don't want that. They're happy to delegate both typing and thinking.

There are folks who still want to think for themselves of course, but model providers are incentivised to maximise token spend over all else, so the "official" harnesses are not aligned with their needs. My message to those folks is: _go and build your own harnesses_.

I built one, it wasn't a huge lift and it completely changed how I work with LLMs. One consequence is that I choose smaller, cheaper models now because latency is more important with shorter feedback loops. I don't want a super-intelligent model that disappears for ages and provides a final answer, my own brain thinks and guides the process instead.

I'm deliberately not linking to my harness here because that's not the point. Think about what modes of work you want from a coding harness, then build one that works exactly like that. Immense happiness and satisfaction is just a couple of weekends away.

I think this is the clearest example of: exceptions don't make the rules.

Author might be a vibe coder, designer or someone who does not do really heavy and complicated development, maybe some api here and there.

But it is pretty obvious that a very concerned engineer would not allow any of that, for critical systems.

I have two years of copy pasta from Reddit pre-AI. Does that count?

+1 on your critic. I have tried to solve it by making plans folder a git folder, and using tools like Hunk and Tuicr but it’s awkward…

How many thousands of dollars are you burning a month on “looks good, go” and then *letting it run overnight*?? I spend enough money on 8 human, interruptible and human-thinking hours with paused hours.

I can’t imagine how high that number would go if I got rid of the collaborative style and also the “please don’t run scary commands on random directories without permission” mode.

All of those things are trivially possible without an explicit 'plan mode' built into the harness.

For me, identifying a problem of "taste" doesn't exactly break it down. The problem is underspecified in some way. Can we be more specific?

The sense I get from this discussion is that the models/harnesses do not elicit feedback well. Where there is ambiguity, they tend to pick a solution and call it good.

A planning step aims to make these choices explicit. An iterative process is necessary to capture the detail.

It is natural to look to teams of agents to satisfy that process, but do they know where the decision points are?

Unless I'm going to just do something, I use /wayfinder for almost everything now. It automatically goes into grill mode when appropriate, and it'll suggest just doing the work if it's light enough.

Try /grill-with-docs, too.

There's some pretty interesting evidence that this feature actually just increased costs: https://stencil.so/blog/prewalk

Wait, you can turn that back on? Where's the flag?

This part I find a little disappointing. The plan is the perfect boundary to cut context which still isn’t free, even if models can handle a lot of it now.

Remember, Anthropic knows best for your workflow!

/s

This is why open harnesses and open models will always be superior, it's only a matter of time until someone decides that something you use isn't worth maintaining anymore. The reply from the Anthropic employee up above doesn't give me much confidence that Claude users will be able to continue using plan mode forever.

My only issue with superpowers is: it wast too much time/tokens - besides creating a lot of useless testing

Yes, plan mode is still a reasonable way to guide agents _before_ any code is written. They're so eager toshamelessly change the files even after a simple quesiton.

But nothing is stopping us from prompting agent to only write to plan.md this session.

I also don’t get what the problem is. Claude’s plan mode is great, especially when you add interviewing into the equation. It means I can get to a point where I’m confident all the changes proposed make sense, and that I understand them, before anything is actually changed.

I feel like this post is hawking for commercial reasons more than it’s based in reality, especially a reality that takes into account the extremely varied experiences engineers seem to have with agents. Not to mention it ignores capabilities that, for example, Claude’s VS Code addin have had for ages (specifically select and annotate in plan mode, as I mentioned in another comment).

As such I’m not inclined to take it very seriously. More than that, the “X is dead” trope was overdone 10 years ago and I don’t think it’s been long enough to warrant a resurgence.

I see what you’re saying. That’s actually why I built Nuanced (https://www.nuanced.dev), I wanted a better way for humans and agents to work through intent before the code got written.

but I think I overfit the interface to how I used to work without agents. when I was at GitHub, I wrote a lot of ADRs, RFCs, and design docs, and I liked that because writing is how I clarify my own thinking. with agents though, I’m often not doing the writing myself. I give the model a rough intent and it fills in a bunch of gaps, and then I get back a long, polished plan containing decisions I didn’t explicitly make.

That’s the part that feels broken to me. The plan can be detailed and technically correct, but still be hard to review because the important bits are buried and feel distant from my own thinking. All the assumptions and tradeoffs and questions may or may not be legitimate, but it’s hard for me to get into flow state and carefully check them.

So I still want the collaboration step. I’m just less convinced that generated prose à la plan mode is the right interface for it.

I likewise don't understand this push. Surely it's a trivial feature to keep enabled. It mostly seems like advertising that "our models are so smart you don't need to plan". But I find it to be a great mental review process for my workflow.

It sounds like the Ant perspective is "you can just ask claude to plan", but at the same time that's a little more tedious than shift+tab

>yet they want to take away the main feature that lets them be an active collaborator and participator in the process.

It's just redundant when you can just collaborate in the "main" mode. There's never been a point to having a separate plan mode.

> 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.

Goomba fallacy. These are two distinct groups of people.

Yeah, honestly, I'm wondering, not even why people are against plan-mode, but how they're getting stuff done without it.

Maybe it's me (it usually is), but I don't give an LLM small tasks that a human could knock out in a half-day. I give them big tasks, stuff that would take a human a few months to a year - and then I ask it to give me a plan, as a living document, and we spend a good hour or two iterating over the plan.

Then, when its finally at the point where I'm happy with the plan, and I've talked it down from wherever it first wanted to go, or pointed out that we don't need to be all-things-to-all-(wo)men and focus is important, I get it to start going through it.

Likewise, I get it to maintain TODO.md with lists of known bugs, separate lists of future-features, and again, I make a rule that this file must be updated whenever something material changes. I just asked Claude "where are we ?" and got back stuff like:

The ## Still-open detail section lists two items:

- Task #1070: the ported back end doesn't fold offsets into vector loads, so it emits an extra add on 11 files (from 892) at -O3. The output is correct, just longer.

- Task #1080: array sizes must constant-fold. For example, u8 buf[EVSZ * MAXEV] is rejected because size expressions only accept a literal.

This is for 'xc' [1] - a compiler for an Objective-C-like language (but without the excessive []). The language has ARC, blocks and bound-functions/methods named 'block' and 'callback', automatic parsing of DWARF data so you can #use a shared-object, so there's no header files - just read enums/types/functions/methods from the shared object. It's a cross-compiler, runs on mac,windows,linux and creates executables for mac,windows,linux,ios,android,WASM (amongst others). I have a binary running on my iPhone which was written on, and signed on a Linux box - no Apple software used at all. Oh, and it produces code that is very comparable to clang in speed on both arm64 and x86_64.

You can appreciate it's a reasonably large project. It's taken actual months(!) [grin] for me to get working. Months! There's no way I'd approach a problem like this without detailed plans of what I wanted the language to do, where we were going with it

FWIW, "I" wrote blewit.net [2] entirely in xc - both the server back-end (#use <psql> was very useful for binding to Postgres) and the WASM client - which share classes between client and back end, to make it very difficult to get out-of-step between them. No Apache (#use <tls>), no scripting, just a lean-and-mean daemon talking to postgres via valkey (#use <valkey>) - a reddis-alike. Oh yeah, blewit.net has a plan too. Actually it has lots of planning :)

1: https://compile-xc.org/compiler/

2: https://blewit.net/

I realised I linked super cringe docs instead of the actual skill:

https://github.com/mattpocock/skills/blob/main/skills/produc...

The claudism in such docs is so tiring. So many words, yet reading them feels like trying to fill a sieve with water.

That writing style is borderline incomprehensible.

I'm genuinely curious as to what you're working on that you find 4B models good enough. I wouldn't even let a 27B model code, never mind supervising smaller models.

Tell the planner to not do all that. Just plan out the high level. No code. No implementation details.

If you can run the smarter 3.8 27B model, why not use it for everything?

How do you set all of that up with supervisor and minions? What harness?

    > Qwen 3.8 27b is the supervisor
    > 
    > Qwen 3.5 4b are the 6-15 minions it controls
    > 
    > Gemma 4 e4b is the validator for the supervisor.

+1 to a lot of what you said here, especially this:

> I used to tell myself that plan mode mitigated that, but I usually ended up mentally glossing over the generated plans anyway.

At a certain point I realized I far preferred delegating the first implementation pass to agents and reviewing the _code_ instead of a plan up front. If you had asked me this question ~2 years ago I'd think anyone would be insane to hand off discretion like this, but frontier models are just so _good_ nowadays.

Let's say you launch 10 working sessions in a day, would you rather:

* Review 10 plans, and _then_ review 10 PRs, and _then_ maybe adjust the approach on 1-2 and merge the other 8

* Review 10 PRs, and maybe adjust the approach on maybe 4 and merge the other 6

The first option just feels like needless attention for the sake of feeling in control; but the reality is that these models are becoming just as good if not better as us humans and our reckoning is here. Our codebase has enough linters, hooks, and guards such that generally the agent just follows our blessed patterns already, so what is plan mode actually doing beyond giving me a false sense of security? I'm still going to read the code anyways.

Likewise. I get drained quick when I let it just spit out who knows what code.

This is exactly what I do. If it's asking a lot of questions your spec isn't specified enough. It's very useful.

oh interesting! I haven’t used vscode for anything meaningful since shortly after leaving GitHub (2023). I generally find it overwhelming but codex added the annotations too and I love it.

Even worse are slop graphics. A stick figure driving a realistically-illustrated horse and carriage??? Barf

Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.

Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.