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

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

Yeah, it's way better when you do design documentation, or even ticketing, to instruct it not to include any implementation specifics. You're not doing the deep dive on the zero shot that writes the ticket or the document and so it is much less informed than the agent doing the work will be.

Or Kimi K3? /s

Some people are resource constrained.

These are self hosted for learning experience, I could have built an agent swarm in the cloud, but I'd never have learnt the fundamentals.

- Cold starts impact, context length issues, task lifecycle management

- Inefficiencies in delegation, necessitating workflow patterns for small projects (big AIs hide this problem until you scale and they hit the same issues).

- Limits of the AI would be harder to find or notice (e.g. where time - and cost - is being spent needlessly).

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

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

At the moment I'm still doing shakedowns, so Typescript games compilation with a menu that has 4 games and retro artwork.

This seems to be a good example because things like the menu, high score boards etc are common, but the games are distinct. Then there's the artwork which requires decisions on look, and for coordinating.

The Qwen 4B model is multimodal so part of the AC is to view the output - I've a robust anti AI-look QA chain for that I've been using elsewhere, e.g. no floating parts, consistency, obvious missing fingers etc etc.

The longer term plan is to do some llama.cpp refactors specifically for some target hardware I have and implementing slightly different novel architectures I'd like to try (one I did already targeted CPU inference, which I did using 3 agents with specific roles; main planner, QA for planner, and benchmarking/environment handling)

The implementation was 85% of the speed of the original maxed out on my hardware but performance scaled with CPU core count whereas the original implementation plateaued. Unfortunately the break even mark seemed to be around 30 - non HT - threads.

I suppose I should look at that one again, since the increase in cores did not linearly drop off performance e.g. due to memory contention.

Alternatively you could just use plan mode

developers have been complaining about AI supposedly killing their jobs, yet they want to take away the main feature that lets them be an active collaborator and participator in the process.

Goomba fallacy. These are two distinct groups of people.

I see what you mean, but I’m saying something else, I think plan modes were solving two different problems:

1. giving the agent sufficiently precise instructions 2. helping the human understand what’s being built

I think #1 is increasingly going away as models get better. #2 is a separate problem, and I actually think it matters more as agents get more capable. I’m not arguing that human understanding should disappear with plan mode.

I’m also not pushing this on behalf of a model lab, I don’t represent one. These are lessons I learned from my own mistakes building Nuanced (https://www.nuanced.dev). We built around a very explicit plan-oriented workflow because that’s how I used to work. I spent years at GitHub writing ADRs, RFCs, and design docs, and I still really like writing because it’s how I clarify my own thinking.

What changed for me is that AI-generated plans don’t give me that same effect. The agent reads between the lines, generates a lot of detailed prose, and now I’m parsing decisions and assumptions I didn’t actually make.

So I still think human understanding deserves a first-class primitive. I’m just increasingly unconvinced that a big blob of generated text is the right one, especially as we move toward many agents working in parallel.

There are many ways people solve this. I use spec directories, and the agents just keeps updating it as I make decisions. It isn't a single file, it's a directory; sometimes nested based on the size of the project. I'll have the directory open in my editor of choice. It being a directory allows me to use an arsenal of text tools, and also optionally commit it for history/tracking.

This tool is a difficult sell. Users _might_ consider an Open Source version, but switching people away from familiar tools is not easy.

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

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

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

There is a point, plan mode has harness level behaviour - it's restricted to readonly tools, and it re-reads its plan into context after compaction

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

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

early plan mode would just refuse to make edits at all

Plan forced the model to write down and outline what it was going to do before writing the code. As Boris said up thread, he created it to prevent it from just rushing into writing code. So that regard, it did act like a permission system.

It helps to think more abstractly when approaching problems like this.

What? Nothing to do with that

Yes, but plan mode wasn’t that.

You can use Docker’s sbx or similar VM/containers for that.

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

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

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

true dat

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

Codex and Claude Code are the best harnesses out there by a long shot. They work out of the box, require no real config, and just do the thing.

Even if I agreed, that doesn't address my point: Claude Code might be the world's best harness right now, but that doesn't stop an Anthropic employee coming along tomorrow and taking a giant steamy dump on the thing you like most about it. You're using their workflow, not your own.

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

The flag is:

    "showClearContextOnPlanAccept": true

Boris rationale was "with 1m context window, most users don't need it anymore."

https://x.com/bcherny/status/2035375125382451648

Yes, a conversation can be the plan. It helps if you ask it what the commits will be and then tell it to use subagents to implement them.

Also, since sometimes an AI can be a busy beaver, I added instructions to not edit any checked-in files if the prompt contains a question.

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

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

I'd like a brainstorming mode, with limited side effects.

I want it to go and read stuff but also invoke some commands and generate reports and discuss on the results. Latest GPTs in codex plan mode always go.. write a plan. Shocking, i know, but thats not what i want on every turn when im in that mode.

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.

wastes a ton of time

It wastes a ton of tokens as well and those are not cheap.

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?

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.

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

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.

Hi! Taking this moment to gripe; forgive me...

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 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 can relate to this. But this part doesn't make sense to me.

But for larger things, I try to take a waterfall approach with well defined milestones.

If I knew exactly how I was going to build something, I would have built it myself

Aren't these contradictory? If you don't know exactly what/how to build, how can you do waterfall?

when people on HN think they're special or do more "real" software engineering.

But you're doing the same with your "how it's done these days".

These days things are done in many contradicting ways, and it probably will take at least a few years to settle on common normal.

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've definitely seen this, though.

I have something like this in my default rules which Claude has consistently always loaded before doing any work. Works really well!

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.

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.

That sounds like a contorted way of saying "better."

It’s just surprising how few people understand this. It’s not like it’s new either. Polyani’s theory of tacit knowledge captured this back in 1958

"Marketing hat" is extremely civil. Back off.

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.

Engineers can nevertheless also be marketers for their employer's products.

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.

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?

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.

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.

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

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

This is the process I generally use too. Small plans you can just ask for, and big plans you work through building a plan.md file before you build it.

That also makes it easier to adversarially review the plan (I have Fable write the plan, then review it with Astra and another Fable instance).

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.

the thing is it fails on CSS most of time, I experienced it and it takes a lot of time to fix again and again, and ruin the code sometimes

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

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.

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

Did you just invent "agile" maybe. ;)

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

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.

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

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

