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

91–100 of 630 posts

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

#91

Post by saxelsen »

red_hare wrote: post #74

I use Claude Code for lecture prep. I craft a detailed and ordered set of lecture notes in a Quarto file and then have a dedicated claude code skill for translating those notes into Slidev slides, in the style that I like. Once that's done, much like the author, I go through the slides and make commented annotations like "this should be broken into two slides" or "this should be a side-by-side" or "use your generate…

Can I ask how you annotate the feedback for it? Just with inline comments like `# This should be changed to X`?

The author mentions annotations but doesn't go into detail about how to feed the annotations to Claude.

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

#92

Post by joshmn »

chickensong wrote: post #55
jcdavis wrote: post #25

Earlier quoted context omitted.

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…

For Claude at least, the more recent guidance from Anthropic is to not yell at it. Just clear, calm, and concise instructions.

Sometimes I daydream about people screaming at their LLM as if it was a TV they were playing video games on.

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

#93

Post by CGamesPlay »

ramoz wrote: post #83
RHSeeger wrote: post #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 mor…

The author seems to think theyve invented a special workflow... We all tend to regress to average (same thoughts/workflows)... Have had many users already doing the exact same workflow with: https://github.com/backnotprop/plannotator

4 times in one thread, please stop spamming this link.

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

#95

Post by haolez »

Betelbuddy wrote: post #72
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…

Its very logical and pretty obvious when you do code generation. If you ask the same model, to generate code by starting with: - You are a Python Developer... or - You are a Professional Python Developer... or - You are one of the World most renowned Python Experts, with several books written on the subject, and 15 years of experience in creating highly reliable production quality code... You will notice a clear impr…

That's different. You are pulling the model, semantically, closer to the problem domain you want it to attack.

That's very different from "think deeper". I'm just curious about this case in specific :)

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

#96

Post by skydhash »

jamesmcq wrote: 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.

> planning and checking and prompting and orchestrating is far more work than just writing the code yourself.

This! Once I'm familiar with the codebase (which I strive to do very quickly), for most tickets, I usually have a plan by the time I've read the description. I can have a couple of implementation questions, but I knew where the info is located in the codebase. For things, I only have a vague idea, the whiteboard is where I go.

The nice thing with such a mental plan, you can start with a rougher version (like a drawing sketch). Like if I'm starting a new UI screen, I can put a placeholder text like "Hello, world", then work on navigation. Once that done, I can start to pull data, then I add mapping functions to have a view model,...

Each step is a verifiable milestone. Describing them is more mentally taxing than just writing the code (which is a flow state for me). Why? Because English is not fit to describe how computer works (try describe a finite state machine like navigation flow in natural languages). My mental mental model is already aligned to code, writing the solution in natural language is asking me to be ambiguous and unclear on purpose.

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

#97

Post by reg_dunlop »

fourthark wrote: post #48
jamesmcq wrote: post #36

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.

Exactly; the original commenter seems determined to write-off AI as "just not as good as me".

The original article is, to me, seemingly not that novel. Not because it's a trite example, but because I've begun to experience massive gains from following the same basic premise as the article. And I can't believe there's others who aren't using like this.

I iterate the plan until it's seemingly deterministic, then I strip the plan of implementation, and re-write it following a TDD approach. Then I read all specs, and generate all the code to red->green the tests.

If this commenter is too good for that, then it's that attitude that'll keep him stuck. I already feel like my projects backlog is achievable, this year.

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

#99

Post by [deleted] »

nostrademons wrote: post #85
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…

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…

[deleted]

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

#100

Post by reg_dunlop »

jamesmcq wrote: post #43
nojito wrote: post #39

Earlier quoted context omitted.

>I've never seen it develop something more than trivial correctly. This is 100% incorrect, but the real issue is that the people who are using these llms for non-trivial work tend to be extremely secretive about it. For example, I view my use of LLMs to be a competitive advantage and I will hold on to this for as long as possible.

The key part of my comment is "correctly". Does it write maintainable code? Does it write extensible code? Does it write secure code? Does it write performant code? My experience has been it failing most of these. The code might "work", but it's not good for anything more than trivial, well defined functions (that probably appeared in it's training data written by humans). LLMs have a fundamental lack of understandin…

To answer all of your questions:

yes, if I steer it properly.

It's very good at spotting design patterns, and implementing them. It doesn't always know where or how to implement them, but that's my job.

The specs and syntactic sugar are just nice quality of life benefits.

Post reply on HN