Live data from Hacker News

How I use Claude Code: Separation of planning and execution

boristane.com

61–70 of 630 posts

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

#61

Earlier quoted context omitted.

I really don't understand why there are so many comments like this. Yesterday I had Claude write an audit logging feature to track all changes made to entities in my app. Yeah you get this for free with many frameworks, but my company's custom setup doesn't have it. It took maybe 5-10 minutes of wall-time to come up with a good plan, and then ~20-30 min for Claude implement, test, etc. That would've taken me at least…

I mean, all I can really say is... if writing some logging takes you one or two days, are you sure you _really_ know how to code?

Ever worked on a distributed system with hundreds of millions of customers and seemingly endless business requirements?

Some things are complex.

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

#62

Earlier quoted context omitted.

You're right, you're better than me! You could've been curious and ask why it would take 1-2 days, and I would've happily told you.

I'll bite, because it does seem like something that should be quick in a well-architected codebase. What was the situation? Was there something in this codebase that was especially suited to AI-development? Large amounts of duplication perhaps?

It's not particularly interesting.

I wanted to add audit logging for all endpoints we call, all places we call the DB, etc. across areas I haven't touched before. It would have taken me a while to track down all of the touchpoints.

Granted, I am not 100% certain that Claude didn't miss anything. I feel fairly confident that it is correct given that I had it research upfront, had multiple agents review, and it made the correct changes in the areas that I knew.

Also I'm realizing I didn't mention it included an API + UI for viewing events w/ pretty deltas

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

#63
I have tried using this and other workflows for a long time and had never been able to get them to work (see chat history for details).

This has changed in the last week, for 3 reasons:

1. Claude opus. It’s the first model where I haven’t had to spend more time correcting things than it would’ve taken me to just do it myself. The problem is that opus chews through tokens, which led to..

2. I upgraded my Claude plan. Previously on the regular plan I’d get about 20 mins of time before running out of tokens for the session and then needing to wait a few hours to use again. It was fine for little scripts or toy apps but not feasible for the regular dev work I do. So I upgraded to 5x. This now got me 1-2 hours per session before tokens expired. Which was better but still a frustration. Wincing at the price, I upgraded again to the 20x plan and this was the next game changer. I had plenty of spare tokens per session and at that price it felt like they were being wasted - so I ramped up my usage. Following a similar process as OP but with a plans directory with subdirectories for backlog, active and complete plans, and skills with strict rules for planning, implementing and completing plans, I now have 5-6 projects on the go. While I’m planning a feature on one the others are implementing. The strict plans and controls keep them on track and I have follow up skills for auditing quality and performance. I still haven’t hit token limits for a session but I’ve almost hit my token limit for the week so I feel like I’m getting my money’s worth. In that sense spending more has forced me to figure out how to use more.

3. The final piece of the puzzle is using opencode over claude code. I’m not sure why but I just don’t gel with Claude code. Maybe it’s all the sautéing and flibertygibbering, maybe it’s all the permission asking, maybe it’s that it doesn’t show what it’s doing as much as opencode. Whatever it is it just doesn’t work well for me. Opencode on the other hand is great. It’s shows what it’s doing and how it’s thinking which makes it easy for me to spot when it’s going off track and correct early.

Having a detailed plan, and correcting and iterating on the plan is essential. Making clause follow the plan is also essential - but there’s a line. Too fine grained and it’s not as creative at solving problems. Too loose/high level and it makes bad choices and goes in the wrong direction.

Is it actually making me more productive? I think it is but I’m only a week in. I’ve decided to give myself a month to see how it all works out.

I don’t intend to keep paying for the 20x plan unless I can see a path to using it to earn me at least as much back.

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

#64
post #9

This all looks fine for someone who can't code, but for anyone with even a moderate amount of experience as a developer all this planning and checking and prompting and orchestrating is far more work than just writing the code yourself. There's no winner for "least amount of code written regardless of productivity outcomes.", except for maybe Anthropic's bank account.

Researching and planning a project is a generally usefully thing. This is something I've been doing for years, and have always had great results compared to just jumping in and coding. It makes perfect sense that this transfers to LLM use.

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

#65
post #63

I have tried using this and other workflows for a long time and had never been able to get them to work (see chat history for details). This has changed in the last week, for 3 reasons: 1. Claude opus. It’s the first model where I haven’t had to spend more time correcting things than it would’ve taken me to just do it myself. The problem is that opus chews through tokens, which led to.. 2. I upgraded my Claude plan.…

Just don’t use Claude Code. I can use the Codex CLI with just my $20 subscription and never come close to any usage limits

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

#66
> Most developers type a prompt, sometimes use plan mode, fix the errors, repeat.

> ...

> never let Claude write code until you’ve reviewed and approved a written plan

I certainly always work towards an approved plan before I let it lost on changing the code. I just assumed most people did, honestly. Admittedly, sometimes there's "phases" to the implementation (because some parts can be figured out later and it's more important to get the key parts up and running first), but each phase gets a full, reviewed plan before I tell it to go.

In fact, I just finished writing a command and instruction to tell claude that, when it presents a plan for implementation, offer me another option; to write out the current (important parts of the) context and the full plan to individual (ticket specific) md files. That way, if something goes wrong with the implementation I can tell it to read those files and "start from where they left off" in the planning.

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

#67
post #25
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…

Its a wild time to be in software development. Nobody(1) actually knows what causes LLMs to do certain things, we just pray the prompt moves the probabilities the right way enough such that it mostly does what we want. This used to be a field that prided itself on deterministic behavior and reproducibility. Now? We have AGENTS.md files that look like a parent talking to a child with all the bold all-caps, double emph…

[deleted]

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

#68
post #45

I go a bit further than this and have had great success with 3 doc types and 2 skills: - Specs: these are generally static, but updatable as the project evolves. And they're broken out to an index file that gives a project overview, a high-level arch file, and files for all the main modules. Roughly ~1k lines of spec for 10k lines of code, and try to limit any particular spec file to 300 lines. I'm intimately familia…

Looks good. Question - is it always better to use a monorepo in this new AI world? Vs breaking your app into separate repos? At my company we have like 6 repos all separate nextjs apps for the same user base. Trying to consolidate to one as it should make life easier overall.

AI is happy to work with any directory you tell it to. Agent files can be applied anywhere.

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

#69

Earlier quoted context omitted.

Please don't be knee-jerk dismissive of posts. Absolute nothing about this article looks "LLM-generated style" to me.

>> Why This Works So Well

an obvious tell from another tech influencer and Hn will eat it up

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

#70
post #63

I have tried using this and other workflows for a long time and had never been able to get them to work (see chat history for details). This has changed in the last week, for 3 reasons: 1. Claude opus. It’s the first model where I haven’t had to spend more time correcting things than it would’ve taken me to just do it myself. The problem is that opus chews through tokens, which led to.. 2. I upgraded my Claude plan.…

Just don’t use Claude Code. I can use the Codex CLI with just my $20 subscription and never come close to any usage limits

What if it's just slower so that your daily work fits within the paid tier they want?
Post reply on HN