Make a db replica or just a db user account with readonly permissions, and have only those in your env, or docs accessible to agent. It's liberating.

Oh gods, I don't give it write access to my actual DB.

For my small-scale sqlite dB, it gets read access, and I encourage it to test modifications by copying it somewhere and writing into that.

Scale-dependent, but I hope to not have to work at a scale where it gets write access to the production DB. That just seems like asking for trouble.

Plan mode was great, but I realized I progressed well beyond it. I found that I was getting these categories repeated errors and oversights from Claude (and frankly it hasn't gotten much better about this). Skills were too generic and got lost to context.

I ended up building out tool an MCP server that I use as a bit of a psuedo harness for Claude. I have a variety of multi-step workflows that are basically micro-skills stacked on top of each other. This helps me make sure that I can get Claude to think in a repeatable and reliable manner.

For coding, I've found that I have a few specific steps that Claude needs to do before I'm comfortable letting it loose:

* It must extensively explore the code base (including certain areas that it misses)

* It must think about what it doesn't know or is making assumptions about

* It MUST scaffold out it's intentions. Essentially, it can write comments, classes, and method stubs - but no actual content. Very much like a spec, but since it's in and alongside other code, it's much easier to identify problems.

* It must spike and validate key assumptions. This, plus the prior step, are the only way I've figured out how to avoid it ending up in a confusion loop. Too often it looks at poor-quality code it's written and thinks it's a long-term solution. By avoiding writing code as much as possible, it knows that it's draft content.

* Only, then can I review it and send it it.

Said MCP server (missing the actual ops): https://github.com/clops-mcp/clops-mcp

Perhaps not that fantastically given the url doesn't load. :)

Good old "Check out my new awesome app: http://localhost:3000"

Is this what happens when you vibe code long enough?

Hahaha

https://innerloop.works/breadcrumb

What a rookie mistake!

Now if only the human would write its own comment.

Perhaps it depends on where you live? It is a common enough term in parts of England

It is 100% Claude

For me its like a dry-run.

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.

thats a feature flag you can gurn on still

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.

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.

https://plannotator.ai/

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.

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

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

You can only fit so many bits of watermarks in code... but comments on the other hand, the possibilities are endless!

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.

I use similar approach, but use gpt to review plan written by opus.

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.

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.

Look into beads/dolt then - it does this pretty much with a cli - Jira for agents :)

Wow. It's like beads++

Great work man.

Oh shit, this looks incredible. Thanks!

Not OP but will definitely have a look.

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.

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.

13:37 - 13:49

“ayy lmao”

httpd://recursive-mode.dev

https://recursive-mode.dev

