Hey, Boris from the team here. This is pretty surprising, given background subagents are the default. Could you confirm you’re running the latest, and run /bug and paste the id here? Happy to debug what’s happening
[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.
I've recently gotten religion on the workflow that is many (relatively) short-lived agent sessions passing planning/handoff docs between themselves. It's better for my own task tracking, better for handling "oh btw I noticed XXXX", and better as a clear review point. Overall it just feels like it takes a lot of the formerly implicit context that was whatever we happened to have talked about and turns it into a much more explicit "this is what you need to know, now go".
Currently looking for a framework for managing this in a more formal way, and I think it's probably beads, but interested to hear from others.
Spent the past 1,5 years building a tool that might be relevant, helping keep durable task state between agent sessions. It is an issue tracker persisting state as immutable event logs, allows you to inspect workflows after the fact, lets you inspect diffs inline in the tickets and it is much more lightweight than Jira/Linear. There is no central service to integrate with, as it is Git-backed and lives with your code in your repo.
This looks really nice and I'm definitely going to give it a go. I been relying on Jira so this will be a breath of fresh air. Beads was great in principle and I haven't given it a look in a while but this looks much cleaner.
I have some older projects that use beads (I still run an old version without dolt that's imho pretty good overall) but lately with Fable also have a few newer projects where I just have the agent write docs and keep a worklog with the what/why/decisions etc. (I think I read it here on HN somewhere and figured I'd give that a try.)
The latter seems to work pretty well for now (slightly better than beads) but I'm always looking for ways to improve it. This could be an interesting replacement.
I think it works well for tracking intent. I tell my agents to use a "human-input-needed" tag when there is a high stakes decision fork, and then I just filter on that tag, immediately highlighting blocked workflows. I think you can get a long way with clever tagging, filtering + time travel.
Checking this out, the skill it wants me to add to my project seems to reference issues that wouldn't make sense in the context of my project. IE: `QPPR7PE` and `MBB6WY5` ?
You are totally right in that it makes no sense. It seems like the skill.md had regressed as I had updated it via agent proxy. Thanks for pointing it out, the skill has been brushed up.
Got it! I am not up to speed on Claude cloud sessions yet. Interested to hear how that works out for you. Let me know if you figure out what's getting in the way, I'd be happy to look into it.
I have a lot of little projects and I also prefer this way of working with agents. Sometimes I would start to interrogate on a specific portion or ask questions to better understand a concept, and the session would get poisoned and the agent would fixate on that topic for all the remaining turns.
I asked fable to look at my interaction patterns and clearly stated my frustrations and the problems I wanted solved, and it designed a simple process to track things in git and built a couple simple session hook skills. It’s pretty lightweight and I’ve been very happy with it for a couple months.
The power of this mode of work is that after you deconstruct the task into smaller subtasks, it's a lot easier to use cheaper models to implement that task.
I get a long way using models like Opus to make a plan of action and a bunch of tasks, and then using Deepseek to implement that plan of action. Saves a bunch of money and is fast.
- I have a record of work done and work to be done that helps _me_ when I come back to the project after several months. It’s committed and lives with the code.
- when a task inevitably ends up more complicated than I thought, I can in that session break it up
- I initiate sessions from multiple computers, so things stay in sync (through git)
- I also have a “tooling” repo that builds out some views of the work and hosts it for me to see when I’m on my phone.
- The hooks let the agent manage all of the workflow/task management, so there’s very little management overhead for me.
I rejected beads and JIRA. I wanted something more lightweight.
Nice. I found myself doing a lot of repetitive stuff handing off between agents, time to fix that. I think I agree with your approach of keeping it lean.
I also sometimes rewind the conversation after going off on a tangent, sometimes not if I want the agent to have the sorts of things I’m thinking about in context. I probably justify keeping too much crud in context than I should
I've been on this kick since I realized the primacy of the initial part of the session context. I created a python app that reads a phased plan and kicks off a new session for each phase. There is a standard prompt and handoff mechanism to determine if we encountered any unforeseen issues that we need to address in chat, but otherwise it will just grind with a clean session with appropriate context for each phase.
Just kicking off a subagent does this automatically...?
My main conversation is usually with an orchestrator that hands off work to various (usually cheaper) subagents to plan / review / etc. It has instructions to find the correct model for each task and not to do too much itself so a multi-phase plan automatically gets a fresh subagent for each phase.
i disable subagents. it also helps that i work in microservice size repos, so a single agent can keep the full relevant context. subagents waste alot of unnecessary tokens doing code exploration that the main agent is going to end up duplicating, i think they make more sense for monorepos.
anecdotally I've tried the same plan on different branches with both approaches (single agent with subagents implement the full plan vs. my little session per phase app) and then had agents judge the code quality and my approach worked better and saves tokens. horses for courses.
I use Jobs [0] to manage this—it's an agent-first CLI to track issues and tasks. A single `job orient` command gives the agent the current task in the context of the larger plan. It's a replacement for Plan Mode and issue trackers, and it has allowed me to execute massive plans in parallel with minimal oversight. There's a web UI, but it's a work in progress.
> (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.
Superpowers never really held up in my own testing vs /plan - not just more expensive but markedly worse code organisation, because the plan itself leads to higher cognitive burden for the models - and today it's even worse, because /plan doesn't hold up versus coming up with a few high level slices and having cc work on one per session, for much the same reason.
5.5 is much closer to Fable so i don't even need it. I am pretty sure it's got Fable's DNA in it.
I really need to find a role where I can do more DX...
Yeah I always balked at the amount bloat in that repo, and I just prefer a more lightweight setup and plannotator’s UI which I can use to interactively review stuff. It solves this one problem better, where superpowers tries to do way too much, poorly.
Going through the superpowers spec-plan-implement-review cycle took one of my test runs (local AI) from 40 minutes to 8 hours, and produced a lower-quality result. I want to use something like that skill, but I'm doubting the efficacy of this one.
I dived into one or two of the skills there and some of it feels very cargo-culty. In a similar vein to the article, the models have improved markedly now and I’m not convinced that “You are an experienced senior software engineer and an expert reviewer, here are five pages of instructions on how to do a review” style prompts are massively useful any more.
I get great review results (as good or better than colleagues using superpowers or even adversarial review skills) just by asking Claude to review a PR and spit out results in order of severity.
My workflow is very similar. But I just ask agents to write design in html instead of markdown, due to its richer layout and better interactivity. When the design is about UI or anything related to graphics, this approach is extremely efficient.
I also found that having the design reviewed by multiple agents has very little marginal value. The review agent will always find something to improve, but mostly it’s just nit and not anything super important.
I used to let Claude just upload the html design doc to Claude artifacts for me to review. Recently I switched to codex and started to use my own tool https://github.com/hyperlogue/r3 to complete this workflow.
I do the same, I don't use Claude Code or Codex planning because it is mostly pointless, even with Fable/Astra. I just have multiple agents work on a markdown file which I manually perfect, often breaking into multiple different files for large features or PRs. I also create design 'handoff' documents which I feed into Claude Design or Astra along with screenshots and wireframes. By the time an agent does something I'm well prepared.
I've tried doing the incremental, iterative approach with just Code and it's just not as effective unless you're working on something simple or experimental. Or you're shipping to something non-serious or perpetually beta.
Have you recently tried working without generating that plan? What I've been doing is first tell the model I want to plan the implementation, talk about it a few turns, then when I'm happy with the idea and method just tell the model to go ahead with the work.
Note that this is only really necessary for complex work that I don't know yet what the best way to do it is.
I've tried doing it your way as well, but there was just too much fiddling about with writing the plan somewhere, then having another session rebuild their context with whatever info is in the plan. It really didn't result in better output for me.
Currently 9 times out of 10 I just say to the model: xyz is the problem/bug/feature, fix it. Since about Fable and Opus 5, this is more than enough. Opus 5.5 (and previously Fable 5.1) got even better at this. However, this is in a codebase where there are already a few hundred thousand lines of code for the model to look at to see how we generally attack things in our codebase.
Claude Codes plan mode I never use anymore, it was useful a few months ago because the models had a tendency to just start doing work and forget I specifically told them not to. But the UX is just annoying and the models now do adhere when I tell them not to change anything.
I have, and it always does something unexpected and undesirable.
Plan mode ensures I'm spending fewer tokens on the code-test loop, and more on the arch/design, and allows me to keep appraised of what's going on, while planning for future changes better.
Maybe folks who don't need planning, don't have as much concern for the details, and are happy enough with just evaluation of if it works or not.
I have roughly the same workflow, also with plannotator - which I like a lot - and haven't used or felt the need to use _plan mode_ for at least 3-4 months.
Then telling Claude to work on a document, the instruction is kept to its core.
Now when bcherny explicitly mentioned that it merely adds a single line - it explains why I don't need it.
What may be concerning about "super plan" mode from the creators (or a skill, for that matter) - is that tuning the amount of effort, and how much deep to dig - may become too hard, as it will interfere with several embedded paragraphs explaining what to do, how to do, where to do, etc'.
What I do look for is even better plannotator ability to track changes, combining historical comments (like Google docs), and git blame of several "generations" before current reviewed doc.
While possible to commit, I'd still loose the comments themselves, and the commit will be at least per changeset, and not connected ro a specific changed section.
Roughly speaking, I'd be happy if plannotator would persist something similar to github PR reviews combined with Google docs comments & suggestions.
I do something similar. But where I change it up a bit is depending on plan complexity I divvy up parts of the implementation to different subagents with fresh, only relevant context for whatever they're responsible for doing (e.g. a part of that plan). Edit: to clarify, I will also go back and forth with the planning agent making sure edge cases are covered. Sometimes that involves invoking a new subagent without our planning context to validate it without preconceptions.
I personally still find planning a valuable mental exercise; it's not so different from pre-LLMs and whiteboarding or otherwise taking the time to consciously plan a set of work.
Yeah, sure, but you don't need a dedicated plan mode for that at all. you can just do it in auto mode, and say "let's do some planning first", and Claude will (nowadays) be smart enough to understand that it's not supposed to jump straight into the implementation.
So again: You don't need plan mode, auto mode works just fine, there is no difference in the workflows here.
I do something similar but a bit more involved, using a few informal stages. Let's say for example I'm trying to launch a new complex feature for https://coderba.se.
- strategy document
- "sprint" document with technical implementation
- actual implementation
- e2e testing scenarios updates
Every step involves iterating with Claude on it with me in the loop (setting the direction then resolving the "founder questions" as they appear), and importantly a different model for review/code-review, be it Codex (usually, it's great at it) or Antigravity/Gemini (sometimes finds novel things, its precision and recall are abysmal but on the odd occasion it has good accuracy). This iteration on the high-level plan then on the implementation plan is essential to me, and IMHO part of why people are surprised that I tend to get solid results from LLMs. At the very least, it allows me to fill gaps in my own knowledge (primarily front-end development) and be more productive than writing the code myself. I cannot stress enough how nice it is to have a partner in the high-level system design – yes, it often suggests utterly moronic ideas, but the overall experience is still net positive and getting better every quarter.
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
Interesting, I don’t see this very often with the latest models. Are you using Opus 5.5/Fable 5.1?
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.
> Interesting, I don’t see this very often with the latest models.
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?
What is it with the snide responses? This threads title is "Plan mode is dead", not "You don't need to plan anymore".
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.
> if I am not even quite sure what exactly I want to build myself
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.
You tell it, "let's brainstorm, don't implement anything yet". Then you talk about what you want to build and hammer out all the corner cases. Then you tell it "now do that".
My experience with that is not very good. It gets so hung up in its initial decision. Like, it won't make changes because they're "breaking", for something never even committed. Or it will litter the code base with defensive code and comments about the path not chosen.
> My experience with that is not very good. It gets so hung up in its initial decision. Like, it won't make changes because they're "breaking", for something never even committed.
This hasn't been my experience.
> Or it will litter the code base with defensive code and comments about the path not chosen.
I love when people on HN think they're special or do more "real" software engineering.
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.
The model is irrelevant, plan mode helps us ensure the model will actually do what we have in mind. The best model in the world can't work around misinterpretation because of bad specs. I'm not sure why this is even a discussion, isn't it obvious to anyone actually using LLMs?
This is an out of touch with reality thing to say. Remember: not everyone has access to unlimited usage/money to spend tokens or the most expensive models with the higher thinking settings, exceptions does not make the rules.
> This is an out of touch with reality thing to say
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.
Hey, well first off, congrats on making the greatest product ever probably.
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.
I’ve been having similar issues. Absolute love fable but it keeps leaving development servers running that are blocking port 3000 (rails apps run on this by default) and then when I try to launch the app and realize the port is in use I ask fable what’s up and it says sorry I left x running and then shuts it off freeing up the port.
Why would he have a field day with it? It seems he oscillates between finding models the greatest thing there is to being absolutely stupid so not sure in which direction you're implying he'd have a field day.
Theo is a YouTuber & prolific X tweeter who has a channel about AI. This is not Theo, but gives a flavour of Theo's style: https://youtu.be/h1p9zdUtUdo
I don't think me giving the model bad instructions is something a smarter model can solve. I use plan mode constantly (with opus/fable), and at least once a day I'll say something too vague or just dumb and it will sketch out the "wrong" solution in it's plan.
Which is fine because it just put together a plan and didn't spend 10 minutes rearchitecting everything.
I use fable 5.1 (tried opus but it lied to me 3 times in quick succession and ignored me in another)
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 happens with Opus when I leave too much up to interpretation and the AI doesn't do what I had envisioned but didn't specify. Like sure, what it did may be a technically correct solution but it's not the correct solution that allows for further development of my idea. I'm not sure how others do their projects but I start small with proof of concepts and develop in layers until the project does what I want. I use plan mode first to layout everything I can think of that I ultimately want and describe features in the best detail I can manage. I work with Claude to figure out the best framework or find whatever existing projects can serve as a starting point. The first milestone is the proof of concept, take the framework/existing project and build something that does the bare minimum of what I need in the way I want it done then build a test suite to make sure it works. Once that's proven out, we start adding more features (both mine and the ones Claude has suggested) and adding/revising tests along the way. For small things, I won't bother with a plan since I generally already know what I want or any ambiguities can be solved in a single response. 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. 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
Yeah IMO there's two entirely different traps I've seen in startup codebases in the last year or so:
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.
I haven’t tested with Claude specifically in a while, but I see this a lot on larger features.
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.
I've found Opus 5.5 is quite good at surfacing and clarifying these issues using Grilling[0]. Often I find that I want to expand the scope of work much larger than Claude would consider based on my original request.
We got Opus 5.5 just a few days ago so haven’t had time to learn its ways, and Fable was/is too expensive for many people including myself. Insiders have months to learn the ins and outs of new models.
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 have primarily used Fable 5, Fable 5.1, and now Opus 5.5. I never use shift-tab to enter plan mode personally. My general workflow is chatting with the machine to work out fiddly bits, then /plan to get everything in one document, and reviewing the plan.
/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.
For me, every day, although it fails far less often at this than Opus 5 did, which might as well have been a gremlin. It was a really poor technical writer too, leaving slop reminders to itself in all prose, including comments. So even if 5.5 fails less right this second, I have trouble believing that it all will not similarly bite me next week.
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.
How could a newer model be better at making up information? Do you understand basic information theory? Or maybe what you're saying is you don't actually have any ideas and are happy to do what everyone else has done before you so it makes no difference?
Why is “are you using the latest model?” the automatic response to any even mildly critical of LLM coding?
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.
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.
I guess that You dont need plan mode any more is ambiguous. I took it to mean you dont need to plan because the models are so good at infering intent. You are taking it as "you dont need a dedicated modality to create a plan".
It’s not that planning is dead, but rather that planning has outgrown the simple “Plan Mode” feature as models have become capable of taking longer turns.
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
Awesome blog. You're a good writer. I enjoyed seeing your article on AI in 2018. Thank you for sharing your expertise.
Also I hope your delivery goes well. My wife (and co-founder) had a challenging delivery and it really put life in to perspective for both of us on a range of issues (how much women's pain is minimized in the health system requiring stronger personal advocacy than I would ever have expected).
As far as plan mode, I still find it essential in keeping agents on track. I build propelcode.app and have a variation on plan mode I still find useful, happy to trade notes on agentic coding if youre interested.
I'm not the person who responded to you but I hope they're able to help her and she's okay.
And thank you for the article - it was a good read. I still see folks in my org playing "throw spaghetti at the wall and see what works" and getting frustrated so plan mode (mostly point 2) has been their guardrails almost as much as for the AI.
I never understood fear and anxiety until I had a kid and was worried about her safety. I am sorry youre facing that and hope she recovers and thrives.
Can't help but think "Doesn't matter if a machine or a human with (even slightly) different background wrote it", maximizing information flow is maximizing common assumptions and "culture" to only have to communicate a small set of current information for the task at hand. Being a team means having built a joint context so to say. This has always been the purpose of design documents and they always were too big or too small. Because you did not write them, but the others. If you only produce code you think they are the past and useless. If you iterate and your team grows, you start seeing the value in always current docs that are containing just what is not in your everyday culture.
All the best for you and your growing family. I had a similar experience recalibrating my values...
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.
Hence why the Anthropic employee is telling you to not use it and just aimlessly throw tokens at a wall. It'll eventually get you there, sure, and consume more tokens. This sounds absurd, but trust that Anthropic (and any large company) is hyper aware of how customer behavior impacts their revenue, and they certainly will try to steer you into behavior that increases revenue.
Also this is a way less removed process that I want nothing to do with. The more removed I am from the process the more I hate my job, get burned out and genuinely wish that Anthropic never existed.
Even if it could "just know" or infer my intent. It wouldnt be desirable.
Edit: Oh yeah its Boris, hes one or the most disengenous shovel sellers on earth right now.
So you think telling a model once to "do not write code, just plan" vs having an enum that causes that same text to be added to each message will somehow waste tokens and will surely make anthropic much better off..
I mean if you want it to plan something without writing code first you literally just need to ask it to plan out the implementation first it's not exactly a difficult concept
The Anthropic employee literally told you plan mode is a "we're still planning!!!" at the end of the prompt. Plan mode is useless because you can literally type "dont write code yet" and get the same effect, not because you should never plan in general.
Sure and I should also have been more specific, I don't always use "plan mode" I often just do planning without explicitly activating it just via prompting, point being that the robot doesn't work for me without some time spent planning out what to do.
* 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 tried plan mode when we first added it to github copilot and it didn’t stick for me, until very recently, when I used it the way you describe. I was just putting it too early in the process, turns out I have to do a bit of exploration and discovery on my own and most of the time I can skip plan but now I have an intuition for when to engage it so it can interview me to clarify the last few things it needs before implementation. This also made autopilot mode work a lot better for me.
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.
> 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.
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.
GitHub Copilot for VS Code by default configures "Plan" mode to disable everything except reading, asking the user questions, and writing into the memory scratchpad.
Claude Code's tool system feels quite rudimentary in comparison, but that's what you get I guess when you're only working with models you're going to finetune on being able to handle specifically your own tools anyway.
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 don't use Plan mode because I plan out work with a ticket based approach (that also works as a memory store), but I wish there were some kind of Plan mode like harness feature to try as hard as possible to stop it from beginning to code. With the newer models, I have started to have a lot of trouble with them proceeding through the QA with me where I scope out the work and refine requirements and then immediately begin to do the work rather than either making tickets or giving me the full plan to thumbs up like I tell them to do.
So it sounds like we use it somewhat similarly, just taking a glance at it before the work starts, and that's becoming harder to do in my experience. It is important because problems with the overall plan or strategy end up magnified the further you proceed with development.
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. :)
I'm hoping that by "gets it," he meant that if you start a discussion about the design, it doesn't misunderstand and immediately go off to do the work. Some models tend to do this.
Whether or not a distinct "plan mode" is needed, upfront planning remains essential in my experience, even with Fable (albeit not the 5.1 version). I agree that, as the models get better, you can skip planning on increasingly complicated tasks.
But there is still a ceiling above which it is necessary to "preload" the context window before starting to call tools and get into the meat of the work. You want to establish domain language (especially with Claude models which otherwise will invent their own, and it will be inscrutable) and key requirements and assumptions. You want to do a Q&A iteration cycle with the LLM. You definitely should do a sanity check that the LLM actually "understands" what you were trying to achieve, and then make sure that understanding is coherently and plainly stated in the prompt. All of that seems to be necessary still for just about any serious task, if you actually care about the quality of the results and/or don't want to burn hundreds of thousands of tokens on flailing around to get to a good quality result.
So no, you don't "need" plan mode. But you do still need to do all of the things you would do with plan mode.
But in your example you never even asked it to plan so you could check the implementation before writing it you just asked it to write it directly, so this isn't even a comparison to plan mode
Apologies, I didn’t mean to imply it’s a benchmark, I just wanted to provide a reproducible example of where I see models make decisions that seem to be fine initially but might paint the software architecture into a challenging corner. I don’t expect models to read my mind, but I do see them produce a lot of verbose output, none of which is used to say “here’s a simple response to your ask, but have you also considered...”
I think knowing which models use the standard library and which ones pull in dependencies as highly useful. As a dev I've always favored staying as close to the standard library as possible as it makes refactoring, understanding, and deletion much easier. Not everyone has the same preferences as you, it's nice to understand what matters for others too.
> 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.
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.
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.
FYI I had Clod attempt to corrupt a prod db the other day. (Opus 5)
I was experimenting with a rather complicated backfill operation, were I had a validation script I understand and have Clod come up with the backfill script. I was running against a local prod copy, and it proposed running the actual (unfinished) backfill script against prod.
It didn't have access to the secrets and I also caught the command, but a good reminder that this stuff needs guardrails.
yeah that's crazy. its so good 99% of the time but I've seen it have some insane hallucinations before (as late as Fable... cant remember if it was Fable 5 or Fable 5.1).
Hallucination not a big deal when it's on the surface layer. But I can't imagine the damage it could do if it hallucinated while building/validating a "load-bearing" component and then continued down that path
yeah (at an early stage data-focused startup). I think when our product is a bit more mature we'd probably have a staging tier with full access and then manually promote builds / DB changes to prod. So many things to build lol
we DO daily snapshotting, so the risk is limited... but still spooks me
> 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
It’s bizarre to me that Claude Code doesn’t have more guardrails on plan mode. I mostly use Copilot and the plan mode there has teeth. In plan the agent does not have permission to write to the filesystem outside of a temp directory and the plan document itself, and tool calling is heavily restricted.
There’s also a “ask” mode which is read only. Both are enforced by the permissions model, not just a system prompt instruction. I’ve seen the model “forget” and try to start coding - it bounces off a hard permissions failure and that “reminds” it that it’s in plan mode.
In my experience, around the time the author describes as starting to not need plan mode is when erasing the chat history became an anti-feature. I found the agents were doing better when they had the context already, and with the history I no longer needed to micro-manage persisting various caveats and rejections to the plan artifact. The amount of prompt construction necessary went down overall.
By the time my plan’s done I’m usually between 200 and 350k context. Even if keeping that around gives a performance bump for the implementation (which I haven’t noticed to be the case) it balloons the cost. I would much rather put everything in a plan file and start fresh.
Plus, I usually plan with a more expensive model and guide implementation with a cheaper model (with smaller validation calls back to a more expensive model)
that still essentially works. ask it to write a plan doc to a file. then when you're ready to implement, start a new session with a prompt to review the plan doc and then start building.
To be fair, the team also neglected the functionalities of plan mode. It was unusable for since july when they removed the option of running /clear before implementing a plan. Also, there was a period of time during the dark periods of opus 5 and nerfed fable 5, whereby if you didnt explicitly request for code, it went on an on for a few sessions planning and researching in a loop.
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 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.
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" :)
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.
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).
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.
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 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.
Agree, and for me I feel like I often have more implicit intentions than I write in a prompt. A plan helps me verify whether an agent gets these right or not. Plus, it highlights tradeoffs I might've not thought about. Removing both feels like lowering a quality bar.
On the other hand, for a low effort hobby project: just do the thing.
It is absolutely true that Opus 5.5 just ‘gets it’ far more often than gpt-5.6-sol, which is more like an idiot savant. It can nearly always do what you ask it to, but that might not be what you want.
Yer, it’s probably best to face reality and understand that for actual software engineering / complex coding work - Anthropic models are way ahead of OpenAIs…
I am curious what your take is on skill packages like Obra/Superpowers and grillme and the like. On one hand I find them extremely useful for asking me questions. I wouldn't have thought of myself or that I don't feel I would have necessarily gotten in a structured a format just by having the AI interview me. On the other hand, I am not sure how to tell when they have become obsolete because I'm not sure where to even start with generating evals for such a thing.
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.
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.
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 specifically work in tooling now, so this probably applies more to that domain than some others, but I find 'very up-front spec-driven development' unappealing for that kind of work.
I'm experimenting just like everyone else, but this is my process right now:
- Quick prototype
- Figure out the language of your app (what terms you want to use for things, what your UI design language will be, etc) and spec that, so you can use words consistently with the agent. You need to be able to describe the things you want well and consistently.
- Keep prototyping. Let the agent write unit tests along the way. Lock down behaviour you like, keep track of those things in a document.
- At some point your idea of the real architecture comes into focus, from actual use cases -- avoids the over-abstracting right away trap.
- Refactoring is cheap with tests, so start refactoring into the architecture you want.
- Your architecture won't necessarily be what would be best for a human, but it will be pretty close.
- Keep relentlessly iterating on small work.
- Things that were expensive before aren't that expensive now -- integrating a library, changing from one library to another, trying out a few architectural refactors, trying out different performance optimizations, etc. That stuff is all 'throw it there and see what sticks' now, so don't be afraid to try stuff which felt big before.
I feel like 'front loading' too much is just the wrong approach. You might feel like you're sitting there 'babysitting the agent'; but that's just what the hard part of the work (hard as in 'zjust slogging through it', not as in 'conceptually complex') looks like now. Your code is much more like clay.
Atleast that's how I'm thinking about it so far, but I'm not working on large sprawling systems that I imagine would need more pre-planning.
I believe spec driven design is a good way to go. But that means keeping all your specs either in the repo (if you want the agent to be able to edit them) or available via for example MCP (if you think only humans should be able to edit them and you got some type of external documentation system keeping specs).
But given that running an agent us cheaper than the cost of waiting for a slot to assemble the team to talk about a change (isn’t it always?), why wait with running the agent?
I propose updating the spec then do the implementation. This will most likely show that a few assumptions were wrong forcing some major or minor updates to the spec. Work through those and then let your team review the spec change together with testing the next iteration of what what’s build.
I have found it doesn't see me any direct time. I either iterate ruthlessly on the spec or on the implementation.
I find that the code is generally in a better place proportionate to the amount of SDD I actually do. But it's just a matter of where and when I want to spend my time.
SDD is good. It's a lot faster and cheaper to have an agent polish a spec, than refactor code. The implementation can then be verified against the spec artifact, and any drift can feed back into process improvements for future specs.
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 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.
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.
What, are you suggesting that there were people already successfully doing agentic coding in CLI harnesses with a good number of features before November 2025, the moment HN collectively deciding that it was now "good enough", if using "Opus on Claude Code"? Blasphemy!
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").
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?
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.
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 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).
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 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.
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
Recently I started using pi as a harness and its flexibility has really changed the way I think about UI into agents. It feels like I took the red pill and have been liberated from the prescriptive nature of CC or codex. Instead of getting told here’s how you should approach ___, I pay much more attention to my workflows and when I feel friction I make the harness adapt and smooth it out.
For example, there are no shortage of web based uis for pi and they are all cool but I wanted a deep integration between artifacts and how I want to collaborate with the agent on them. So i built my own ui that mirrors what the pi tui sees. It’s chat based but has a deep integration with a GitHub style code review UI so I can leave review and comments whenever I want. Every agent message renders nicely in an annotatable markdown viewer so I don’t need an ask question tool and can more naturally get the agent on the same page as me. I want it to feel like I’m working with a colleague.
I don’t think these features are too unique but having full control over the experience is really nice. Flexibility over model provider, can tailor it to my work’s dev stack, and don’t need to worry about anyone breaking it with a million updates everyday.
Your perfect workflow can be realized in a day or so. You just need to go make it happen.
I also didn't like the chat TUI for back and forth on things, especially on long markdown files where I felt like I needed to copy a line to comment on it. I wonder if LLM companies would rather skip a step and aim for a world where most people one-shot things, which sounds much more impressive.
I've been building https://crit.md to keep that back and forth with agents - GitHub-esque interface and have agents respond to my feedback, iterating until I'm happy.
Admittedly like many others, I use it a lot less for actual plans now, models are indeed getting really good at just getting it.
I wodner what this product space will look like a year from now. Reviews are already dying.
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...
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.
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.
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 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.
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
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.
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?
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 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.
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.
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.
Author here. This isn’t the one true framework, but it is the one I use. The goal of this post was to communicate to the team the way I think. There are many ways to think and there isn’t one that is more correct than others.
The word “feedback” might be overloaded here also — if you haven’t worked in a culture where feedback is an honest, no-blame part of the culture, then I can see how the idea of giving feedback can feel like a disingenuous corp-speak way to make a person fall in line or have their career impacted. There’s also an inherent power dynamic in giving feedback. However, if the work culture celebrates feedback as an honest way to have more direct conversations, and makes coworkers feel psychologically safe talking to one another directly in this way, it is something that makes culture better for everyone and gives better results in the end. I have given feedback to many people, and I have received it in turn many times.
I appreciate you took the time to answer my post. Since you like honesty, let me say that I think your framework isn't terribly useful and, for most people, somewhat condescending coming from people in a leadership capacity. There's nothing wrong with your advice, but it's kind of generic and childish, like "in order to think, you have to think" with a hint of "move fast" corporate drivel.
I've worked in this culture. I was an IC, tech lead, lower and upper management in medium to large AAA tech companies, household names, that had the same sort of feedback focus.
I think the all-in feedback culture is overall a net negative because it invites this kind of micro-criticism, rules-driven feedback sharing.
Given that, all I can say is that while you're appear to be well intentioned, I would at most share your framework once or twice and stop pushing it, assuming you're doing that (it sounded like it). I can see most people being annoyed but this kind of framework and that's why my reply was so upvoted.
Thanks for sharing and engaging with the comments.
> Also, I am an IC, not a manager.
I think this understates the power dynamics involved. At your level, being an IC doesn’t mean you aren’t in a leadership position, and feedback from you can still carry substantial weight.
Psychological safety is a worthy aim, but it cannot be assumed, nor will everyone experience it equally. I’d be wary of relying on it too heavily here.
> There are many ways to think and there isn’t one that is more correct than others.
Charlie Munger once said "The right way to think is how Zeckhauser plays bridge. It's just that simple." He managed to boil it down to a single way to think. You disagree?
Quick feedback: this framework feels like a not so well thought out extension of polya’s how to solve it to “do things fast” in a credible looking way.
Harder feedback: the writeup feels like a quickly hacked together memo, which claims it is “self healingly” good. Because it has this throwaway quality I’m not sure what is the goal? Shall I engage with it seriously, when the lead dev didn’t seem to put in the effort? But if I don’t engage with it seriously it means that I have to follow this patchy fremwork?
I’m surprised that you haven’t noticed this yourself, this is an incredibly common issue.
I always thought that it was perhaps referencing something that’s in its hidden thinking tokens, but the grandparent’s explanation could also very well be it.
Yeah it's something server side if I recall correctly from the numerous threads, regular messages getting returned as thinking tokens or something strange.
I've got a Claude session going which can check sessions and count how many of these messages I haven't seen due to this bug.
On a similar topic - since you said "I always use" - is it true that nearly everyone at Anthropic is using Fable and that's why Opus 5's style of speech was not really noticed as problematic by Anthropic employees?
You actually don't speak for us. On the contrary, it is because of threads like this that I am aware of bcherny's reputation. You are woefully ill-equipped to be assigning value to anyone's contributions or policing their tone, especially as someone who so eagerly laps up what he is fed by bad-faith actors.
> I’m surprised that you haven’t noticed this yourself
To be fair, isn't this the standard response to issues everywhere? Generally, users will find edge cases in odd scenarios that are difficult to reproduce.
(But I do not use CC and have never looked at their issue trackers, so maybe I'm missing something.)
> To be fair, isn't this the standard response to issues everywhere?
No, not really. Anthropic is notorius for ignoring issues, pretending they don't exist, gaslighting and blaming users, then spending weeks fixing things that end up being obvious even to juniors.
At the same time they proudly tell everyone how they don't look at code anymore and only run a gazillion Claude sessions.
(I work at Anthropic) I agree. I use an LLM to write my code, but I do all of my writing by hand, since it helps me think.
It reminds me of the transition over the last year from AI-assisted coding to AI doing all the coding. At first the code output wasn't good enough, and humans read and iterated on the code all day, so the details of the source code mattered. Now, the code is largely high quality and it meets a large set of guardrails we've set up over the years (linters, typecheckers, security checks, LLM-assisted code quality checkers), and it's just Claude working on the code, so the details matter less and engineers think a level or two up (machine code < assembly/bytecode < source code < conversation with agent < artifact with high level design).
I wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document. But writing and coding are different enough in a number of ways that this is far from inevitable.
> wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document.
What use is that? I'm not being facetious, I'd really rather like to know.
Who or what is the audience for that sort of long form writing? If it's a human, why would they read it? They'd just give it to an LLM and get the salient points back. If the audience is another LLM, why expand it?
The only use case is an audience of humans who still read and understand, and those people aren't going to be interested in a message when it is not apparent that the sender actually understands the message themselves.
A lot of corporate documentation exists solely to measure if people are working or not.
That's why there's so many meetings in white collar companies. Because people can't understand what is going on at those documents so they just need to "align".
LLMs are amazing at generating this useless documentation that goes absolutely nowhere.
1. I have a bunch of data or research that I've gathered with a unique hypothesis
2. Having gotten my arms around that pile of information, I believe I have a compelling thesis to put forth
3. I design the narrative arc and of the thesis. The important parts, the necessary but not sufficient scaffolding.
4. An AI helps fill in the story from there. Fact checks each claim, connects the dots, makes it comprehensible.
Who is this for? Well, quite possibly the human who asked for it. It's pretty informative to read back a research brief in full that you helped do the scaffolding.
Also of very clear use is other AI's who did not have the same unique hypothesis and did not gather the supporting evidence. It's an interesting angle for others to build on.
And of course, other humans! Most human written content gets almost zero readers today as it is. And I suppose LLM content probably pulls the asymptote closer to zero, but some pieces of content may be genuinely interesting or useful.
> An AI helps fill in the story from there. Fact checks each claim, connects the dots, makes it comprehensible.
I think this certainly has some value but this claim in and of itself is stated like your hand-wavy step 3. How do they fact check claims and connect the dots?
Maybe LLMs get there but currently they write in an extremely verbose manner, and things that have gotten into the context window that are no longer relevant continue to stick around (just try having it write some code, then work some of it back to simplify the problem - it will insist on writing comments about code that no longer exists).
Right now using an LLM to write documents is like taking a superhighway to travel 100 meters. Yeah you're doing a lot but is all that really necessary?
I won't deny that LLMs will never have a place in writing. But I personally don't think the current form is "the one that actually lands" (!).
Then the reader can use an LLM to compress it back, and you can then interrogate it for details.
I used to say this was the future of advertising (cr sales person prompts “we have some new EV SUVs on the lot”; GPT generates an ad email with a synthetic video, blinking text etc; then the recipient’s spam processor tells them “that dealer has some new SUVs”. I suppose the same could happen with so-called “long form”.
> What use is that? I'm not being facetious, I'd really rather like to know.
People are terrible at writing. Near universally bad. Even good writers have drafts and editors.
There is a constant refrain here that somehow short messages are more valuable than longer ones. But that assumes it's understandable. Lots of short content is, frankly, awful because the writer cannot put themselves in the position of the reader and explain all the things around the point they're making that the reader really should be told.
You can view writing as translation. From your language to a language your audience speaks. At that level is it so odd if the word count differs from one side to the other?
But this is the same with coding. The reason that AI can write code from a description that is shorter than the output is in large part because it makes decisions about the behavior that were unspecified in your prompt. We accept this for coding apparently, I guess because those decisions are often unimportant. We might accept it for writing too. I hope not.
Not necessarily. Poorly worded, ambiguous, confusingly ordered writing can be massively improved without changing the core content. Better setups and explanations can be longer without changing the message or meaning.
Look at it the other way, could you take a good longer message you’ve written and make it shorter and less readable for your audience while still making sense to you and containing the key points?
wasn't it thoreau who said "Not that the story need be long, but it will take a long while to make it short"
personally, I think there's a time and place for short versus long, just like there's a time and place for a 45mins TV episode versus a 2 hour marathon movie.
You claim writing is thinking, but imply writing code isn't thinking.
My opinion of LLM design review isn't that high - it seems to miss design tweaks that could vastly simplify corner cases. But if your code isn't written for human consumption maybe it doesn't matter. I'm still directly responsible for what I commit, so I can't just offload it to Claude.
That's something I struggle with, I try to get LLMs to output code I don't care much about and focus on the parts I do and it kind of works but the problem is that reading code written by the LLM is even worth than reading LLM generating text. It's nauseating and you still have to read what the LLM did if you want to really work on the parts that matter.
People have been "writing code" like this for decades. That a programmer happens to do it doesn't turn it into writing code, no one would have made that claim 25 years ago, and people who aren't programmers wouldn't make that claim today.
It's like watching somebody about to be hit by a bus. You yell, you wave your arms, but they either don't hear you, or they don't believe you. The last thing that goes through their head is a Greyhound's hood ornament.
There is no subtext to bigstrat2003's argument, other than "I'm wrong, and I don't care." If you give persistent, repeatable instructions to a computer, you are programming it. If you disagree, you are gatekeeping. It's that simple.
The most popular programming languages in 2030 will, in fact, be English and Mandarin. Deal with it and get over it.
----------------
Edit, to bcrosby95: Look up the etymology of the word 'computer'. It didn't originally have anything to do with hardware. The first computers were people, who were told what to do ("programmed") without necessarily knowing what they were working on in a big-picture sense.
There is subtext to my argument, namely that you're the one standing in front of the bus, and trying to pull the rest of us in front of the bus, while shouting at the people standing safely out of the road. I'll continue to reject the replacement of humanity. (That doesn't mean remaining ignorant of AI as a technology. It means rejecting the idea that we should be thrilled to be replaced by AI.)
I'm game. Say $1000, donated to a charity of the winner's choice? How do you want to set the bet up, and how do you think it should be decided?
To be precise: I will bet that high-level programming languages won't be any less popular as a whole, but the vast majority of code will be written by AI rather than humans, working from specs written in natural language or something very close to it.
What we call "source code" today will be thought of as "object code" by 2030. Something that occasionally needs to be inspected by humans, but rarely authored directly. Anyone not writing code this way had better be doing it as a hobby, because almost no one will pay for it.
> You and the other poster just need to find some agreeable benchmark so you can decide who won.
That is the hard part. I'm not sure the usage numbers we'd need to decide the outcome are public now, and I can't predict ~4yr out whether any currently available metric will continue to be available. Stack Overflow's popular language thing has been going for a while, that will probably still exist (if SO does) but do we have any reliable metrics to tell us what fraction of code is AI generated?
I think the outcome will be very obvious when the the time comes to settle the bet, but I agree that it's not easy to write those terms today.
But speaking of Stack Overflow, that's a good point to examine more closely. Simply looking at Stack Overflow's usage trend [1] should have been a strong clue that a seismic shift was under way. A couple of things could be responsible for it, though:
1) Stack Overflow's movers and shakers have finally assholed themselves into irrelevance. That's possible, and it could potentially explain the secular decline that began around 2015. But it doesn't explain the rate of descent since 2023, given that the core rules haven't changed for years. It also doesn't explain the meteoric rise between 2008-2014. What they were doing clearly worked, right up until it didn't.
2) AI is now answering questions that would previously have been posted to SO. That's the conventional argument. Hard to dispute it. And it leads to...
3) Stack Overflow has not failed its mission, but fulfilled it: most of the code that will ever need to be written already has been. That's an argument I've never seen anyone else propose, likely because it's a really stupid argument that's been made many times before. I think it's true this time, though, at least until genuinely-new hardware paradigms come along. I think it's a big reason why AI will be doing our jobs for us going forward. Programming is a robot's job now.
3a) As a corollary not related to the SO question, I think the math community is starting to wake up to a similar realization: we have all the math we need. Or, rather, we have all the math we can comprehend. The low-hanging fruit is all gone. Mochizuki's work, which requires a large part of multiple peoples' careers to prove or refute, is an example of that phenomenon. Leading mathematicians are coming to recognize that their best shot at contributing to progress in math is to work on AI.
The groundwork has been laid, and now we need to find better ways to reuse and recycle what we have. That's how AI will help us reach the next level. It's just crazy to think that our industry will be recognizable in 3-5 more years.
Other person probably doesn’t like the idea that LLMs will replace hard earned skills. On the flip side, I bet you’ve seen your skills atrophy at an alarming rate and are trying to justify it.
Both sides come from fear. Just relax and take things as they come. Whatever happens happens.
Maybe. I'll have to think about that one. It doesn't feel like fear to me, but that could be some kind of coping mechanism. From where I sit, I don't believe I fear this AI stuff because I don't really see what all the fuss is about. I don't think I'll be replaced by Claude anytime soon, because fundamentally language models cannot do the things necessary to compete with me. They can generate large amounts of relatively mediocre code quickly, but that's not really what anyone expects of me in the workplace.
Instead, what I do is I think deeply and understand things. And I refine my understanding of those things. And eventually, I have some insight that proves extremely valuable to my employer. Or sometimes not! But on balance it tends to work out swimmingly in their favor. This may sometimes involve writing lots of code, sometimes it involves writing very tiny amounts of code. Sometimes it involves simply deleting code. But the code part of that job is really minimal. It's all the other things--developing understanding, having insights, thinking really hard, making connections, communicating--that are valuable. Banging out code was never a big deal. I'm good at writing clear, correct code and I believe I can do it better than an LLM, if not faster. But that never mattered very much, what actually matters is learning and adapting. I'll be scared when someone makes an "AI" that can do that competitively, but I'm not worried this will happen anytime soon.
So the premises of this "LLM crisis" seem deluded to me. The people saying "everyone will be using an LLM all day every day for their job" seem to have no idea what jobs are like or what LLMs are (in)capable of. The people talking about AI paperclip apocalypses seem like they're having a really bad drug trip. The stock market bros and VCs throwing money as hard as they can after whimsical sci-fi fantasies seem like they've gone completely batshit insane. Meanwhile managers are forcing workers to use LLMs for everything, for no clear reason, and push them into products where it does nothing good. So therefore every little spineless corporate toady is clambering on top of the other little spineless corporate toadies to show big mr manager what a good AI boy they are. It seems like y'all have lost your entire minds because the computer does words now.
It's not fear. It's disgust. I'm disgusted by all of this.
because fundamentally language models cannot do the things necessary to compete with me.
One imagines Lee Sedol telling himself the same thing. True one day and false the next.
It's all the other things--developing understanding, having insights, thinking really hard, making connections, communicating--that are valuable
Spend some time working with frontier models like Fable and Astra. It's clear you haven't. Or if you have, you haven't paid attention to anything but acceptance of the final work product.
"Thinking really hard," LOL. You won't beat an LLM at that. No one ever will again. Insights are still our domain as humans -- if only because the motivations behind them are still entirely ours -- but now we can put those insights into practice at a rate never possible before. And your reaction is disgust?
Meanwhile managers are forcing workers to use LLMs for everything, for no clear reason
I'm with you there. Don't worry, those managers will be the next to go.
Why is it always "you clearly haven't used the latest model, let me tell you this time it'll blow your socks off!"
How many times have we heard this? If it wasn't true all the other times why must I believe it now?
Here's a challenge: show something impressive. Show me how using your LLM will actually help me do something better. How come if this stuff is so great, it's just not all that obvious? I'm looking around and over the past year or 18mo I'm just not seeing a whole lot of change in software. Maybe increased bugs shipped?
How many times have we heard this? If it wasn't true all the other times why must I believe it now?
It was true the first time somebody said, "Hey, check out this ChatGPT thing." It blew my socks off. I still haven't found them. I guess they're probably behind the dryer or something.
I'm looking around and over the past year or 18mo I'm just not seeing a whole lot of change in software. Maybe increased bugs shipped?
I think you're just demanding too much too soon. Peoples' workflows are still adjusting. As you said yourself, correctly, management is being stupid about this whole thing.
The improvements won't all be visible at once. I will ship my next hardware product sooner than I would have, because Fable routed a board for me. Specifically, it wrote a Python program to solve a nasty routing problem that I just didn't feel like working on.
This morning, I was pissed because the volume shadow copy program I use for backups, Casper, screwed up a 30-hour job because it had scheduled a task behind my back, without my knowledge, that tried to perform the same backup to the same drive at the same time. Fable figured out what happened; all I knew was that the boot sector on the target drive was hosed. I will avoid that problem in the future by telling Fable or Astra to find me a simple command-line shadow copy utility that doesn't suck, and if no such utility exists, write it from scratch. That will not be a problem for Fable or Astra, but I wouldn't have dreamed of relying on an LLM to do that last year.
Will this win be visible to you, as a consumer? No, because LOL at anybody trying to sell something like that from here on out.
The software that I develop to support the hardware? I rarely work on it anymore, as of a few weeks ago. When I want a new feature added, I ask Claude (or, again, Astra, which is now better than Fable in some respects.) Claude could do a lot of that work last year, but it needed extensive babysitting. Now it has taste. It chooses the controls, lays out the dialog box and writes the help text. You won't notice the details as a consumer, you'll just see more rapid incremental improvements coming out for my software and ultimately the hardware as well.
Speaking of my very-obscure hardware, last week I ran into a very obscure firmware bug in some code I wrote. Or, rather, my customer did. Different customers are demanding both new features and bug fixes, and I only have the bandwidth for one of those. So: "Claude, see if you can figure out why the board stopped responding to input X when input Y went away. Here are the component data sheets." Took it about an hour but it would have taken me longer.
I would like to say I used the time it saved me to work in parallel on new features, but in reality I spent it here instead, arguing with Luddites. They say "you are your calendar," so I guess I enjoy that even more than building new stuff. Funny how much the clankers are teaching me about myself!
LLMs do not produce repeatable results, by their nature. Two people can give the exact same prompt to the exact same LLM and get different results. It's not a straightforward 1 + 1 always equals 2 process. This is like telling someone else to code something for you. You relinquish control of all the details.
Calling it gatekeeping is just laughable. That's like saying it's gatekeeping to say that the painter painted their painting, and that the person who commissioned the painting did not paint it. It's wholely absurd.
Anybody can pick up a book and learn to actually code themselves. Or you can use an LLM to try to make things without bothering with that. But even if the LLM worked perfectly, pretending these are the same thing is silly.
The history of the word computer is obviously irrelevant. Words change, it turns out.
It isn’t really by their nature that they don’t give repeatable results, right? They’re just a bunch of math, but they perform better with randomness injected so we choose do to so.
(I’ve heard about some GPU compute nuance meaning that even without randomness injected they still wouldn’t quite be deterministic, but that’s also not core to their nature)
You are just talking about the output though. If you only think at a "higher level" you aren't doing the actual thinking. Its the same with code. The output may be good enough, but over time you lose touch with the details to the extent that you can no longer serve a useful steering function for the organization. Before coding agents I'd seen this with many humans when they get promoted passed the point where they work with code directly and can't figure out how to add value there.
Expands into a document for _who_ to read? another LLM to re-compress?
It's baffling you people are in control of such a strong product when you are obsessed with this intellectual pornography; wow - look at how smart it made my thoughts look (n.b. look, not read). Don't look too close. And certainly don't ask me what it means.
Many programmers don't write long text; their way of getting a deep understanding of a problem domain is to build something, is to write code - in a process very similar to writing a long piece of text - it has the same reflection and externalization of thought.
The widespread introduction of LLM code generation is very destructive to that.
Perhaps LLMs can be brought to support human cognition in the same way writing can; but that has yet to be designed and it does not seem to be the way things are heading.
LLM prompts definitely don’t feel like “writing” to me in the way that writing a blog post (or even an HN comment) does or writing code used to. There is nothing to work out, you don’t really need to think. You’re _typing_ sure, but I don’t think it counts as writing maybe because the text that you write is thrown away.
I'm way more articulated now than I've ever been, because in the past I didn't have to -- I never write a blog post -- but I've learned that well thought-out writing, with clear description, will produce better code.
The bottom line is, prompting is definitely writing.
Idk man I get a ton out of gaming and other media. If I say “I’m a cinephile” no one bats an eye, it’s seen as elevated and intellectually stimulating. Your examples reflect more on the gate keeping we do with what’s considered “worthy of our time” and “art” than the value of LLM’s.
If you get an AI to review the code especially for security, it does a very good job st finding issues. Better than any human reviewers I have worked with, and getting better. As someone who works in security , I feel much less worried about security bugs on code reviewed by a AI for security issues, be it written by AI or human.
Compilers like GCC are deterministic and the source code already fully defines the behavior. LLMs are non-deterministic and will accept ambiguity, filling in details where you haven’t. These sorts of comparisons aren’t really fair.
In the case of writing, it’s like hiring someone to write a book for you vs. hiring someone to translate a book you wrote into another language. In the first case, you didn’t really define the message for readers, whereas in the second case you did, and the translator is converting that same message for another audience to consume.
Sure, but I don't know what GCC's behavior is, and I don't vet behavior differences between compiler upgrades. As long as the output works, why does it matter that the black box is deterministic?
It doesn’t matter how exactly GCC works, as long as the behavior is deterministic and consistent (GCC is likely maintaining backwards compatibility between versions, so the behavior of your code likely hasn’t changed). In that case, you can reason about the behavior you need and write your code appropriately.
In the case of LLMs, the behavior is non-deterministic and inconsistent. If I don’t explain how handle an edge case or give a performance constraint, the LLM will still produce code and may do so in different ways, handling edge cases differently and with different performance characteristics. I can’t reason about how the LLM will fill in those gaps, it’s “random.”
Maybe you don’t care about how the LLM handles those edge cases or handles performance, but that’s different than a deterministic abstraction whose implementation details you don’t care about, but whose logic and performance is deterministic and consistent
Sure, I manually test the output of the LLM. Manual testing is actually the main role for humans doing software engineering these days.
I wouldn't use it for flight control software yet, at least not without careful review, but most software isn't exactly critical. At the same time, I wouldn't trust flight control software that was only reviewed by humans, since AI is so much better at debugging.
We'll probably need humans in the loop for safety critical software for at least a year or two, before AI fully outpaces humans at generating correct code.
How so? As long as it works to spec, I haven't had anyone care. They literally hire people so they don't need to care about the details. Put money in, get working software out.
And, AI is rapidly getting better than people at both code review and authorship, so a human deeply involved is turning into nothing but a slowdown. The main purpose people have is testing that the specs were, in fact, implemented properly.
I guarantee your specs/testing are either inadequate and/or you're not leveraging lots of existing (and probably free open source) code that was already written by humans and meets the spec better without ever needing an LLM.
The vast majority of properly written software was already plumbing well over a decade ago. The software engineering is making high level decisions based on experience with respect to the existing tools and the needs of the business. If you're not already using LLMs that way, you would have been a similarly bad manager of human devs writing similar inadequate slop. Less code has always been better code.
The line in the sand for these arguments really ought to be whether you think LLMs are better than humans who actually know what they're doing.
If you think LLMs are better, or could get better while continuing to use statistical methods, you automatically lose the argument (delusional/ignorant) and any hope of regaining credibility. That's not dogma. That's the science.
No, because GCC doesn't randomly fuck up the assembly generation (much less on a fairly frequent basis the way LLMs do). If it did, you bet I'd be reviewing the assembly line by line, or decline to use such a poorly performing tool (as I have with LLMs).
For instructions you really care about, yes of course you review the assembly output! Usually when you're doing SIMD or want to check atomics are doing what you expect.
You can do that with LLMs for the parts you really care about too. The LLMs aren't regenerating the codebase from scratch every time, so the results stick around.
> wonder if long form writing will go the way of code.
I worry about AI Loopidity here though. Think about the similar analogy of email. If my set of ideas is condensable to bullet points, but I use AI to expand the content, then I add no information density and a lot of noise. Other folks then use AI to summarize the content to a list of bullet points, ideally the same but not certainly the same, and thus communication has been only partially successful.
> it's just Claude working on the code, so the details matter less
If you're not billed for usage, anyway.
Otherwise, for the other 99% of folks, that attitude is of course a pit trap that captures code bases and makes them maintainable only through the providers -- presumably one or few -- with a rich enough model to keep up with the growing mess. Preserving a code base that's legible, organized, and fundamentally maintainable by both humans and trailing commodity models is of imminent concern for anybody who doesn't want their margin strangled by your employer once it's too late to have other options.
As frontier capabilities advance, the details don't matter less; they matter more.
Writing is already amenable to many different levels of abstraction, though. If an LLM can expand your outline into writing, then you aren’t writing at the correct level of abstraction in my opinion; you should instead be explaining how you arrived at your chosen outline. You don’t need to explain the details because any party can generate those with an LLM; same as how many PRs today can be auto-generated and no one needs to read implementations; that is no longer the correct level abstraction to work at. This should actually free us to do work at a higher level of abstraction —- more consideration of strategy, objectives, etc and less worry about implementation details.
This only applies if LLMs aren't making mistakes 20% of the time and that's the problem. When you're only saving time on the easy part, it doesn't matter if you're working twice as fast because review of the tricky parts is still going to take 80% of what it would have taken to do the whole thing. Total effort ends up being more rather than less if you want the same quality.
I mean these are cold inhumane companies and their employees reflect it. SF is truly where human ingenuity goes to die, truly a blight on the industry as a whole and holding us back tremendously.
[non-AI org] I despise this and call it out every time I see it. Some dude hooked up an LLM autoresponder to his email, sent some nauseating AI slop to a huge distribution list.
I couldn’t help myself, replied and asked him for a recipe for delicious apple cobbler and hiking trail recommendations in Glasgow, which “he” immediately provided. Highlight of my career.
I think my core argument is this: I have access to every bit of information your AI does, so if I want an AI answer I’ll get one myself. If that isn’t true, why are you hoarding information? Push it somewhere we can all see it. So the only reason I would send you a message is to access _your_ brain. I have no interest in talking to an AI through a worse interface.
You could try this [0] I’ve started doing this and it’s helped a lot.
1. I understand fully the code and everything it does
2. You can pick up on mistakes super early and it can adjust the plan is it goes.
3. Faster than writing it by hand but slower than letting the LLM do it.
One could imagine a universe where the agent fills in citations and supportive points and so on, or makes a more conclusive argument but it seems you’d get better results leaving that to read time if it’s a one-shot. Steering prompts etc. with tool use to bring in other sources etc of course change this entirely. And regardless, I doubt we will read content like that directly ever again. Agents will act as per-person highly specialized adapter layers for information transmission.
The entire point is what runtime you’re running your code on. A computer with any modern stack requires a lot of text for you to communicate “spin a square around on its center” to it. A human requires only that short string because they have a faster natural language interpreter.
Text meant for a human can communicate “spin a square around its center” much better than any code that mimics it. In some sense, all programming is boilerplate expansion because computers have (until now) been unable to be programmed with anything approaching natural language.
> In some sense, all programming is boilerplate expansion because computers have (until now) been unable to be programmed with anything approaching natural language.
Maybe sometimes, but not always. When you need to actually render the thing you have all kinds of micro decisions, like where to put the square, what color, how fast it spins, etc.
You might not care about the details, but maybe you do. If it spins at 10000 rpm, will you care then?
Natural language, and human communication in general, is ambiguous, and coding is in great part about disambiguation.
Sure, you can use English to disambiguate as much as needed, but wouldn’t you then end up with some yaml-like spec that wasn’t much easier to create in the first place?
>(I work at Anthropic) I agree. I use an LLM to write my code, but I do all of my writing by hand, since it helps me think.
You get pushback for this? I saw an anthropic job post recently, and they wanted you specifically to have claude muck with your resume before applying.
I suspect some amount of long form writing will go the way of code - long form writing for the purpose of consumption by other AIs. Writing as a means of exchanging qualitative information, with no regard for how the reader will feel about it (beyond understanding what the words mean). Not everything can be distilled into data, but this doesn’t mean it is beyond the reach of LLMs.
On the other hand, long form writing for human consumption seems like it may evade LLMs for much, much longer.
What makes you think it will take a long time? AI seems capable of imitating any writing style if prompted to do so already, and I think it will get better on this quickly since the AI writing style is a main focus of AI labs right now. I can see no reason at all to believe this is a matter of years still, more like a few months.
The style you refer to is the "container" of the writing. The medium. Like the specific encoding of the message. What @arctic-true was talking about was the "content" of the writing, which is bounded from above[1] by the information content of the prompt.
So, I'm not sure if it's a question of time at all: if a LLM text contains some piece of information beyond the information that went into the prompt, where does this "extra" information come from? [Note, I'm not thinking about facts which could trivially come from the training corpus, I'm thinking specifically as information in the sense of intended message from sender (author) to receiver (reader)]
You can have a great “writing style” and still put together really crappy long-form work. The problem is that AI writing, particularly creative writing, is too repetitive, too predictable, too trope-laden.
All of the things you say are very true in the near term for short form writing - a page or two of Claudeslop will probably be much easier to swallow in a year or two than it is now. But I don’t see a path to fully AI-generated novels or long-form investigative journalism becoming mainstream in the next couple of years.
> I wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document.
You can already do this. And you can build pipelines where AI performs fact checks on what it writes, with citations a human can reference as well.
> I do all of my writing by hand, since it helps me think.
Later
> I wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document.
So in the future, it won't be necessary for you to think?
Kinda. Walking the dog with me this evening, Christa saw the license plate 8531 PRI and asked me if 8531 really was prime. The 2, 3, 5 checks are automatic, and 8531-8400 = 131, which obviously isn't divisible by 7, but I would've had to check the rest of the two-digit prime factors except 97 - 8531 is greater than 90 squared, less than 97 squared, though, I reckon. So I said I don't know. But Google would know, you know? If your LLM buddy is hanging out active on your phone all the time, it can - maybe not yet, but foreseeably - answer every question, no thought required, and carry out any expressed desire.
"You and the AI agree on an outline or other high level representation, then the LLM expands it into a document."
I am a subject matter expert in certain fields of real estate in Canada. This is how I draft my teaching materials, articles and educational content. I use it as a human amplifier of my brain as it increases my output which other people will pay money for. People who complain that LLM writing is slop have not encountered good AI-human hybrid outputs. Like visual effects in movies, the best examples are imperceptible and do not get in the way of storytelling.
Note: this is for Cowork, not sure if that makes a difference, I don't use the desktop app for coding.
Claude asked me a question at 12:05pm my time, came back at 12:40 and the question prompt disappeared and it spat back a message. Previously when I was writing a Google Doc, it would prompt me for questions, I'd come back and it would have timed out like this and just made a new version of the doc.
> The auto mode classifier uses a small number of extra tokens per tool call, and we're no longer charging Claude Code users on Pro, Max, and Team plans for that classifier overhead, effective today
This just sounds like they bump their unspecified limits by N% to cover this usage. Which of course means nothing because the next time they re-evaluate their limits they will just ignore this bump.
For those using Claude Code, I recommend Learning mode to instruct Claude to walk you through implementing the solution yourself rather than doing it for you. It’s very helpful when diving into a new domain, and helps build lower level intuition.
To enable it, run /config > output styles > Learning
Learning mode has been a huge help for me, it quickly became my favorite way to learn. I ended up created a “Coaching Mode” output style that took some of the learning concepts like stubbing todos for the users and added other intructions that better fit how I learn
reply