Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I use Claude Code: Separation of planning and execution

boristane.com

Post reply on HN
Print view View original

151–160 of 630 posts

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

#151

Post by wokwokwok »

This is the way.

The practice is:

- simple

- effective

- retains control and quality

Certainly the “unsupervised agent” workflows are getting a lot of attention right now, but they require a specific set of circumstances to be effective:

- clear validation loop (eg. Compile the kernel, here is gcc that does so correctly)

- ai enabled tooling (mcp / cli tool that will lint, test and provide feedback immediately)

- oversight to prevent sgents going off the rails (open area of research)

- an unlimited token budget

That means that most people can't use unsupervised agents.

Not that they dont work; Most people have simply not got an environment and task that is appropriate.

By comparison, anyone with cursor or claude can immediately start using this approach, or their own variant on it.

It does not require fancy tooling.

It does not require an arcane agent framework.

It works generally well across models.

This is one of those few genunie pieces of good practical advice for people getting into AI coding.

Simple. Obviously works once you start using it. No external dependencies. BYO tools to help with it, no “buy my AI startup xxx to help”. No “star my github so I can a job at $AI corp too”.

Great stuff.

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

#152

Post by Affric »

haolez wrote: 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…

My guess would be that there’s a greater absolute magnitude of the vectors to get to the same point in the knowledge model.

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

#153

Post by victorbjorklund »

xscott wrote: post #148
nostrademons wrote: post #85

Earlier quoted context omitted.

It's the attention mechanism at work, along with a fair bit of Internet one-up-manship. The LLM has ingested all of the text on the Internet, as well as Github code repositories, pull requests, StackOverflow posts, code reviews, mailing lists, etc. In a number of those content sources, there will be people saying "Actually, if you go into the details of..." or "If you look at the intricacies of the problem" or "If yo…

Of course I can't be certain, but I think the "mixture of experts" design plays into it too. Metaphorically, there's a mid-level manager who looks at your prompt and tries to decide which experts it should be sent to. If he thinks you won't notice, he saves money by sending it to the undergraduate intern. Just a theory.

Notice that MOE isn’t different experts for different types of problems. It’s per token and not really connect to problem type.

So if you send a python code then the first one in function can be one expert, second another expert and so on.

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

#154

Post by turingsroot »

I've been teaching AI coding tool workshops for the past year and this planning-first approach is by far the most reliable pattern I've seen across skill levels.

The key insight that most people miss: this isn't a new workflow invented for AI - it's how good senior engineers already work. You read the code deeply, write a design doc, get buy-in, then implement. The AI just makes the implementation phase dramatically faster.

What I've found interesting is that the people who struggle most with AI coding tools are often junior devs who never developed the habit of planning before coding. They jump straight to "build me X" and get frustrated when the output is a mess. Meanwhile, engineers with 10+ years of experience who are used to writing design docs and reviewing code pick it up almost instantly - because the hard part was always the planning, not the typing.

One addition I'd make to this workflow: version your research.md and plan.md files in git alongside your code. They become incredibly valuable documentation for future maintainers (including future-you) trying to understand why certain architectural decisions were made.

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

#155

Post by DevEx7 »

I’m a big fan of having the model create a GitHub issue directly (using the GH CLI) with the exact plan it generates, instead of creating a markdown file that will eventually get deleted. It gives me a permanent record and makes it easy to reference and close the issue once the PR is ready.

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

#156

Post by gitaarik »

dack wrote: post #120
bluegatty wrote: post #118

I don't see how this is 'radically different' given that Claude Code literally has a planning mode. This is my workflow as well, with the big caveat that 80% of 'work' doesn't require substantive planning, we're making relatively straight forward changes. Edit: there is nothing fundamentally different about 'annotating offline' in an MD vs in the CLI and iterating until the plan is clear. It's a UI choice. Spec Drive…

last i checked, you can't annotate inline with planning mode. you have to type a lot to explain precisely what needs to change, and then it re-presents you with a plan (which may or may not have changed something else). i like the idea of having an actual document because you could actually compare the before and after versions if you wanted to confirm things changed as intended when you gave feedback

A plan is just a file you can edit and then tell CC to check your annotations

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

#158

Post by imron »

raw_anon_1111 wrote: post #107
imron wrote: post #88

Earlier quoted context omitted.

> and use my $800/month company Claude allowance only for the tricky stuff that Codex can’t figure out. It doesn’t seem controversial that the model that can solve more complex problems (that you admit the cheaper model can’t solve) costs more. For the things I use it for, I’ve not found any other model to be worth it.

You’re assuming rational behavior from a company that doesn’t care about losing billions of dollar. Have you tried Codex with OpenAi’s latest models?

Not in the last 2 months.

Current clause subscription is a sunk cost for the next month. Maybe I’ll try codex if Claude doesn’t lead anywhere.

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

#159

Post by [deleted] »

haolez wrote: 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…

[deleted]

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

#160

Post by epec254 »

wokwokwok wrote: post #151

This is the way. The practice is: - simple - effective - retains control and quality Certainly the “unsupervised agent” workflows are getting a lot of attention right now, but they require a specific set of circumstances to be effective: - clear validation loop (eg. Compile the kernel, here is gcc that does so correctly) - ai enabled tooling (mcp / cli tool that will lint, test and provide feedback immediately) - ove…

Huge +1. This loop consistently delivers great results for my vibe coding.

The “easy” path of “short prompt declaring what I want” works OK for simple tasks but consistently breaks down for medium to high complexity tasks.

Post reply on HN