I used taskwarrior for myself and agents, but felt it was insufficient for agentic era in many ways, so I started building my own a while back:

https://aventasks.dev/

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.

That sounds very similar to just manually compacting after every message. Is there a difference I'm not seeing?

On the quick start page it looks like you just pass it as a CLI argument: https://docs.plannotator.ai/open-source/start/quickstart

Couldn't you commit the plan markdown to git to get the tracking you're referring to?

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.

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

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.

Do you think this is a good practice?

For who? The more control you hand over to the AI and let it think for you with no supervision, the better it is for Anthropic

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.

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

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

It’s just an odd way to judge whether an entire model “gets it” in my opinion. There are so many variables.

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

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

It can't read your mind that you have an HSM, can it?

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?

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

plan mode was useful, and is no longer useful.

In Claude Code, all plan mode does is add a little reminder to every user message along the lines of “you’re in plan mode, please don’t code yet"

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

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

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

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

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.

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.

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

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

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.

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…

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.

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.

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

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.

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?

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

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

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

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.

I work on Claude Code

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

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.

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

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.

So planning mode is dead, long live planning?

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.

You can still do planning as a phase without using an official plan mode you literally just ask it to plan first...

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!

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

planning had become interactive and iterative

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

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

Good to hear, this is my experience also:

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

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

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

(happily using Claude Code Opus 5.5 on High rn)

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

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.

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

# YOLO 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 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 was thinking of making (locally) an “artifact mode” along those same lines. It’s a much better way to see proposed changes

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.

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

If you want to see an even more heavy/"extreme" example of this, there was this HN post & blog some months ago on Claude Design.

Basically, Claude Design is primarily a huge prompt.

That's all.

There's no "magic sauce", and with the right tools to call, even your local LLM can implement "Qwen Design".

(Disclaimer, I work at github)

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

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

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

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

Probably the same way they have for the last 30 years: poorly, in a dozen different ways, depending on what that particular hiring manager thinks has correlated with successful hiring in the past

I can imagine a code review where you're asked to implement and merge 10 PR in a sample codebase and the codebase is littered with the sorts of mistakes and slop that vibe coders put in when they're careless and you're asked to correct the mess and make it work.

Future hiring will select for people that shipped the most, plain and simple.

The tech debt concerns are much ado about nothing. Use the next model to clean it up, big deal. Code is cheap.

The people that sat around handwringing about tech debt and trying to read every line of LLM code will really struggle to find a job. The profession fundamentally changed, and these people did not catch up.

No one at a FAANG is fixing things manually these days.

If it turns into a hairball, just have a few agents rewrite it.

Do you think the average dev is better than frontier models when it comes to spotting defects and security holes?

What a very useful definition.

You’re being too abstract ;)

I think the main problem with this statement is that different facets of an entity are abstracted at different rates.

AI abstracts effort and cognitive load away from code at a heafty rate, but it doesn’t abstract liability away from code at all.

My business is paid to produce artefacts for which it has liability in the case of error, so we need to do additional work to mitigate and eliminate the liability risk introduced with language models. So far I’ve not found a better way to do that than a plan/act/assert type approach on every feature.

That's true, but it's also prone to over documenting. As an example, for some reason it always tries to include a diagram of the folder structure in the project. I think that's not really useful and it's something that changes so often it's not worth documenting

This, and maintaining the spec is a cat-and-mouse game precisely to cover those edge cases.

Like "if you're using this database, and the engine has these configurations, then do _x_, unless _x'_ and _y'_ are enabled, in which case, do _y_..."

Which, if you're already being THAT specific in your spec, you might as well, idk, write the code yourself?

Because at that point your human language is basically the code and AI is the compiler. A non-deterministic one.

Regardless, your business stakeholders won't understand what's going on anyway (nor should they), so we're back at square zero.

