[deleted]
How I use Claude Code: Separation of planning and execution
281–290 of 630 posts
Re: How I use Claude Code: Separation of planning and execution
#282Has anyone found a efficient way to avoid repeating the initial codebase assessment when working with large projects?
There are several projects on GitHub that attempt to tackle context and memory limitations, but I haven’t found one that consistently works well in practice.
My current workaround is to maintain a set of Markdown files, each covering a specific subsystem or area of the application. Depending on the task, I provide only the relevant documents to Claude Code to limit the context scope. It works reasonably well, but it still feels like a manual and fragile solution. I’m interested in more robust strategies for persistent project context or structured codebase understanding.
Re: How I use Claude Code: Separation of planning and execution
#283This 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.
I'd find it deeply funny if the optimal vibe coding workflow continues to evolve to include more and more human oversight, and less and less agent autonomy, to the point where eventually someone makes a final breakthrough that they can save time by bypassing the LLM entirely and writing the code themselves. (Finally coming full circle.)
You mean there will be an invention to edit files directly instead of giving the specific code and location you want it to be written into the prompt?
Re: How I use Claude Code: Separation of planning and execution
#284It is really fun to watch how a baby makes its first steps and also how experienced professionals rediscover what standards were telling us for 80+ years.
Re: How I use Claude Code: Separation of planning and execution
#285The 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…
Revolutionary or not it was very nice of the author to make time and effort to share their workflow. For those starting out using Claude Code it gives a structured way to get things done bypassing the time/energy needed to “hit upon something that several of us have evolved to naturally”.
Its ai written though, the tells are in pretty much every paragraph.
Re: How I use Claude Code: Separation of planning and execution
#286Earlier quoted context omitted.
They didn't write 100k plan lines. The llm did (99.9% of it at least or more). Writing 30k by hand would take weeks if not months. Llms do it in an afternoon.
And my weeks or months of work beats an LLMs 10/10 times. There are no shortcuts in life.
Might be true for you. But there are plenty of top tier engineers who love LLMs. So it works for some. Not for others.
And of course there are shortcuts in life. Any form of progress whether its cars, medicine, computers or the internet are all shortcuts in life. It makes life easier for a lot of people.
Re: How I use Claude Code: Separation of planning and execution
#287Has anyone found a efficient way to avoid repeating the initial codebase assessment when working with large projects? There are several projects on GitHub that attempt to tackle context and memory limitations, but I haven’t found one that consistently works well in practice. My current workaround is to maintain a set of Markdown files, each covering a specific subsystem or area of the application. Depending on the ta…
Whenever I build a new feature with it I end up with several plan files leftover. I ask CC to combine them all, update with what we actually ended up building and name it something sensible, then whenever I want to work on that area again it's a useful reference (including the architecture, decisions and tradeoffs, relevant files etc).
Re: How I use Claude Code: Separation of planning and execution
#288Earlier quoted context omitted.
I don’t think this is a result of the base training data („the internet“). It’s a post training behavior, created during reinforcement learning. Codex has a totally different behavior in that regard. Codex reads per default a lot of potentially relevant files before it goes and writes files. Maybe you remember that, without reinforcement learning, the models of 2019 just completed the sentences you gave them. There w…
Modern LLM are certainly fine tuned on data that includes examples of tool use, mostly the tools built into their respective harnesses, but also external/mock tools so they dont overfit on only using the toolset they expect to see in their harnesses.
IDK the current state, but I remember that, last year, the open source coding harnesses needed to provide exactly the tools that the LLM expected, or the error rate went through the roof. Some, like grok and gemini, only recently managed to make tool calls somewhat reliable.
Re: How I use Claude Code: Separation of planning and execution
#289> the workflow I’ve settled into is radically different from what most people do with AI coding tools This looks exactly like what anthropic recommends as the best practice for using Claude Code. Textbook. It also exposes a major downside of this approach: if you don't plan perfectly, you'll have to start over from scratch if anything goes wrong. I've found a much better approach in doing a design -> plan -> execute…
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.
Re: How I use Claude Code: Separation of planning and execution
#290I don't really get what is different about this from how almost everyone else uses Claude Code? This is an incredibly common, if not the most common way of using it (and many other tools).