logoalt Hacker News

stingraycharles • today at 1:41 AM • 13 replies • view on HN

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


Replies

mikepurvis • today at 4:07 AM

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.

➕ show 10 replies
rickye26 • today at 8:15 PM

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.

jcelerier • today at 3:27 AM

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

➕ show 2 replies
technotony • today at 9:11 PM

That used to be my flow but I stripped it all out with opus 5.5 and it's working great. You don't need all the process anymore

nerdyadventurer • today at 2:10 AM

There is a popular skill for this kind of workflows: https://github.com/obra/superpowers

➕ show 3 replies
jaapz • today at 11:49 AM

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.

➕ show 1 reply
dmix • today at 1:54 AM

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.

soleveloper • today at 7:02 AM

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.

➕ show 1 reply
spike021 • today at 4:05 AM

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.

c_s_guy • today at 5:43 AM

> write down a markdown file with its plan, then review the plan using plannotator

How do I use plannotator to review an arbitrary markdown file? It always opens the Claude Code plan file for me.

➕ show 1 reply
jimbobimbo • today at 4:04 AM

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

Mond_ • today at 2:11 AM

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.

smnscu • today at 3:23 AM

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.