(I wrote Technical and Functional Requirements Documents as a business analyst in college. What's happening now _for most situations_ is more or less the same thing.)

At the same time if the organisation want code fast, it gets code fast.

The revenue for a new feature today is something sure. While the cost associated with supporting such feature will be up to debate in the coming quarters.

As often it is the case, we are moving on a long vs short term trade-off space. And I don't think any experience will generalize

I'm not saying we can get rid of humans (yet). I'm saying that it's not critical to write and review the code yourself anymore, and that the LLM is the new layer of abstraction through which code is written.

Today, an agent can chew through years of history and artifacts on a large codebase in a half hour, documenting as it goes, and have way better understanding of it than I ever will.

At my last job we worked in a large, but publicly available code base. My experience was that just giving an agent the prompt to look at area X to figure out how it works would use up half or more of the context window. And that was thrown away every time we started again. We had docs, agent generated overviews but the agents still filled their context windows way too quickly to actually really be any use.

Exactly. As someone much smarter than me once argued here on HN, the value of a software company is less in the software but much more in the mental map the team has built of the problem and of how the software solves it. Throw the team / mental map away and you'll have a very hard time maintaining the software.

The difference is, you can perfectly understand that C, and own it.

and there is a community of developers who care about the quality of those libraries and take the weight of their responsibility seriously

hundreds of MB to GB of code from god knows where doing god knows what

If you use established libraries then actually the code IS well known to someone (and likely many), even if that's not you. Likely it was built with an actual purpose and with the foresight to not add red herrings to the design.

You can't say any of that for the equivalent amount generated lines. Literally no one knows what it does.

moreover there is not a black and white "code you can read" and "code you cannot read", there is a spectrum between. In this era, IMO if you know which module do what kind of function it should be enough, you don't need to have deep understanding of the file.

I care!

What happens when the maintainers lose access to frontier models because of cost, politics or other external factors? What happens if they don't have enough hardware to spin up an open-weights model?

I've seen variants of this play out before AI, so I can tell you: they will inherit a codebase they've never seen before, take forever to ship fixes (forget new features), and they'll either scrap it, completely rewrite it, or, if they're "enterprise" enough, will pay consulting companies literal mountains of cash to make it their problem.

The whole point of writing simple code was to write code that other humans can maintain. If AI is here to stay and becomes economical enough for everyone to use it, then you're right; writing code for other humans is no longer useful. If that doesn't happen though...developers who can/want to still code by hand will be loving life

I am reminded of the cartoons where the car kept going faster and faster, the driver kept pushing on the pedal, parts started to fly out, the gauges started to go in circles, smoke started to billow out of everywhere and then boom!

I guess we just wait for the boom.

Long term, that also just seems like a matter of spending enough tokens. I.e. we have these "red team" AIs that are finding security bugs in very mature software. As AI improves it seems you will be able to just point them at your copy, spend enough tokens and get most of the bugs.

Well they had actual people who understood the code - because they wrote it and had a mental model pretty deep. Now the people owning the code don't understand it.

Won't you be worried if your mechanic didn't understand your car but offloaded it to a robot that made mistakes all the time?

I do try to learn how systems work and remove "abstractions" as much as I can. I do that with coding and my personal life.

Actually baking is a good example, I used to be really bad so I spent time learning. I don't do it every day but now I understand how bread is made. I bought a 3D printer so I could print parts to fix stuff myself. I learned to do my own oil changes, I learned how engines work, etc.

My point is that I try to learn more, not less, which is what AI is trying to achieve

They believe they know, because they have LLMs to tell them, but they don’t often get to the point of being able to have a conversation about it

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

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

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

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

My experience is this is great when the model surfaces something to you. But I'm constantly caught off-guard by things the model didn't volunteer, things I would have quickly stumbled upon if I was working on code the traditional way. The model didn't think it was relevant but I sure do.

In my experience having the agent explain the code doesn’t work very well for real world apps, even the parts written by humans. For example we tried using to generate diagrams, class hierarchies, etc as part of documentation. If you don’t know the code it looks great. If you do, it’s focusing on all the wrong things, missing the mental model, and ignoring lots of important bits. And Claude tends to be extremely verbose to the point of muddling things.

I have, on a lark, reached 20 to 30 adversarial sessions a few times. For some tasks, the sessions will just never converge on anything that yet another session won't find fault with, recommending an alternative already ruled out by another session. Even if all the reasoning in between was documented, the new sessions will endlessly claim to find flaws in past reasoning.

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

We're uh.. we're a well known and widely used piece of software. There is an insanely large amount of testing that needs to go in to each change across many platforms and configurations and we have a lot of devs hammering that system with changes to test. Even worse now because of AI...

Lol sure dude.

The quote is so simple that there are obviously no deficiencies in it

The point of "ship, ship, ship" is to cash in (in terms of your career or company) before AGI renders you jobless.

If we get to post-scarcity you never needed the money. But if we end up in some dystopian hellhole where people have no jobs but capitalism still exists, you'll be thankful.

We get it, the future can't come fast enough for you. Code is a commodity and the only important thing is scale. Congratulations on leapfrogging the midwits on the path to the C-suite!

Define "mission critical" and then maybe we can come up with a reasonable estimate.

its objectively not engineering