Live data from Hacker News

How I use Claude Code: Separation of planning and execution

boristane.com

381–390 of 630 posts

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

#381
post #289

Earlier quoted context omitted.

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…

LLMs are really eager to start coding (as interns are eager to start working), so the sentence “don’t implement yet” has to be used very often at the beginning of any project.

Most LLM apps have a 'plan' or 'ask' mode for that.

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

#382

Quoting the article: > One trick I use constantly: for well-contained features where I’ve seen a good implementation in an open source repo, I’ll share that code as a reference alongside the plan request. If I want to add sortable IDs, I paste the ID generation code from a project that does it well and say “this is how they do sortable IDs, write a plan.md explaining how we can adopt a similar approach.” Claude works…

Concepts are not copyrightable.

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

#383
post #285

Earlier quoted context omitted.

Its ai written though, the tells are in pretty much every paragraph.

I don’t think it’s that big a red flag anymore. Most people use ai to rewrite or clean up content, so I’d think we should actually evaluate content for what it is rather than stop at “nah it’s ai written.”

If you want to write something with AI, send me your prompt. I'd rather read what you intend for it to produce rather than what it produces. If I start to believe you regularly send me AI written text, I will stop reading it. Even at work. You'll have to call me to explain what you intended to write.

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

#384
post #285

Earlier quoted context omitted.

Its ai written though, the tells are in pretty much every paragraph.

I don’t think it’s that big a red flag anymore. Most people use ai to rewrite or clean up content, so I’d think we should actually evaluate content for what it is rather than stop at “nah it’s ai written.”

Even though I use LLMs for code, I just can't read LLM written text, I kind of hate the style, it reminds me too much of LinkedIn.

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

#385
post #337

Earlier quoted context omitted.

That's not (or should not be what's happening). They write a short high level plan (let's say 200 words). The plan asks the agent to write a more detailed implementation plan (written by the LLM, let's say 2000-5000 words). They read this plan and adjust as needed, even sending it to the agent for re-dos. Once the implementation plan is done, they ask the agent to write the actual code changes. Then they review that…

[flagged]

> Haven't seen a single useful thing produced by this garbage process you describe

By using it first-hand or by a colleague? And useful to whom, you, or the person writing it? There are plenty of people in this thread who have actually used this "garbage process," myself included, to produce stuff we, and our colleagues, find is useful.

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

#386

Earlier quoted context omitted.

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…

Developers should work by wasting lots of time making the wrong thing? I bet if they did a work and motion study on this approach they'd find the classic: "Thinks they're more productive, AI has actually made them less productive" But lots of lovely dopamine from this false progress that gets thrown away!

Developers should work by wasting lots of time making the wrong thing?

Yes. In fact, that's not emphatic enough: HELL YES!

More specifically, developers should experiment. They should test their hypothesis. They should try out ideas by designing a solution and creating a proof of concept, then throw that away and build a proper version based on what they learned.

If your approach to building something is to implement the first idea you have and move on then you are going to waste so much more time later refactoring things to fix architecture that paints you into corners, reimplementing things that didn't work for future use cases, fixing edge cases than you hadn't considered, and just paying off a mountain of tech debt.

I'd actually go so far as to say that if you aren't experimenting and throwing away solutions that don't quite work then you're only amassing tech debt and you're not really building anything that will last. If it does it's through luck rather than skill.

Also, this has nothing to do with AI. Developers should be working this way even if they handcraft their artisanal code carefully in vi.

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

#387

Earlier quoted context omitted.

Trust me I'm very impressed at the progress AI has made, and maybe we'll get to the point where everything is 100% correct all the time and better than any human could write. I'm skeptical we can get there with the LLM approach though. The problem is LLMs are great at simple implementation, even large amounts of simple implementation, but I've never seen it develop something more than trivial correctly. The larger pr…

This is exactly what the article is about. The tradeoff is that you have to throughly review the plans and iterate on them, which is tiring. But the LLM will write good code faster than you, if you tell it what good code is.

My experience has so far been similar to the root commenter - at the stage where you need to have a long cycle with planning it's just slower than doing the writing + theory building on my own.

It's an okay mental energy saver for simpler things, but for me the self review in an actual production code context is much more draining than writing is.

I guess we're seeing the split of people for whom reviewing is easy and writing is difficult and vice versa.

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

#389

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 assumptions against actual reality, not just be telling it to review the sources "in detail". It gains much more from real output from the code and clears up wrong assumptions. Do some smaller jobs, write up md files, then plan the big thing, then execute.

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

#390

Earlier quoted context omitted.

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…

Developers should work by wasting lots of time making the wrong thing? I bet if they did a work and motion study on this approach they'd find the classic: "Thinks they're more productive, AI has actually made them less productive" But lots of lovely dopamine from this false progress that gets thrown away!

> Developers should work by wasting lots of time making the wrong thing?

Yes? I can't even count how many times I worked on something my company deemed was valuable only for it to be deprecated or thrown away soon after. Or, how many times I solved a problem but apparently misunderstood the specs slightly and had to redo it. Or how many times we've had to refactor our code because scope increased. In fact, the very existence of the concepts of refactoring and tech debt proves that devs often spend a lot of time making the "wrong" thing.

Is it a waste? No, it solved the problem as understood at the time. And we learned stuff along the way.

Post reply on HN