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

431–440 of 630 posts

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

#431

Post by abustamam »

Bishonen88 wrote: post #347
dakolli wrote: post #277

Earlier quoted context omitted.

And my weeks or months of work beats an LLMs 10/10 times. There are no shortcuts in life.

I have no doubts that it does for many people. But the time/cost tradeoff is still unquestionable. I know I could create what LLMs do for me in the frontend/backend in most cases as good or better - I know that, because I've done it at work for years. But to create a somewhat complex app with lots of pages/features/apis etc. would take me months if not a year++ since I'd be working on it only on the weekends for a fe…

> What previously would've taken a multi-man team weeks of planning and executing, stand ups, jour fixes, architecture diagrams, etc. can now be done within a single week by myself.

This has been my experience. We use Miro at work for diagramming. Lots of visual people on the team, myself included. Using Miro's MCP I draft a solution to a problem and have Miro diagram it. Once we talk it through as a team, I have Claude or codex implement it from the diagram.

It works surprisingly well.

> They are amazed however that what has taken months previously, can be done in hours nowadays.

Of course they're amazed. They don't have to pay you for time saved ;)

> reap benefits of LLMs for as long as they don't replace me > What previously would've taken a multi-man team

I think this is the part that people are worried about. Every engineer who uses LLMs says this. By definition it means that people are being replaced.

I think I justify it in that no one on my team has been replaced. But management has explicitly said "we don't want to hire more because we can already 20x ourselves with our current team +LLM." But I do acknowledge that many people ARE being replaced; not necessarily by LLMs, but certainly by other engineers using LLMs.

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

#432

Post by hun3 »

sparin9 wrote: post #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.

Except that merely surfacing them changes their behavior, like how you add that one printf() call and now your heisenbug is suddenly nonexistent

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

#433

Post by maccard »

sparin9 wrote: post #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.

> LLMs don’t usually fail at syntax?

Really? My experience has been that it’s incredibly easy to get them stuck in a loop on a hallucinated API and burn through credits before I’ve even noticed what it’s done. I have a small rust project that stores stuff on disk that I wanted to add an s3 backend too - Claude code burned through my $20 in a loop in about 30 minutes without any awareness of what it was doing on a very simple syntax issue.

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

#434

Post by hghbbjh »

vntok wrote: post #401
BoredPositron wrote: post #360

Earlier quoted context omitted.

Not if anthropic goes further in obfuscating the output of claude code.

Why would you test implementation details? Test what's delivered, not how it's delivered. The thinking portion, synthetized or not, is merely implementation. The resulting artefact, that's what is worth testing.

> Why would you test implementation details

Because this has never been sufficient. From things like various hard to test cases to things like readability and long term maintenance. Reading and understanding the code is more efficient and necessary for any code worth keeping around.

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

#435

Post by skydhash »

intrasight wrote: post #425
jerryharri wrote: post #413

Earlier quoted context omitted.

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

We're learning how to be an engineer all over again. The authors process is super-close what we were taught in engineering 101 40 years ago.

I always feels like I'm in a fever dream when I hear about AI workflows. A lot of stuff is what I've read from software engineering books and articles.

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

#436

Post by ramoz »

zahlman wrote: post #198

> After Claude writes the plan, I open it in my editor and add inline notes directly into the document. These notes correct assumptions, reject approaches, add constraints, or provide domain knowledge that Claude doesn’t have. This is the part that seems most novel compared to what I've heard suggested before. And I have to admit I'm a bit skeptical. Would it not be better to modify what Claude has written directly,…

The whole process feels Socratic which is why I and a lot of other folks use plan annotation tools already. In my workflow I had a great desire to tell the agent what I didn’t like about the plan vs just fix it myself - because I wanted the agent to fix its own plan.

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

#437

Post by getnormality »

This looks like an important post. What makes it special is that it operationalizes Polya's classic problem-solving recipe for the age of AI-assisted coding.

1. Understand the problem (research.md)

2. Make a plan (plan.md)

3. Execute the plan

4. Look back

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

#438

Post by layer8 »

DonHopkins wrote: post #422
fasbiner wrote: post #421

Earlier quoted context omitted.

Yeah but it's not. This a complete contrivance and you're just making shit up. The prompt is much shorter than the output and you are concealing that fact. Why? Github repo or it didn't happen. Let's go.

[flagged]

It’s certainly more interesting than whatever the AI would turn it into.

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

#439

Post by christophilus »

getnormality wrote: post #437

This looks like an important post. What makes it special is that it operationalizes Polya's classic problem-solving recipe for the age of AI-assisted coding. 1. Understand the problem (research.md) 2. Make a plan (plan.md) 3. Execute the plan 4. Look back

Yeah, OODA loop for programmers, basically. It’s a good approach.

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

#440

Post by skydhash »

onion2k wrote: post #386
mattmanser wrote: post #280

Earlier quoted context omitted.

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…

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

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

You do realize there are prior research and well tested solutions for a lot of things. Instead of wasting time making the wrong thing, it is faster to do some research if the problem has already been solved. Experimentation is fine only after checking that the problem space is truly novel or there's not enough information around.

It is faster to iterate in your mental space and in front of a whiteboard than in code.

Post reply on HN