Live data from Hacker News

How I use Claude Code: Separation of planning and execution

boristane.com

411–420 of 630 posts

Re: How I use Claude Code: Separation of planning and execution

#412
post #218

> the workflow I’ve settled into is radically different from what most people do with AI coding tools This looks exactly like what anthropic recommends as the best practice for using Claude Code. Textbook. It also exposes a major downside of this approach: if you don't plan perfectly, you'll have to start over from scratch if anything goes wrong. I've found a much better approach in doing a design -> plan -> execute…

How can you know that 100k lines plan is not just slop?

Just because plan is elaborate doesn’t mean it makes sense.

Re: How I use Claude Code: Separation of planning and execution

#413
post #218

> the workflow I’ve settled into is radically different from what most people do with AI coding tools This looks exactly like what anthropic recommends as the best practice for using Claude Code. Textbook. It also exposes a major downside of this approach: if you don't plan perfectly, you'll have to start over from scratch if anything goes wrong. I've found a much better approach in doing a design -> plan -> execute…

if you don't plan perfectly, you'll have to start over from scratch if anything goes wrong This is my experience too, but it's pushed me to make much smaller plans and to commit things to a feature branch far more atomically so I can revert a step to the previous commit, or bin the entire feature by going back to main. I do this far more now than I ever did when I was writing the code by hand. This is how developers…

We're learning the lessons of Agile all over again.

Re: How I use Claude Code: Separation of planning and execution

#414
post #12

> Notice the language: “deeply”, “in great details”, “intricacies”, “go through everything”. This isn’t fluff. Without these words, Claude will skim. It’ll read a file, see what a function does at the signature level, and move on. You need to signal that surface-level reading is not acceptable. This makes no sense to my intuition of how an LLM works. It's not that I don't believe this works, but my mental model doesn…

How anybody can read stuff like this and still take all this seriously is beyond me. This is becoming the engineering equivalent of astrology.

We have tests and benchmarks to measure it though.

Re: How I use Claude Code: Separation of planning and execution

#415
post #403

I just use Jesse’s “superpowers” plugin. It does all of this but also steps you through the design and gives you bite sized chunks and you make architecture decisions along the way. Far better than making big changes to an already established plan.

Link for those interested: https://claude.com/plugins/superpowers

I suggest reading the tests that Superpowers author has come up with for testing the skills. See the GitHub repo.

Re: How I use Claude Code: Separation of planning and execution

#416
post #374

Earlier quoted context omitted.

What genuinely new thing have you produced?

Well I'm actually producing, not having an llm do things for me and frying my brain in the process. If you're building things with the process described above you're not producing anything, Dalio or Altman's GPUs are, you're simply just a slot machine user. Have fun paying for "Think for me Saas". 2025-2026: The year everyone became the mental equivalent of obese and let their brain atrophy. There are no shortcuts in…

By that logic, compilers ruined programming and calculators killed math.

If someone’s brain atrophies, that’s a user problem, not a tool problem.

Re: How I use Claude Code: Separation of planning and execution

#417
post #330
post #323

Earlier quoted context omitted.

I don't judge content for being AI written, I judge it for the content itself (just like with code). However I do find the standard out-of-the-box style very grating. Call it faux-chummy linkedin corporate workslop style. Why don't people give the llm a steer on style? Either based on your personal style or at least on a writer whose style you admire. That should be easier.

Because they think this is good writing. You can’t correct what you don’t have taste for. Most software engineers think that reading books means reading NYT non-fiction bestsellers.

While I agree with:

> Because they think this is good writing. You can’t correct what you don’t have taste for.

I have to disagree about:

> Most software engineers think that reading books means reading NYT non-fiction bestsellers.

There's a lot of scifi and fantasy in nerd circles, too. Douglas Adams, Terry Pratchett, Vernor Vinge, Charlie Stross, Iain M Banks, Arthur C Clarke, and so on.

But simply enjoying good writing is not enough to fully get what makes writing good. Even writing is not itself enough to get such a taste: thinking of Arthur C Clarke, I've just finished 3001, and at the end Clarke gives thanks to his editors, noting his own experience as an editor meant he held a higher regard for editors than many writers seemed to. Stross has, likewise, blogged about how writing a manuscript is only the first half of writing a book, because then you need to edit the thing.

Re: How I use Claude Code: Separation of planning and execution

#418
I think the real value here isn’t “planning vs not planning,” it’s forcing the model to surface its assumptions before they harden into code.

LLMs don’t usually fail at syntax. They fail at invisible assumptions about architecture, constraints, invariants, etc. A written plan becomes a debugging surface for those assumptions.

Re: How I use Claude Code: Separation of planning and execution

#419

The author seems to think they've hit upon something revolutionary... They've actually hit upon something that several of us have evolved to naturally. LLM's are like unreliable interns with boundless energy. They make silly mistakes, wander into annoying structural traps, and have to be unwound if left to their own devices. It's like the genie that almost pathologically misinterprets your wishes. So, how do you solv…

If you have a big rules file you’re in the right direction but still not there. Just as with humans, the key is that your architecture should make it very difficult to break the rules by accident and still be able to compile/run with correct exit status.

My architecture is so beautifully strong that even LLMs and human juniors can’t box their way out of it.

Re: How I use Claude Code: Separation of planning and execution

#420

The author seems to think they've hit upon something revolutionary... They've actually hit upon something that several of us have evolved to naturally. LLM's are like unreliable interns with boundless energy. They make silly mistakes, wander into annoying structural traps, and have to be unwound if left to their own devices. It's like the genie that almost pathologically misinterprets your wishes. So, how do you solv…

It feels like retracing the history of software project management. The post is quite waterfall-like. Writing a lot of docs and specs upfront then implementing. Another approach is to just YOLO (on a new branch) make it write up the lessons afterwards, then start a new more informed try and throw away the first. Or any other combo. For me what works well is to ask it to write some code upfront to verify its assumptio…

[deleted]
Post reply on HN