Live data from Hacker News

How I use Claude Code: Separation of planning and execution

boristane.com

261–270 of 630 posts

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

#261

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…

[deleted]

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

#262

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…

[flagged]

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

#263

Earlier quoted context omitted.

wtf, why would you write 100k lines of plan to produce 30k loc.. JUST WRITE THE CODE!!!

They didn't write 100k plan lines. The llm did (99.9% of it at least or more). Writing 30k by hand would take weeks if not months. Llms do it in an afternoon.

Just reading that plan would take weeks or months

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

#264

Haha this is surprisingly and exactly how I use claude as well. Quite fascinating that we independently discovered the same workflow. I maintain two directories: "docs/proposals" (for the research md files) and "docs/plans" (for the planning md files). For complex research files, I typically break them down into multiple planning md files so claude can implement one at a time. A small difference in my workflow is tha…

Same, I formalized a similar workflow for my team (oriented around feature requirement docs), I am thinking about fully productizing it and am looking to for feedback - https://acai.sh Even if the product doesn’t resonate I think I’ve stumbled on some ideas you might find useful^ I do think spec-driven development is where this all goes. Still making up my mind though.

Spec-driven looks very much like what the author describes. He may have some tweaks of his own but they could just as well be coded into the artifacts that something like OpenSpec produces.

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

#265

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…

I’ve also found that a bigger focus on expanding my agents.md as the project rolls on has led to less headaches overall and more consistency (non-surprisingly). It’s the same as asking juniors to reflect on the work they’ve completed and to document important things that can help them in the future. Software Manger is a good way to put this.

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

#266

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…

Oh no, maybe the V-Model was right all the time? And right sizing increments with control stops after them. No wonder these matrix multiplications start to behave like humans, that is what we wanted them to do.

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

#267

Earlier quoted context omitted.

wtf, why would you write 100k lines of plan to produce 30k loc.. JUST WRITE THE CODE!!!

They didn't write 100k plan lines. The llm did (99.9% of it at least or more). Writing 30k by hand would take weeks if not months. Llms do it in an afternoon.

[deleted]

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

#268
post #236

Earlier quoted context omitted.

What is a personal life planner?

Todos, habits, goals, calendar, meals, notes, bookmarks, shopping lists, finances. More or less that with Google cal integration, garmin Integration (Auto updates workout habits, weight goals) family sharing/gamification, daily/weekly reviews, ai summaries and more. All built by just prompting Claude for feature after feature, with me writing 0 lines.

Ah, I imagined actual life planning as in asking AI what to do, I was morbidly curious.

Prompting basic notes apps is not as exciting but I can see how people who care about that also care about it being exactly a certain way, so I think get your excitement.

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

#269

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…

Revolutionary or not it was very nice of the author to make time and effort to share their workflow.

For those starting out using Claude Code it gives a structured way to get things done bypassing the time/energy needed to “hit upon something that several of us have evolved to naturally”.

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

#270

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…

I really like your analogy of LLMs as 'unreliable interns'. The shift from being a 'coder' to a 'software manager' who enforces documentation and grounding is the only way to scale these tools. Without an architecture.md or similar grounding, the context drift eventually makes the AI-generated code a liability rather than an asset. It's about moving the complexity from the syntax to the specification.
Post reply on HN