The planning/execution split is the first “agent workflow” idea that’s actually robust for me: planning wants breadth and tradeoffs, execution wants tight constraints and reproducibility.
How I use Claude Code: Separation of planning and execution
621–630 of 630 posts
Re: How I use Claude Code: Separation of planning and execution
#622> 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…
This is a very useful take, thank you. Really helped me to adjust my mental model without "antropomorphising" the machinery. Upvoted.
If I may, I would re-phrase/expand the last sentence of yours in a way that makes it even more useful for me, personally. Maybe it could help other people too. I think it is fair to say that in presence of hints like "Pretend you are X" or "Take a deeper look" the inference mechanism (driven by it's training weights, and now influenced by those hints via "attention math") is not "satisfied" until it pulls more relevant tokens into "working context" ("more" and "relevant" being modulated by the particular hint).
Re: How I use Claude Code: Separation of planning and execution
#623Earlier quoted context omitted.
How is this evidence of AI use? > That’s it. No magic prompts, no elaborate system instructions, no clever hacks. Just a disciplined pipeline that separates thinking from typing. That is a perfectly normal sentence, indistinguishable from one I might write myself. I am not an AI.
This is a big giveaway because ai tends to overuse this same structure to "conclude"
As do humans, who produced all of the work on which AI was trained.
If an AI favours a particular sentence structure or turn of phrase, it's probably because humans favour it.
Re: How I use Claude Code: Separation of planning and execution
#624Has 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…
This is the exact problem we built Glue to solve. Maintaining markdown files per subsystem works but breaks down as the codebase evolves — the docs drift from reality within weeks. Glue keeps a live, queryable map of the codebase that updates as code changes, so you're not repeating the assessment or trusting stale docs. Happy to share more if useful — getglueapp.com
Re: How I use Claude Code: Separation of planning and execution
#625I 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…
This looks very similar to what I'm doing. Few questions: - How do you adress spec drift? A new feature can easily affect 2 or 3 specs. Do you update them manually? Is a new feature part of a new spec or you update the spec and then plan based on spec changes? - How do you address plan drift? A plan may change as implementer surfaces some issues with the spec for example.
- Whenever I have a change to suggest, I ask Gemini to review my docs/specs folder. I then describe the change I'm thinking of and ask it to modify the specs as it sees fit. I review those changes, ask questions or make suggestions/corrections, rinse/repeat until I'm satisfied. This tends to take about 5-6 iterations, esp. if the agent is adding or suggesting things I hadn't considered and want to dig in deeper on.
- I don't update plans in the past - any work that superseeds work from an earlier plan is simply a new plan. If during creation of a new plan I review the plan and decide I want to something else that requires a spec update, I trash the plan, do the spec update, and rerun plan generation. Past plans of course can point to divergent specs but that's not something I care about much, as plans are a self-contained enough story of the work that was done.
Re: How I use Claude Code: Separation of planning and execution
#626I 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…
This is pretty much my approach. I started with some spec files for a project I'm working on right now, based on some academic papers I've written. I ended up going back and forth with Claude, building plans, pushing info back into the specs, expanding that out and I ended up with multiple spec/architecture/module documents. I got to the point where I ended up building my own system (using claude) to capture and gene…
IME, Claude is more powerful, but Codex follows instructions better. So the more precise the context, the better results you'll get with Codex.
Claude OTOH works better with ambiguity, but it also tends to stray a bit off spec in subtle ways. I always had to take more corrective action w/ the PRs it produced.
That said, I haven't used CC in 3 months and the latest models may be better.
Re: How I use Claude Code: Separation of planning and execution
#627I've been running Claude Code as my primary dev environment for ~6 weeks now, and the planning/execution split is real but undersells the bigger insight: file-based memory is the operating system layer that makes it work.
Claude Code is stateless between sessions. Every /compact or context window overflow wipes the slate. The fix is a CLAUDE.md file that acts as a boot loader, plus a memory/ directory tree organized by topic. The agent reads its own instructions on startup, writes lessons when it makes mistakes, and loads topic files on demand.
The result is an agent that gets better over time despite having no persistent state. I've got ~200 condensed lessons across 10 topic files, and the error rate on repeated tasks has dropped noticeably.
The separation of planning and execution is step 1. The separation of ephemeral context and durable memory is step 2, and that's where the compounding returns live.
Re: How I use Claude Code: Separation of planning and execution
#628Earlier quoted context omitted.
>> Same reason that "Pretend you are an MIT professor" or "You are a leading Python expert" or similar works in prompts. This pretend-you-are-a-[persona] is cargo cult prompting at this point. The persona framing is just decoration. A brief purpose statement describing what the skill [skill.md] does is more honest and just as effective.
It’s not cargo culting, it does make a difference and there are papers on arxiv discussing it. The trouble is that it’s hard to tell whether it’ll help or hurt - telling it to act as an expert in one field may improve your result, or may make it lose some of the other perspectives it has which might be more important for solving the problem.
Papers I read on arxiv mostly say that persona prompting changes tone of voice and attitude, but not the quality of the answer, at least statistically.
For example: https://arxiv.org/abs/2512.05858
Re: How I use Claude Code: Separation of planning and execution
#6291000% accurate. Planning is the difference. I just wrote a white paper that supports this concept at a more macro level. It shows the direct link between failure to plan with adequate business requirements is the exact reason something like 90% of Enterprise AI initiatives failed. Have a look and let me know your thoughts (no asking for your email or any of that) encephalon.net/whitepaper
Re: How I use Claude Code: Separation of planning and execution
#630Earlier quoted context omitted.
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.
Slidev is markdown, so i do it in html comments. Usually something like: or And then, when I finish annotating I just say: "Address all the TODOCLAUDEs"
Thanks for sharing this method - such an elegant way to add annotations to generated specs!