15 ms·

How I use Claude Code: Separation of planning and execution

• aufklarer 8mo ago
  [dead]
• hilliardfarmer 8mo ago
  [flagged]
  • crazygringo 8mo ago
    Please don't be knee-jerk dismissive of posts. Absolute nothing about this article looks "LLM-generated style" to me.
    • bonsai_spool 8mo ago
      I think it was edited with an LLM - the voice flits from human to bot but various tells are present. The heterogeneity of sentence structure is the clearest signal. Here’s an older article from the author from 2024: https://boristane.com/blog/learnings-from-starting-building-and-exiting-a-devtools-startup/ https://boristane.com/blog/learnings-from-starting-building-...
      • zahlman 8mo ago
        I also suspect that people who spend too much time reading LLM-produced content and using LLMs end up suffering a kind of brain-rot from the "LLM house style", and start naturally using those idioms in their own writing even if they do it all by hand.
    • gregoryl 8mo ago
      >> Why This Works So Well
      • thousand_nights 8mo ago
        an obvious tell from another tech influencer and Hn will eat it up
      • hilliardfarmer 8mo ago
        That was the giveaway for me too!
• zitrusfrucht 8mo ago
  I do something very similar, also with Claude and Codex, because the workflow is controlled by me, not by the tool. But instead of plan.md I use a ticket system basically like ticket_<number>_<slug>.md where I let the agent create the ticket from a chat, correct and annotate it afterwards and send it back, sometimes to a new agent instance. This workflow helps me keeping track of what has been done over time in the projects I work on. Also this approach does not need any „real“ ticket system tooling/mcp/skill/whatever since it works purely on text files.
  • gbnwl 8mo ago
    +1 to creating tickets by simply asking the agent to. It's worked great and larger tasks can be broken down into smaller subtasks that could reasonably be completed in a single context window, so you rarely every have to deal with compaction. Especially in the last few months since Claude's gotten good at dispatching agents to handle tasks if you ask it to, I can plan large changes that span multilpe tickets and tell claude to dispatch agents as needed to handle them (which it will do in parallel if they mostly touch different files), keeping the main chat relatively clean for orchestration and validation work.
  • ramoz 8mo ago
    semantic plan name is important
• srid 8mo ago
  Regarding inline notes, I use a specific format in the `/plan` command, by using th `ME:` prefix. https://github.com/srid/AI/blob/master/commands/plan.md#2-plan-review-cycle https://github.com/srid/AI/blob/master/commands/plan.md#2-pl... It works very similar to Antigravity's plan document comment-refine cycle. https://antigravity.google/docs/implementation-plan https://antigravity.google/docs/implementation-plan
• renewiltord 8mo ago
  The plan document and todo are an artifact of context size limits. I use them too because it allows using /reset and then continuing.
• jamesmcq 8mo ago
  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.
  • dmix 8mo ago
    Most of these AI coding articles seem to be about greenfield development. That said, if you're on a serious team writing professional software there is still tons of value in always telling AI to plan first, unless it's a small quick task. This post just takes it a few steps further and formalizes it. I find Cursor works much more reliably using plan mode, reviewing/revising output in markdown, then pressing build. Which isn't a ton of overhead but often leads to lots of context switching as it definitely adds more time.
  • shepherdjerred 8mo ago
    I really don't understand why there are so many comments like this. Yesterday I had Claude write an audit logging feature to track all changes made to entities in my app. Yeah you get this for free with many frameworks, but my company's custom setup doesn't have it. It took maybe 5-10 minutes of wall-time to come up with a good plan, and then ~20-30 min for Claude implement, test, etc. That would've taken me at least a day, maybe two. I had 4-5 other tasks going on in other tabs while I waited the 20-30 min for Claude to generate the feature. After Claude generated, I needed to manually test that it worked, and it did. I then needed to review the code before making a PR. In all, maybe 30-45 minutes of my actual time to add a small feature. All I can really say is... are you sure you're using it right? Have you _really_ invested time into learning how to use AI tools?
    • tyleo 8mo ago
      Same here. I did bounce off these tools a year ago. They just didn't work for me 60% of the time. I learned a bit in that initial experience though and walked away with some tasks ChatGPT could replace in my workflow. Mainly replacing scripts and reviewing single files or functions. Fast forward to today and I tried the tools again--specifically Claude Code--about a week ago. I'm blown away. I've reproduced some tools that took me weeks at full-time roles in a single day. This is while reviewing every line of code. The output is more or less what I'd be writing as a principal engineer.
• ihsw 8mo ago
  Kiro's spec-based development looks identical. https://kiro.dev/docs/specs/ https://kiro.dev/docs/specs/ It looks verbose but it defines the requirements based on your input, and when you approve it then it defines a design, and (again) when you approve it then it defines an implementation plan (a series of tasks.)
• deleted 8mo ago
  [deleted]
• ramoz 8mo ago
  One thing for me has been the ability to iterate over plans - with a better visual of them as well as ability to annotate feedback about the plan. https://github.com/backnotprop/plannotator https://github.com/backnotprop/plannotator Plannotator does this really effectively and natively through hooks
  • prodtorok 8mo ago
    Wow, I've been needing this! The one issue I’ve had with terminals is reviewing plans, and desiring the ability to provide feedback on specific plan sections in a more organized way. Really nice ui based on the demo.
• haolez 8mo ago
  > 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't capture why asking the model to read the content "more deeply" will have any impact on whatever output the LLM generates.
  • fragmede 8mo ago
    Yeah, it's definitely a strange new world we're in, where I have to "trick" the computer into cooperating. The other day I told Claude "Yes you can", and it went off and did something it just said it couldn't do!
    • itypecode 8mo ago
      Solid dad move. XD
      • wilkystyle 8mo ago
        Is parenting making us better at prompt engineering, or is it the other way around?
        • fragmede 8mo ago
          Better yet, I have Codex, Gemini, and Claude as my kids, running around in my code playground. How do I be a good parent and not play favorites?
          • itypecode 8mo ago
            We all know Gemini is your artsy, Claude is your smartypants, and Codex is your nerd.
    • bpodgursky 8mo ago
• deevus 8mo ago
  This is what I do with the obra/superpowers[0] set of skills. 1. Use brainstorming to come up with the plan using the Socratic method 2. Write a high level design plan to file 3. I review the design plan 4. Write an implementation plan to file. We've already discussed this in detail, so usually it just needs skimming. 5. Use the worktree skill with subagent driven development skill 6. Agent does the work using subagents that for each task: a. Implements the task b. Spec reviews the completed task c. Code reviews the completed task 7. When all tasks complete: create a PR for me to review 8. Go back to the agent with any comments 9. If finished, delete the plan files and merge the PR [0]: https://github.com/obra/superpowers https://github.com/obra/superpowers
  • ramoz 8mo ago
    If you’ve ever desired the ability for annotating the plan more visually, try fitting Plannotator in this workflow. There is a slash command for use when you use custom workflows outside of normal plan mode. https://github.com/backnotprop/plannotator https://github.com/backnotprop/plannotator
    • deevus 8mo ago
      I'll give this a try. Thanks for the suggestion.
  • moribunda 8mo ago
    The crowd around this pot shows how superficial is knowledge about claude code. It gets releases each day and most of this is already built in the vanilla version. Not to mention subagent working in work trees, memory.md, plan on which you can comment directly from the interface, subagents launched in research phase, but also some basic mcp's like LSP/IDE integration, and context7 to not to be stuck in the knowledge cutoff/past. When you go to YouTube and search for stuff like "7 levels of claude code" this post would be maybe 3-4. Oh, one more thing - quality is not consistent, so be ready for 2-3 rounds of "are you happy with the code you wrote" and defining audit skills crafted for your application domain - like for example RODO/Compliance audit etc.
• fnord77 8mo ago
  I have a different approach where I have claude write coding prompts for stages then I give the prompt to another agent. I wonder if I should write it up as a blog post
• alexmorgan26 8mo ago
  [dead]
  • dimgl 8mo ago
    Pretty sure this entire comment is AI generated.
    • rob 8mo ago
      Almost think we're at the point on HN where we need a special [flag bot] link for those that meet a certain threshold and it alerts @dang or something to investigate them in more detail. The amount of bots on here has been increasing at an alarming rate.
    • zahlman 8mo ago
      There has been this really weird flood of new accounts lately that are making these kinds of bot comments with no clear purpose to making them. Maybe it comes from people experimenting with OpenClaw?
• skybrian 8mo ago
  I do something broadly similar. I ask for a design doc that contains an embedded todo list, broken down into phases. Looping on the design doc asking for suggestions seems to help. I'm up to about 40 design docs so far on my current project.
• deleted 8mo ago
  [deleted]
• brandall10 8mo ago
  I 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 familiar with every single line in these. - Plans: these are the output of a planning session with an LLM. They point to the associated specs. These tend to be 100-300 lines and 3 to 5 phases. - Working memory files: I use both a status.md (3-5 items per phase roughly 30 lines overall), which points to a latest plan, and a project_status (100-200 lines), which tracks the current state of the project and is instructed to compact past efforts to keep it lean) - A planner skill I use w/ Gemini Pro to generate new plans. It essentially explains the specs/plans dichotomy, the role of the status files, and to review everything in the pertinent areas of code and give me a handful of high-level next set of features to address based on shortfalls in the specs or things noted in the project_status file. Based on what it presents, I select a feature or improvement to generate. Then it proceeds to generate a plan, updates a clean status.md that points to the plan, and adjusts project_status based on the state of the prior completed plan. - An implementer skill in Codex that goes to town on a plan file. It's fairly simple, it just looks at status.md, which points to the plan, and of course the plan points to the relevant specs so it loads up context pretty efficiently. I've tried the two main spec generation libraries, which were way overblown, and then I gave superpowers a shot... which was fine, but still too much. The above is all homegrown, and I've had much better success because it keeps the context lean and focused. And I'm only on the $20 plans for Codex/Gemini vs. spending $100/month on CC for half year prior and move quicker w/ no stall outs due to token consumption, which was regularly happening w/ CC by the 5th day. Codex rarely dips below 70% available context when it puts up a PR after an execution run. Roughly 4/5 PRs are without issue, which is flipped against what I experienced with CC and only using planning mode.
  • r1290 8mo ago
    Looks good. Question - is it always better to use a monorepo in this new AI world? Vs breaking your app into separate repos? At my company we have like 6 repos all separate nextjs apps for the same user base. Trying to consolidate to one as it should make life easier overall.
• cowlby 8mo ago
  I recently discovered GitHub speckit which separates planning/execution in stages: specify, plan, tasks, implement. Finding it aligns with the OP with the level of “focus” and “attention” this gets out of Claude Code. Speckit is worth trying as it automates what is being described here, and with Opus 4.6 it's been a kind of BC/AD moment for me.
• recroad 8mo ago
  Use OpenSpec and simplify everything.
• recroad 8mo ago
  Try OpenSpec and it'll do all this for you. SpecKit works too. I don't think there's a need to reinvent the wheel on this one, as this is spec-driven development.
  • twoquestions 8mo ago
    This, I've been using SpecKit for a while for my side project and it's been working beautifully. I generally spend more than half my time working on the specs, until implementation is an afterthought, Claude already knows what to write and where. The /speckit.analyze and /speckit.clarify tools are extremely useful for me.
• bodeadly 8mo ago
  Tip: LLMs are very good at following conventions (this is actually what is happening when it writes code). If you create a .md file with a list of entries of the following structure: # <identifier> <description block> <blank space> # <identifier> ... where an <identifier> is a stable and concise sequence of tokens that identifies some "thing" and seed it with 5 entries describing abstract stuff, the LLM will latch on and reference this. I call this a PCL (Project Concept List). I just tell it: > consume tmp/pcl-init.md pcl.md The pcl-init.md describes what PCL is and pcl.md is the actual list. I have pcl.md file for each independent component in the code (logging, http, auth, etc). This works very very well. The LLM seems to "know" what you're talking about. You can ask questions and give instructions like "add a PCL entry about this". It will ask if should add a PCL entry about xyz. If the description block tends to be high information-to-token ratio, it will follow that convention (which is a very good convention BTW). However, there is a caveat. LLMs resist ambiguity about authority. So the "PCL" or whatever you want to call it, needs to be the ONE authoritative place for everything. If you have the same stuff in 3 different files, it won't work nearly as well. Bonus Tip: I find long prompt input with example code fragments and thoughtful descriptions work best at getting an LLM to produce good output. But there will always be holes (resource leaks, vulnerabilities, concurrency flaws, etc). So then I update my original prompt input (keep it in a separate file PROMPT.txt as a scratch pad) to add context about those things maybe asking questions along the way to figure out how to fix the holes. Then I /rewind back to the prompt and re-enter the updated prompt. This feedback loop advances the conversation without expending tokens.
• imron 8mo ago
  I have tried using this and other workflows for a long time and had never been able to get them to work (see chat history for details). This has changed in the last week, for 3 reasons: 1. Claude opus. It’s the first model where I haven’t had to spend more time correcting things than it would’ve taken me to just do it myself. The problem is that opus chews through tokens, which led to.. 2. I upgraded my Claude plan. Previously on the regular plan I’d get about 20 mins of time before running out of tokens for the session and then needing to wait a few hours to use again. It was fine for little scripts or toy apps but not feasible for the regular dev work I do. So I upgraded to 5x. This now got me 1-2 hours per session before tokens expired. Which was better but still a frustration. Wincing at the price, I upgraded again to the 20x plan and this was the next game changer. I had plenty of spare tokens per session and at that price it felt like they were being wasted - so I ramped up my usage. Following a similar process as OP but with a plans directory with subdirectories for backlog, active and complete plans, and skills with strict rules for planning, implementing and completing plans, I now have 5-6 projects on the go. While I’m planning a feature on one the others are implementing. The strict plans and controls keep them on track and I have follow up skills for auditing quality and performance. I still haven’t hit token limits for a session but I’ve almost hit my token limit for the week so I feel like I’m getting my money’s worth. In that sense spending more has forced me to figure out how to use more. 3. The final piece of the puzzle is using opencode over claude code. I’m not sure why but I just don’t gel with Claude code. Maybe it’s all the sautéing and flibertygibbering, maybe it’s all the permission asking, maybe it’s that it doesn’t show what it’s doing as much as opencode. Whatever it is it just doesn’t work well for me. Opencode on the other hand is great. It’s shows what it’s doing and how it’s thinking which makes it easy for me to spot when it’s going off track and correct early. Having a detailed plan, and correcting and iterating on the plan is essential. Making clause follow the plan is also essential - but there’s a line. Too fine grained and it’s not as creative at solving problems. Too loose/high level and it makes bad choices and goes in the wrong direction. Is it actually making me more productive? I think it is but I’m only a week in. I’ve decided to give myself a month to see how it all works out. I don’t intend to keep paying for the 20x plan unless I can see a path to using it to earn me at least as much back.
  • raw_anon_1111 8mo ago
• RHSeeger 8mo ago
  > 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 more important to get the key parts up and running first), but each phase gets a full, reviewed plan before I tell it to go. In fact, I just finished writing a command and instruction to tell claude that, when it presents a plan for implementation, offer me another option; to write out the current (important parts of the) context and the full plan to individual (ticket specific) md files. That way, if something goes wrong with the implementation I can tell it to read those files and "start from where they left off" in the planning.
  • ramoz 8mo ago
    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 https://github.com/backnotprop/plannotator
    • CGamesPlay 8mo ago
      4 times in one thread, please stop spamming this link.
• paperclipmaxi 8mo ago
  [dead]
• bandrami 8mo ago
  How much time are you actually saving at this point?
• red_hare 8mo ago
  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 clipart skill to throw an image here alongside these bullets" and "pull in the code example from ../examples/foo." It works brilliantly. And then I do one final pass of tweaking after that's done. But yeah, annotations are super powerful. Token distance in-context and all that jazz.
  • ramoz 8mo ago
    is your skill open source
    • red_hare 8mo ago
      Not yet... but also I'm not sure it makes a lot of sense to be open source. It's super specific to how I like to build slide decks and to my personal lecture style. But it's not hard to build one. The key for me was describing, in great detail: 1. How I want it to read the source material (e.g., H1 means new section, H2 means at least one slide, a link to an example means I want code in the slide) 2. How to connect material to layouts (e.g., "comparison between two ideas should be a two-cols-title," "walkthrough of code should be two-cols with code on right," "learning objectives should be side-title align:left," "recall should be side-title align:right") Then the workflow is: 1. Give all those details and have it do a first pass. 2. Give tons of feedback. 3. At the end of the session, ask it to "make a skill." 4. Manually edit the skill so that you're happy with the examples.
  • saxelsen 8mo ago
    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.
    • 8mo ago
• jrs235 8mo ago
  Claude appeared to just crash in my session: https://news.ycombinator.com/item?id=47107630 https://news.ycombinator.com/item?id=47107630
• zhubert 8mo ago
  AI only improves and changes. Embrace the scientific method and make sure your “here’s how to” are based in data.
• h14h 8mo ago
  Is this not just Ralph with extra steps and the risk of context rot?
• Ozzie_osman 8mo ago
  There are a few prompt frameworks that essentially codify these types of workflows by adding skills and prompts https://github.com/obra/superpowers https://github.com/obra/superpowers https://github.com/jlevy/tbd https://github.com/jlevy/tbd
• politician 8mo ago
  Wow, I never bother with using phrases like “deeply study this codebase deeply.” I consistently get pretty fantastic results.
• dworks 8mo ago
  my rlm-workflow skill has this encoded as a repeatable workflow. give it a try: https://skills.sh/doubleuuser/rlm-workflow/rlm-workflow https://skills.sh/doubleuuser/rlm-workflow/rlm-workflow
• beratbozkurt0 8mo ago
  That's great, actually, doesn't the logic apply to other services as well?
• bluegatty 8mo ago
  I don't see how this is 'radically different' given that Claude Code literally has a planning mode. This is my workflow as well, with the big caveat that 80% of 'work' doesn't require substantive planning, we're making relatively straight forward changes. Edit: there is nothing fundamentally different about 'annotating offline' in an MD vs in the CLI and iterating until the plan is clear. It's a UI choice. Spec Driven Coding with AI is very well established, so working from a plan, or spec (they can be somewhat different) is not novel. This is conventional CC use.
  • dack 8mo ago
    last i checked, you can't annotate inline with planning mode. you have to type a lot to explain precisely what needs to change, and then it re-presents you with a plan (which may or may not have changed something else). i like the idea of having an actual document because you could actually compare the before and after versions if you wanted to confirm things changed as intended when you gave feedback
    • bluegatty 8mo ago
      'Giving precise feedback on a plan' is literally annotating the plan. It comes back to you with an update for verification. You ask it to 'write the plan' as matter of good practice. What the author is describing is conventional usage of claude code.
    • gitaarik 8mo ago
      A plan is just a file you can edit and then tell CC to check your annotations
• cadamsdotcom 8mo ago
  The author is quite far on their journey but would benefit from writing simple scripts to enforce invariants in their codebase. Invariant broken? Script exits with a non-zero exit code and some output that tells the agent how to address the problem. Scripts are deterministic, run in milliseconds, and use zero tokens. Put them in husky or pre-commit, install the git hooks, and your agent won’t be able to commit without all your scripts succeeding. And “Don’t change this function signature” should be enforced not by anticipating that your coding agent “might change this function signature so we better warn it not to” but rather via an end to end test that fails if the function signature is changed (because the other code that needs it not to change now has an error). That takes the author out of the loop and they can not watch for the change in order to issue said correction, and instead sip coffee while the agent observes that it caused a test failure then corrects it without intervention, probably by rolling back the function signature change and changing something else.
• dennisjoseph 8mo ago
  The annotation cycle is the key insight for me. Treating the plan as a living doc you iterate on before touching any code makes a huge difference in output quality. Experimentally, i've been using mfbt.ai [https://mfbt.ai https://mfbt.ai] for roughly the same thing in a team context. it lets you collaboratively nail down the spec with AI before handing off to a coding agent via MCP. Avoids the "everyone has a slightly different plan.md on their machine" problem. Still early days but it's been a nice fit for this kind of workflow.
  • minikomi 8mo ago
    I agree, and this is why I tend to use gptel in emacs for planning - the document is the conversation context, and can be edited and annotated as you like.
• Frannky 8mo ago
  I tried Opus 4.6 recently and it’s really good. I had ditched Claude a long time ago for Grok + Gemini + OpenCode with Chinese models. I used Grok/Gemini for planning and core files, and OpenCode for setup, running, deploying, and editing. However, Opus made me rethink my entire workflow. Now, I do it like this: * PRD (Product Requirements Document) * main.py + requirements.txt + readme.md (I ask for minimal, functional, modular code that fits the main.py) * Ask for a step-by-step ordered plan * Ask to focus on one step at a time The super powerful thing is that I don’t get stuck on missing accounts, keys, etc. Everything is ordered and runs smoothly. I go rapidly from idea to working product, and it’s incredibly easy to iterate if I figure out new features are required while testing. I also have GLM via OpenCode, but I mainly use it for "dumb" tasks. Interestingly, for reasoning capabilities regarding standard logic inside the code, I found Gemini 3 Flash to be very good and relatively cheap. I don't use Claude Code for the actual coding because forcing everything via chat into a main.py encourages minimal code that's easy to skim—it gives me a clearer representation of the feature space
  • kaydub 8mo ago
    Why would you use Grok at all? The one LLM that they're purposely trying to get specific output from (trying to make it "conservative"). I wouldn't want to use a project that I outright know is tainted by the owners trying to introduce bias.
• achenatx 8mo ago
  I use amazon kiro. The AI first works with you to write requirements, then it produces a design, then a task list. The helps the AI to make smaller chunks to work on, it will work on one task at a time. I can let it run for an hour or more in this mode. Then there is lots of stuff to fix, but it is mostly correct. Kiro also supports steering files, they are files that try to lock the AI in for common design decisions. the price is that a lot of the context is used up with these files and kiro constantly pauses to reset the context.
• amarant 8mo ago
  Interesting! I feel like I'm learning to code all over again! I've only been using Claude for a little more than a month and until now I've been figuring things out on my own. Building my methodology from scratch. This is much more advanced than what I'm doing. I've been going straight to implementation, but doing one very small and limited feature at a time, describing implementation details (data structures like this, use that API here, import this library etc) verifying it manually, and having Claude fix things I don't like. I had just started getting annoyed that it would make the same (or very similar) mistake over and over again and I would have to fix it every time. This seems like it'll solve that problem I had only just identified! Neat!
• w4yai 8mo ago
  You described how AntiGravity works natively.
• zmmmmm 8mo ago
  I actually don't really like a few of things about this approach. First, the "big bang" write it all at once. You are going to end up with thousands of lines of code that were monolithically produced. I think it is much better to have it write the plan and formulate it as sensible technical steps that can be completed one at a time. Then you can work through them. I get that this is not very "vibe"ish but that is kind of the point. I want the AI to help me get to the same point I would be at with produced code AND understanding of it, just accelerate that process. I'm not really interested in just generating thousands of lines of code that nobody understands. Second, the author keeps refering to adjusting the behaviour, but never incorporating that into long lived guidance. To me, integral with the planning process is building an overarching knowledge base. Every time you're telling it there's something wrong, you need to tell it to update the knowledge base about why so it doesn't do it again. Finally, no mention of tests? Just quick checks? To me, you have to end up with comprehensive tests. Maybe to the author it goes without saying, but I find it is integral to build this into the planning. Certain stages you will want certain types of tests. Some times in advance of the code (so TDD style) other times built alongside it or after. It's definitely going to be interesting to see how software methodology evolves to incorporate AI support and where it ultimately lands.
  • girvo 8mo ago
    The articles approach matches mine, but I've learned from exactly the things you're pointing out. I get the PLAN.md (or equivalent) to be separated into "phases" or stages, then carefully prompt (because Claude and Codex both love to "keep going") it to only implement that stage, and update the PLAN.md Tests are crucial too, and form another part of the plan really. Though my current workflow begins to build them later in the process than I would prefer...
• armanj 8mo ago
  > “remove this section entirely, we don’t need caching here” — rejecting a proposed approach I wonder why you don't remove it yourself. Aren't you already editing the plan?
• dnautics 8mo ago
  this is literally reinventing claude's planning mode, but with more steps. I think Boris doesn't realize that planning mode is actually stored in a file. https://x.com/boristane/status/2021628652136673282 https://x.com/boristane/status/2021628652136673282
• prodtorok 8mo ago
  Insights are nice for new users but I’m not seeing anything too different from how anyone experienced with Claude Code would use plan mode. You can reject plans with feedback directly in the CLI.
• tabs_or_spaces 8mo ago
  My workflow is a bit different. * I ask the LLM for it's understanding of a topic or an existing feature in code. It's not really planning, it's more like understanding the model first * Then based on its understanding, I can decide how great or small to scope something for the LLM * An LLM showing good understand can deal with a big task fairly well. * An LLM showing bad understanding still needs to be prompted to get it right * What helps a lot is reference implementations. Either I have existing code that serves as the reference or I ask for a reference and I review. A few folks do it at my work do it OPs way, but my arguments for not doing it this way * Nobody is measuring the amount of slop within the plan. We only judge the implementation at the end * it's still non deterministic - folks will have different experiences using OPs methods. If claude updates its model, it outdates OPs suggestions by either making it better or worse. We don't evaluate when things get better, we only focus on things not gone well. * it's very token heavy - LLM providers insist that you use many tokens to get the task done. It's in their best interest to get you to do this. For me, LLMs should be powerful enough to understand context with minimal tokens because of the investment into model training. Both ways gets the task done and it just comes down to my preference for now. For me, I treat the LLM as model training + post processing + input tokens = output tokens. I don't think this is the best way to do non deterministic based software development. For me, we're still trying to shoehorn "old" deterministic programming into a non deterministic LLM.
• umairnadeem123 8mo ago
  [dead]
• wokwokwok 8mo ago
  This is the way. The practice is: - simple - effective - retains control and quality Certainly the “unsupervised agent” workflows are getting a lot of attention right now, but they require a specific set of circumstances to be effective: - clear validation loop (eg. Compile the kernel, here is gcc that does so correctly) - ai enabled tooling (mcp / cli tool that will lint, test and provide feedback immediately) - oversight to prevent sgents going off the rails (open area of research) - an unlimited token budget That means that most people can't use unsupervised agents. Not that they dont work; Most people have simply not got an environment and task that is appropriate. By comparison, anyone with cursor or claude can immediately start using this approach, or their own variant on it. It does not require fancy tooling. It does not require an arcane agent framework. It works generally well across models. This is one of those few genunie pieces of good practical advice for people getting into AI coding. Simple. Obviously works once you start using it. No external dependencies. BYO tools to help with it, no “buy my AI startup xxx to help”. No “star my github so I can a job at $AI corp too”. Great stuff.
  • epec254 8mo ago
    Huge +1. This loop consistently delivers great results for my vibe coding. The “easy” path of “short prompt declaring what I want” works OK for simple tasks but consistently breaks down for medium to high complexity tasks.
    • apsurd 8mo ago
      Can you help me understand the difference between "short prompt for what I want (next)" vs medium to high complexity tasks? What i mean is, in practice, how does one even get to a a high complexity task? What does that look like? Because isn't it more common that one sees only so far ahead?
  • deleted 8mo ago
    [deleted]
  • dnautics 8mo ago
    It's more or less what comes out of the box with plan mode, plus a few extra bits?
• turingsroot 8mo ago
  I've been teaching AI coding tool workshops for the past year and this planning-first approach is by far the most reliable pattern I've seen across skill levels. The key insight that most people miss: this isn't a new workflow invented for AI - it's how good senior engineers already work. You read the code deeply, write a design doc, get buy-in, then implement. The AI just makes the implementation phase dramatically faster. What I've found interesting is that the people who struggle most with AI coding tools are often junior devs who never developed the habit of planning before coding. They jump straight to "build me X" and get frustrated when the output is a mess. Meanwhile, engineers with 10+ years of experience who are used to writing design docs and reviewing code pick it up almost instantly - because the hard part was always the planning, not the typing. One addition I'd make to this workflow: version your research.md and plan.md files in git alongside your code. They become incredibly valuable documentation for future maintainers (including future-you) trying to understand why certain architectural decisions were made.
  • hghbbjh 8mo ago
    > it's how good senior engineers already work The other trick all good ones I’ve worked with converged on: it’s quicker to write code than review it (if we’re being thorough). Agents have some areas where they can really shine (boilerplate you should maybe have automated already being one), but most of their speed comes from passing the quality checking to your users or coworkers. Juniors and other humans are valuable because eventually I trust them enough to not review their work. I don’t know if LLMs can ever get here for serious industries.
  • __mharrison__ 8mo ago
    I teach a lot of folks who "aren't software engineers" but are sitting in front of Jupyter all day writing code. Covertly teaching software engineering best practices is super relevant. I've also found testing skills sorely lacking and even more important in AI driven development.
• DevEx7 8mo ago
  I’m a big fan of having the model create a GitHub issue directly (using the GH CLI) with the exact plan it generates, instead of creating a markdown file that will eventually get deleted. It gives me a permanent record and makes it easy to reference and close the issue once the PR is ready.
• RVuRnvbM2e 8mo ago
  This is just Waterfall for LLMs. What happens when you explore the problem space and need to change up the plan?
  • kaydub 8mo ago
    Do you think this is a gotcha? You just prompt the llm to change the plan.
• mukundesh 8mo ago
  https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ https://github.blog/ai-and-ml/generative-ai/spec-driven-deve...
• paradite 8mo ago
  Lol I wrote about this and been using plan+execute workflow for 8 months. Sadly my post didn't much attention at the time. https://thegroundtruth.media/p/my-claude-code-workflow-and-personal-tips https://thegroundtruth.media/p/my-claude-code-workflow-and-p...
• deleted 8mo ago
  [deleted]
• wangzhongwang 8mo ago
  [dead]
• connectsnk 8mo ago
  Is it required to tell Claude to re-read the code folder again when you come back some day later or should we ask Claude to just pickup from research.md file thus saving some tokens?
• mkl 8mo ago
  How are the annotations put into the markdown? Claude needs to be able to identify them as annotations and not parts of the plan.
• vibeprofessor 8mo ago
  add another agent review, I ask Claude to send plan for review to Codex and fix critical and high issues, with complexity gating (no overcomplicated logic), run in a loop, then send to Gemini reviewer, then maybe final pass with Claude, once all C+H pass the sequence is done
• throwaway7783 8mo ago
  I have to give this a try. My current model for backend is the same as how author does frontend iteration. My friend does the research-plan-edit-implement loop, and there is no real difference between the quality of what I do and what he does. But I do like this just for how it serves as documentation of the thought process across AI/human, and can be added to version control. Instead of humans reviewing PRs, perhaps humans can review the research/plan document. On the PR review front, I give Claude the ticket number and the branch (or PR) and ask it to review for correctness, bugs and design consistency. The prompt is always roughly the same for every PR. It does a very good job there too. Modelwise, Opus 4.6 is scary good!
• rotbart 8mo ago
  This is a similar workflow to speckit, kiro, gsd, etc.
• efnx 8mo ago
  I’ve been using Claude through opencode, and I figured this was just how it does it. I figured everyone else did it this way as well. I guess not!
• swe_dima 8mo ago
  Since everyone is showing their flow, here's mine: * create a feature-name.md file in a gitignored folder * start the file by giving the business context * describe a high-level implementation and user flows * describe database structure changes (I find it important not to leave it for interpretation) * ask Claude to inspect the feature and review if for coherence, while answering its questions I ask to augment feature-name.md file with the answers * enter Claude's plan mode and provide that feature-name.md file * at this point it's detailed enough that rarely any corrections from me are needed
• Merad 8mo ago
  I've been working off and on on a vibe coded FP language and transpiler - mostly just to get more experience with Claude Code and see how it handles complex real world projects. I've settled on a very similar flow, though I use three documents: plan, context, task list. Multiple rounds of iteration when planning a feature. After completion, have a clean session do an audit to confirm that everything was implemented per the design. Then I have both Claude and CodeRabbit do code review passes before I finally do manual review. VERY heavy emphasis on tests, the project currently has 2x more test code than application code. So far it works surprisingly well. Example planning docs below - https://github.com/mbcrawfo/vibefun/tree/main/.claude/archive/2026-02-02-codegen https://github.com/mbcrawfo/vibefun/tree/main/.claude/archiv...
• kulikalov 8mo ago
  I came to the exact same pattern, with one extra heuristic at the end: spin up a new claude instance after the implementation is complete and ask it to find discrepancies between the plan and the implementation.
• zahlman 8mo ago
  > 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, to make it correct, rather than adding the corrections as separate notes (and expecting future Claude to parse out which parts were past Claude and which parts were the operator, and handle the feedback graciously)? At least, it seems like the intent is to do all of this in the same session, such that Claude has the context of the entire back-and-forth updating the plan. But that seems a bit unpleasant; I would think the file is there specifically to preserve context between sessions.
  • fendy3002 8mo ago
    One reason why I don't do this: even I won't be immune to mistakes. When I fix it with new values or paths, for example, and the one I provided is wrong, it can worsen the future work. Personally, I like to order claude one more time to update the plan file after I have given annotation, and review it again after. This will ensure (from my understanding) that claude won't treat my annotation as different instructions, thus risking the work being conflicted.
  • ramoz 8mo ago
    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.
• strix_varius 8mo ago
  The baffling part of the article is all the assertions about how this is unique, novel, not the typical way people are doing this etc. There are whole products wrapped around this common workflow already (like Augment Intent).
• raptorraver 8mo ago
  I’ve been using this same pattern, except not the research phase. Definetly will try to add it to my process aswell. Sometimes when doing big task I ask claude to implement each phase seprately and review the code after each step.
• lxe 8mo ago
  Honestly, I found that the best way to use these CLIs is exactly how the CLI creators have intended.
• nerdright 8mo ago
  Haha this is surprisingly and exactly how I use claude as well. Quite fascinating that we independently discovered the same workflow. I maintain two directories: "docs/proposals" (for the research md files) and "docs/plans" (for the planning md files). For complex research files, I typically break them down into multiple planning md files so claude can implement one at a time. A small difference in my workflow is that I use subagents during implementation to avoid context from filling up quickly.
  • brendanmc6 8mo ago
    Same, I formalized a similar workflow for my team (oriented around feature requirement docs), I am thinking about fully productizing it and am looking to for feedback - https://acai.sh https://acai.sh Even if the product doesn’t resonate I think I’ve stumbled on some ideas you might find useful^ I do think spec-driven development is where this all goes. Still making up my mind though.
    • clouedoc 8mo ago
      This is basically long-lived specs that are used as tests to check that the product still adheres to the original idea that you wanted to implement, right? This inspired me to finally write good old playwright tests for my website :).
    • puchatek 8mo ago
      Spec-driven looks very much like what the author describes. He may have some tweaks of his own but they could just as well be coded into the artifacts that something like OpenSpec produces.
• rossant 8mo ago
  Funny how I came up with something loosely similar. Asking Codex to write a detailed plan in a markdown document, reviewing it, and asking it to implement it step by step. It works exquisitely well when it can build and test itself.
• duttish 8mo ago
  This is quite close to what I've arrived at, but with two modifications 1) anything larger I work on in layers of docs. Architecture and requirements -> design -> implementation plan -> code. Partly it helps me think and nail the larger things first, and partly helps claude. Iterate on each level until I'm satisfied. 2) when doing reviews of each doc I sometimes restart the session and clear context, it often finds new issues and things to clear up before starting the next phase.
  • stevendaniels 8mo ago
    When I use other models review plans (eg opus 4.x with Gemini3 or codex5.x), they often surface different issues than the model that wrote the plan.
• mvkel 8mo ago
  > 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 in batches, where the plan is no more than 1,500 lines, used as a proxy for complexity. My 30,000 LOC app has about 100,000 lines of plan behind it. Can't build something that big as a one-shot.
  • Bishonen88 8mo ago
    Dunno. My 80k+ LOC personal life planner, with a native android app, eink display view still one shots most features/bugs I encounter. I just open a new instance let it know what I want and 5min later it's done.
    • therealdrag0 8mo ago
      In 5 min you are one shotting smaller changes to the larger code base right? Not the entire 80k likes which was the other comments point afaict.
      • Bishonen88 8mo ago
        Yeah, then I guess I misunderstood the post. Its smaller features one by one ofc.
    • makeramen 8mo ago
      Both can be true. I have personally experienced both. Some problems AI surprised me immensely with fast, elegant efficient solutions and problem solving. I've also experienced AI doing totally absurd things that ended up taking multiple times longer than if I did it manually. Sometimes in the same project.
    • vasco 8mo ago
      What is a personal life planner?
• d1sxeyes 8mo ago
  The “inline comments on a plan” is one of the best features of Antigravity, and I’m surprised others haven’t started copycatting.
• _hugerobots_ 8mo ago
  Hub and spoke documentation in planning has been absolutely essential for the way my planning was before, and it's pretty cool seeing it work so well for planning mode to build scaffolds and routing.
• geoffbp 8mo ago
  It’s worrying to me that nobody really knows how LLMs work. We create prompts with or without certain words and hope it works. That’s my perspective anyway
  • solumunus 8mo ago
    It's the same as dealing with a human. You convey a spec for a problem and the language you use matters. You can convey the problem in (from your perspective) a clear way and you will get mixed results nonetheless. You will have to continue to refine the solution with them. Genuinely: no one really knows how humans work either.
  • mannyv 8mo ago
    It's actually no different from how real software is made. Requirements come from the business side, and through an odd game of telephone get down to developers. The team that has developers closest to the customer usually makes the better product...or has the better product/market fit. Then it's iteration.
• cawksuwcka 8mo ago
  falling asleep here. when will the babysitting end
• tayo42 8mo ago
  We're just slowly reinventing agile for telling Ai agents what to do lol Just skip to the Ai stand-ups
• cheekyant 8mo ago
  It seems like the annotation of plan files is the key step. Claude Code now creates persistent markdown plan files in ~/.claude/plans/ and you can open them with Ctrl-G to annotate them in your default editor. So plan mode is not ephemeral any more.
• chaboud 8mo ago
  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 solve that? Exactly how an experienced lead or software manager does: you have systems write it down before executing, explain things back to you, and ground all of their thinking in the code and documentation, avoiding making assumptions about code after superficial review. When it was early ChatGPT, this meant function-level thinking and clearly described jobs. When it was Cline it meant cline rules files that forced writing architecture.md files and vibe-code.log histories, demanding grounding in research and code reading. Maybe nine months ago, another engineer said two things to me, less than a day apart: - "I don't understand why your clinerules file is so large. You have the LLM jumping through so many hoops and doing so much extra work. It's crazy." - The next morning: "It's basically like a lottery. I can't get the LLM to generate what I want reliably. I just have to settle for whatever it comes up with and then try again." These systems have to deal with minimal context, ambiguous guidance, and extreme isolation. Operate with a little empathy for the energetic interns, and they'll uncork levels of output worth fighting for. We're Software Managers now. For some of us, that's working out great.
  • deleted 8mo ago
    [deleted]
  • blackarrow36 8mo ago
    [flagged]
  • marc_g 8mo ago
    I’ve also found that a bigger focus on expanding my agents.md as the project rolls on has led to less headaches overall and more consistency (non-surprisingly). It’s the same as asking juniors to reflect on the work they’ve completed and to document important things that can help them in the future. Software Manger is a good way to put this.
• growt 8mo ago
  That is just spec driven development without a spec, starting with the plan step instead.
• YetAnotherNick 8mo ago
  I don't know. I tried various methods. And this one kind of doesn't work quite a bit of times. The problem is plan naturally always skips some important details, or assumes some library function, but is taken as instruction in the next section. And claude can't handle ambiguity if the instruction is very detailed(e.g. if plan asks to use a certain library even if it is a bad fit claude won't know that decision is flexible). If the instruction is less detailed, I saw claude is willing to try multiple things and if it keeps failing doesn't fear in reverting almost everything. In my experience, the best scenario is that instruction and plan should be human written, and be detailed.
• pgt 8mo ago
  My process is similar, but I recently added a new "critique the plan" feedback loop that is yielding good results. Steps: 1. Spec 2. Plan 3. Read the plan & tell it to fix its bad ideas. 4. (NB) Critique the plan (loop) & write a detailed report 5. Update the plan 6. Review and check the plan 7. Implement plan Detailed here: https://x.com/PetrusTheron/status/2016887552163119225 https://x.com/PetrusTheron/status/2016887552163119225
  • brumar 8mo ago
    Same. In my experience, the first plan always benefits from being challenged once or twice by claude itself.
• lastdong 8mo ago
  Google Anti-Gravity has this process built in. This is essentially a cycle a developer would follow: plan/analyse - document/discuss - break down tasks/implement. We’ve been using requirements and design documents as best practice since leaving our teenage bedroom lab for the professional world. I suppose this could be seen as our coding agents coming of age.
• w10-1 8mo ago
  I try these staging-document patterns, but suspect they have 2 fundamental flaws that stem mostly from our own biases. First, Claude evolves. The original post work pattern evolved over 9 months, before claude's recent step changes. It's likely claude's present plan mode is better than this workaround, but if you stick to the workaround, you'd never know. Second, the staging docs that represent some context - whether a library skills or current session design and implementation plans - are not the model Claude works with. At best they are shaping it, but I've found it does ignore and forget even what's written (even when I shout with emphasis), and the overall session influences the code. (Most often this happens when a peripheral adjustment ends up populating half the context.) Indeed the biggest benefit from the OP might be to squeeze within 1 session, omitting peripheral features and investigations at the plan stage. So the mechanism of action might be the combination of getting our own plan clear and avoiding confusing excursions. (A test for that would be to redo the session with the final plan and implementation, to see if the iteration process itself is shaping the model.) Our bias is to believe that we're getting better at managing this thing, and that we can control and direct it. It's uncomfortable to realize you can only really influence it - much like giving direction to a junior, but they can still go off track. And even if you found a pattern that works, it might work for reasons you're not understanding -- and thus fail you eventually. So, yes, try some patterns, but always hang on to the newbie senses of wonder and terror that make you curious, alert, and experimental.
  • sumedh 8mo ago
    > First, Claude evolves. Boris, the creator of claude code said that he find this spec driven developemnt not necessary, with the Opus 4.6 he says CC's plan mode is enough.
  • MantraHQ 8mo ago
    [dead]
• appsoftware 8mo ago
  This is the flow I've found myself working towards. Essentially maintaining more and more layered documentation for the LLM produces better and more consistent results. What is great here is the emphasis on the use of such documents in the planning phase. I'm feeling much more motivated to write solid documentation recently, because I know someone (the LLM) is actually going to read it! I've noticed my efforts and skill acquisition have moved sharply from app developer towards DevOps and architecture / management, but I think I'll always be grateful for the application engineering experience that I think the next wave of devs might miss out on. I've also noted such a huge gulf between some developers describing 'prompting things into existence' and the approach described in this article. Both types seem to report success, though my experience is that the latter seems more realistic, and much more likely to produce robust code that's likely to be maintainable for long term or project critical goals.
• dr_dshiv 8mo ago
  Another pattern is: 1. First vibecode software to figure out what you want 2. Then throw it out and engineer it
• chickensong 8mo ago
  I agree with most of this, though I'm not sure it's radically different. I think most people who've been using CC in earnest for a while probably have a similar workflow? Prior to Claude 4 it was pretty much mandatory to define requirements and track implementation manually to manage context. It's still good, but since 4.5 release, it feels less important. CC basically works like this by default now, so unless you value the spec docs (still a good reference for Claude, but need to be maintained), you don't have to think too hard about it anymore. The important thing is to have a conversation with Claude during the planning phase and don't just say "add this feature" and take what you get. Have a back and forth, ask questions about common patterns, best practices, performance implications, security requirements, project alignment, etc. This is a learning opportunity for you and Claude. When you think you're done, request a final review to analyze for gaps or areas of improvement. Claude will always find something, but starts to get into the weeds after a couple passes. If you're greenfield and you have preferences about structure and style, you need to be explicit about that. Once the scaffolding is there, modern Claude will typically follow whatever examples it finds in the existing code base. I'm not sure I agree with the "implement it all without stopping" approach and let auto-compact do its thing. I still see Claude get lazy when nearing compaction, though has gotten drastically better over the last year. Even so, I still think it's better to work in a tight loop on each stage of the implementation and preemptively compacting or restarting for the highest quality. Not sure that the language is that important anymore either. Claude will explore existing codebase on its own at unknown resolution, but if you say "read the file" it works pretty well these days. My suggestions to enhance this workflow: - If you use a numbered phase/stage/task approach with checkboxes, it makes it easy to stop/resume as-needed, and discuss particular sections. Each phase should be working/testable software. - Define a clear numbered list workflow in CLAUDE.md that loops on each task (run checks, fix issues, provide summary, etc). - Use hooks to ensure the loop is followed. - Update spec docs at the end of the cycle if you're keeping them. It's not uncommon for there to be some divergence during implementation and testing.
  • vincentvandeth 8mo ago
    [dead]
• deleted 8mo ago
  [deleted]
• koevet 8mo ago
  Has 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.
  • jsmith99 8mo ago
    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).
    • Sammi 8mo ago
      Yes this is what agent "skills" are. Just guides on any topic. The key is that you have the agent write and maintain them.
  • KellyCriterion 8mo ago
    In Claude Web you can use projects to put files relevant for context there.
    • mstkllah 8mo ago
      And then you have to remind it frequently to make use of the files. Happened to me so many times that I added it both to custom instructions as well as to the project memory.
  • hathawsh 8mo ago
    That sounds like the recommended approach. However, there's one more thing I often do: whenever Claude Code and I complete a task that didn't go well at first, I ask CC what it learned, and then I tell it to write down what it learned for the future. It's hard to believe how much better CC has become since I started doing that. I ask it to write dozens of unit tests and it just does. Nearly perfectly. It's insane.
• gregman1 8mo ago
  It 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.
• smcleod 8mo ago
  I 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).
• nesk_ 8mo ago
  > I am not seeing the performance degradation everyone talks about after 50% context window. I pretty much agree with that. I use long sessions and stopped trying to optimize the context size, the compaction happens but the plan keeps the details and it works for me.
• charkubi 8mo ago
  Planning is important because you get the LLM to explain the problem and solution in its language and structure, not yours. This shortcuts a range of problem cases where the LLM fights between the users strict and potentially conflicting requirements, and its own learning. In the early days we used to get LLM to write the prompts for us to get round this problem, now we have planning built in.
• shevy-java 8mo ago
  I don't deny that AI has use cases, but boy - the workflow described is boring: "Most developers type a prompt, sometimes use plan mode, fix the errors, repeat. " Does anyone think this is as epic as, say, watch the Unix archives https://www.youtube.com/watch?v=tc4ROCJYbm0 https://www.youtube.com/watch?v=tc4ROCJYbm0 where Brian demos how pipes work; or Dennis working on C and UNIX? Or even before those, the older machines? I am not at all saying that AI tools are all useless, but there is no real epicness. It is just autogenerated AI slop and blob. I don't really call this engineering (although I also do agree, that it is engineering still; I just don't like using the same word here). > never let Claude write code until you’ve reviewed and approved a written plan. So the junior-dev analogy is quite apt here. I tried to read the rest of the article, but I just got angrier. I never had that feeling watching oldschool legends, though perhaps some of their work may be boring, but this AI-generated code ... that's just some mythical random-guessing work. And none of that is "intelligent", even if it may appear to work, may work to some extent too. This is a simulation of intelligence. If it works very well, why would any software engineer still be required? Supervising would only be necessary if AI produces slop.
• gehsty 8mo ago
  Doesn’t Claude code do this by switching between edit mode and plan mode? FWIW I have had significant improvements by clearing context then implementing the plan. Seems like it stops Claude getting hung up on something.
• je42 8mo ago
  There are frameworks like https://github.com/bmad-code-org/BMAD-METHOD https://github.com/bmad-code-org/BMAD-METHOD and https://github.github.com/spec-kit/ https://github.github.com/spec-kit/ that are working on encoding a similar kind of approach and process.
• mcv 8mo ago
  This is great. My workflow is also heading in that direction, so this is a great roadmap. I've already learned that just naively telling Claude what to do and letting it work, is a recipe for disaster and wasted time. I'm not this structured yet, but I often start with having it analyse and explain a piece of code, so I can correct it before we move on. I also often switch to an LLM that's separate from my IDE because it tends to get confused by sprawling context.
• gary17the 8mo ago
  > Read deeply, write a plan, annotate the plan until it’s right, then let Claude execute the whole thing without stopping, checking types along the way. As others have already noted, this workflow is exactly what the Google Antigravity agent (based off Visual Studio Code) has been created for. Antigravity even includes specialized UI for a user to annotate selected portions of an LLM-generated plan before iterating it. One significant downside to Antigravity I have found so far is the fact that even though it will properly infer a certain technical requirement and clearly note it in the plan it generates (for example, "this business reporting column needs to use a weighted average"), it will sometimes quietly downgrade such a specialized requirement (for example, to a non-weighted average), without even creating an appropriate "WARNING:" comment in the generated code. Especially so when the relevant codebase already includes a similar, but not exactly appropriate API. My repetitive prompts to ALWAYS ask about ANY implementation ambiguities WHATSOEVER go unanswered. From what I gather Claude Code seems to be better than other agents at always remembering to query the user about implementation ambiguities, so maybe I will give Claude Code a shot over Antigravity.
  • ramoz 8mo ago
    With hooks you can achieve a similar UI that can do what antigravity does just as much & better. Search "claude code plan annotations plugin" and youll come across some.
    • ramoz 8mo ago
      example: https://github.com/backnotprop/plannotator https://github.com/backnotprop/plannotator
• Fuzzwah 8mo ago
  All sounds like a bespoke way of remaking https://github.com/Fission-AI/OpenSpec https://github.com/Fission-AI/OpenSpec
• __bjoernd 8mo ago
  Sounds a bit like what Claude Plan Mode or Amazon's Kiro were built for. I agree it's a useful flow, but you can also overdo it.
• grabshot_dev 8mo ago
  Why don't you make Claude give feedback and iterate by itself?
• alexrezvov 8mo ago
  Cool, the idea of leaving comments directly in the plan never even occurred to me, even though it really is the obvious thing to do. Do you markup and then save your comments in any way, and have you tried keeping them so you can review the rules and requirements later?
• zuInnp 8mo ago
  Since the rise of AI systems I really wonder how people wrote code before. This is exactly how I planned out implementation and executed the plan. Might have been some paper notes, a ticket or a white board, buuuuut ... I don't know.
• willsmith72 8mo ago
  this sounds... really slow. for large changes for sure i'm investing time into planning. but such a rigid system can't possible be as good as a flexible approach with variable amounts of planning based on complexity
• EastLondonCoder 8mo ago
  I don’t use plan.md docs either, but I recognise the underlying idea: you need a way to keep agent output constrained by reality. My workflow is more like scaffold -> thin vertical slices -> machine-checkable semantics -> repeat. Concrete example: I built and shipped a live ticketing system for my club (Kolibri Tickets). It’s not a toy: real payments (Stripe), email delivery, ticket verification at the door, frontend + backend, migrations, idempotency edges, etc. It’s running and taking money. The reason this works with AI isn’t that the model “codes fast”. It’s that the workflow moves the bottleneck from “typing” to “verification”, and then engineers the verification loop: -keep the spine runnable early (end-to-end scaffold) -add one thin slice at a time (don’t let it touch 15 files speculatively) -force checkable artifacts (tests/fixtures/types/state-machine semantics where it matters) -treat refactors as normal, because the harness makes them safe If you run it open-loop (prompt -> giant diff -> read/debug), you get the “illusion of velocity” people complain about. If you run it closed-loop (scaffold + constraints + verifiers), you can actually ship faster because you’re not paying the integration cost repeatedly. Plan docs are one way to create shared state and prevent drift. A runnable scaffold + verification harness is another.
  • aitchnyu 8mo ago
    Now that code is cheap, I ensured my side project has unit/integration tests (will enforce 100% coverage), Playwright tests, static typing (its in Python), scripts for all tasks. Will learn mutation testing too (yes, its overkill). Now my agent works upto 1 hour in loops and emits concise code I dont have to edit much.
    • EastLondonCoder 8mo ago
      Totally get it, and I think we’re describing the same control loop from different angles. Where I differ slightly is: “100% coverage” can turn into productivity theatre. It’s a metric that’s easy to optimize while missing the thing you actually care about: do we have machine-checkable invariants at the points where drift is expensive? The harness that’s paid off for me (on a live payments system) is: - thin vertical slice first (end-to-end runnable, even if ugly) - tests at the seams (payments, emails, ticket verification / idempotency) - state-machine semantics where concurrency/ordering matters - unit tests as supporting beams, not wallpaper Then refactors become routine, because the tests will make breakage explicit. So yes: “code is cheap” -> increase verification. Just careful not to replace engineering judgement with an easily gamed proxy.
• yunusabd 8mo ago
  That's exactly what Cursor's "plan" mode does? It even creates md files, which seems to be the main "thing" the author discovered. Along with some cargo cult science? How is this noteworthy other than to spark a discussion on hn? I mean I get it, but a little more substance would be nice.
• irthomasthomas 8mo ago
  In my own tests I have found opus to be very good at writing plans, terrible at executing them. It typically ignores half of the constraints. https://x.com/xundecidability/status/2019794391338987906?s=20 https://x.com/xundecidability/status/2019794391338987906?s=2... https://x.com/xundecidability/status/2024210197959627048?s=20 https://x.com/xundecidability/status/2024210197959627048?s=2...
  • Sammi 8mo ago
    1. Don't implement too much at at time 2. Have the agent review if it followed the plan and relevant skills accurately.
    • irthomasthomas 8mo ago
      the first link was from a simple request with fewer than 1000 tokens total in the context window, just a short shell script. here is another one which had about 200 tokens and opus decided to change the model name i requested. https://x.com/xundecidability/status/2005647216741105962?s=20 https://x.com/xundecidability/status/2005647216741105962?s=2... opus is bad at instruction following now.
• richardjennings 8mo ago
  This is similar to what I do. I instruct an Architect mode with a set of rules related to phased implementation and detailed code artifacts output to a report.md file. After a couple of rounds of review and usually some responses that either tie together behaviors across context, critique poor choices or correct assumptions, there is a piece of work defined for a coder LLM to perform. With the new Opus 4.6 I then select specialist agents to review the report.md, prompted with detailed insight into particular areas of the software. The feedback from these specialist agent reviews is often very good and sometimes catches things I had missed. Once all of this is done, I let the agent make the changes and move onto doing something else. I typically rename and commit the report.md files which can be useful as an alternative to git diff / commit messages etc.
• vazma 8mo ago
  Sorry but I didn't get the hype with this post, isnt it what most of the people doing? I want to see more posts on how you use the claude "smart" without feeding the whole codebase polluting the context window and also more best practices on cost efficient ways to use it, this workflow is clearly burning million tokens per session, for me is a No
• pajamasam 8mo ago
  I feel like if I have to do all this, I might as well write the code myself.
• MarcLore 8mo ago
  [dead]
• nikolay 8mo ago
  Well, that's already done by Amazon's Kiro [0], Google's Antigravity [1], GitHub's Spec Kit [2], and OpenSpec [3]! [0]: https://kiro.dev/ https://kiro.dev/ [1]: https://antigravity.google/ https://antigravity.google/ [2]: https://github.github.com/spec-kit/ https://github.github.com/spec-kit/ [3]: https://openspec.dev/ https://openspec.dev/
• baalimago 8mo ago
  Another approach is to spec functionality using comments and interfaces, then tell the LLM to first implement tests and finally make the tests pass. This way you also get regression safety and can inspect that it works as it should via the tests.
• folex 8mo ago
  this is exactly how I work with cursor except that I put notes to plan document in a single message like: > plan quote my note > plan quote my note otherwise, I'm not sure how to guarantee that ai won't confuse my notes with its own plan. one new thing for me is to review the todo list, I was always relying on auto generated todo list
• adithyassekhar 8mo ago
  What I've read is that even with all the meticulous planning, the author still needed to intervene. Not at the end but at the middle, unless it will continue building out something wrong and its even harder to fix once it's done. It'll cost even more tokens. It's a net negative. You might say a junior might do the same thing, but I'm not worried about it, at least the junior learned something while doing that. They could do it better next time. They know the code and change it from the middle where it broke. It's a net positive.
  • ionwake 8mo ago
    this comment is the first truly humane one ive read regarding this whole AI fiasco
  • anonymousDan 8mo ago
    Unfortunately, you could argue that the model provider has also learned something, i.e. the interaction can be used as additional training data to train subsequent models.
  • sumedh 8mo ago
    When the user intervenes, the model providers will look at those signal and tweak the next version of the model on what it can do better so that the user does not need to intervene next time.
• jeleh 8mo ago
  Good article, but I would rephrase the core principle slightly: Never let Claude write code until you’ve reviewed, *fully understood* and approved a written plan. In my experience, the beginning of chaos is the point at which you trust that Claude has understood everything correctly and claims to present the very best solution. At that point, you leave the driver's seat.
• vemv 8mo ago
  Every "how I use Claude Code" post will get into the HN frontpage. Which maybe has to do with people wanting to show how they use Claude Code in the comments!
• juanre 8mo ago
  Shameless plug: https://beadhub.ai https://beadhub.ai allows you to do exactly that, but with several agents in parallel. One of them is in the role of planner, which takes care of the source-of-truth document and the long term view. They all stay in sync with real-time chat and mail. It's OSS. Real-time work is happening at https://app.beadhub.ai/juanre/beadhub https://app.beadhub.ai/juanre/beadhub (beadhub is a public project at https://beadhub.ai https://beadhub.ai so it is visible). Particularly interesting (I think) is how the agents chat with each other, which you can see at https://app.beadhub.ai/juanre/beadhub/chat https://app.beadhub.ai/juanre/beadhub/chat
• colinhb 8mo ago
  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 dramatically better when it has a concrete reference implementation to work from rather than designing from scratch. Licensing apparently means nothing. Ripped off in the training data, ripped off in the prompt.
  • miohtama 8mo ago
    Concepts are not copyrightable.
    • colinhb 8mo ago
      The article isn’t describing someone who learned the concept of sortable IDs and then wrote their own implementation. It describes copying and pasting actual code from one project into a prompt so a language model can reproduce it in another project. It’s a mechanical transformation of someone else’s copyrighted expression (their code) laundered through a statistical model instead of a human copyist.
      • layer8 8mo ago
        “Mechanical” is doing some heavy lifting here. If a human does the same, reimplement the code in their own style for their particular context, it doesn’t violate copyright. Having the LLM see the original code doesn’t automatically make its output a plagiarism.
  • larard 8mo ago
    That is the exact passage I found so shocking - if one finds the code in an open source repo, is it really acceptable to pass it through Claude code as some sort of license filter and make it proprietary? On the other hand, next time OSX/windows/etc is leaked, one could feed it through this very same license filter. What is sauce for the goose is sauce for the gander.
• parasti 8mo ago
  The biggest roadblock to using agents to maximum effectiveness like this is the chat interface. It's convenience as detriment and convenience as distraction. I've found myself repeatedly giving into that convenience only to realize that I have wasted an hour and need to start over because the agent is just obliviously circling the solution that I thought was fully obvious from the context I gave it. Clearly these tools are exceptional at transforming inputs into outputs and, counterintuitively, not as exceptional when the inputs are constantly interleaved with the outputs like they are in chat mode.
  • sumedh 8mo ago
    > I thought was fully obvious from the context I gave it. Lot of people think they have given the right instructions but in most cases people miss some crucial points and that leads the model in the wrong direction, then the same people complain AI is not good.
• submeta 8mo ago
  What works extremely well for me is this: Let Claude Code create the plan, then turn over the plan to Codex for review, and give the response back to Claude Code. Codex is exceptionally good at doing high level reviews and keeping an eye on the details. It will find very suble errors and omissins. And CC is very good at quickly converting the plan into code. This back and forth between the two agents with me steering the conversation elevates Claude Code into next level.
• drcongo 8mo ago
  This is exactly how I use it.
• oulipo2 8mo ago
  Has Claude Code become slow, laggy, imprecise, giving wrong answers for other people here?
• stuaxo 8mo ago
  I had to stop reading about half way, it's written in that breathless linkedin/ai generated style.
• buildoak 8mo ago
  [dead]
• podgorniy 8mo ago
  I do the same. I also cross-ask gemini and claude about the plan during iterations, sometimes make several separate plans.
• clbrmbr 8mo ago
  I just use Jesse’s “superpowers” plugin. It does all of this but also steps you through the design and gives you bite sized chunks and you make architecture decisions along the way. Far better than making big changes to an already established plan.
  • tagawa 8mo ago
    Link for those interested: https://claude.com/plugins/superpowers https://claude.com/plugins/superpowers
    • clbrmbr 8mo ago
      I suggest reading the tests that Superpowers author has come up with for testing the skills. See the GitHub repo.
    • flippyhead 8mo ago
      Have you tried https://github.com/pcvelz/superpowers https://github.com/pcvelz/superpowers ?
  • clbrmbr 8mo ago
    https://github.com/obra/superpowers https://github.com/obra/superpowers
• xbmcuser 8mo ago
  Gemini is better at research Claude at coding. I try to use Gemini to do all the research and write out instruction on what to do what process to follow then use it in Claude. Though I am mostly creating small python scripts
• sparin9 8mo ago
  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.
  • hun3 8mo ago
    Except that merely surfacing them changes their behavior, like how you add that one printf() call and now your heisenbug is suddenly nonexistent
  • maccard 8mo ago
    > 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.
    • kertoip_1 8mo ago
      Might depend on used language. From my experience Claude Sonnet indeed never make any syntax mistakes in JS/TS/C#, but these are popular language with lots of training data.
  • remify 8mo ago
    Sub agent also helps a lot in that regard. Have an agent do the planning, have an implementation agent do the code and have another one do the review. Clear responsabilities helps a lot. There also blue team / red team that works. The idea is always the same: help LLM to reason properly with less and more clear instructions.
    • jalopy 8mo ago
      This sounds very promising. Any link to more details?
• dr_kretyn 8mo ago
  The post and comments all read like: Here are my rituals to the software God. If you follow them then God gives plenty. Omit one step and the God mad. Sometimes you have to make a sacrifice but that's better for the long term. I've been in eng for decades but never participated in forums. Is the cargo cult new? I use Claude Code a lot. Still don't trust what's in the plan will get actually written, regardless of details. My ritual is around stronger guardrails outside of prompting. This is the new MongoDB webscale meme.
• getnormality 8mo ago
  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
  • christophilus 8mo ago
    Yeah, OODA loop for programmers, basically. It’s a good approach.
• indiekitai 8mo ago
  [dead]
• kissgyorgy 8mo ago
  There is not a lot of explanation WHY is this better than doing the opposite: start coding and see how it goes and how this would apply to Codex models. I do exactly the same, I even developed my own workflows wit Pi agent, which works really well. Here is the reason: - Claude needs a lot more steering than other models, it's too eager to do stuff and does stupid things and write terrible code without feedback. - Claude is very good at following the plan, you can even use a much cheaper model if you have a good plan. For example I list every single file which needs edits with a short explanation. - At the end of the plan, I have a clear picture in my head how the feature will exactly look like and I can be pretty sure the end result will be good enough (given that the model is good at following the plan). A lot of things don't need planning at all. Simple fixes, refactoring, simple scripts, packaging, etc. Just keep it simple.
• etothet 8mo ago
  “The workflow I’m going to describe has one core principle: never let Claude write code until you’ve reviewed and approved a written plan.” I’m not sure we need to be this black and white about things. Speaking from the perspective of leading a dev team, I regularly have Claude Code take a chance at code without reviewing a plan. For example, small issues that I’ve written clear details about, Claude can go to town on those. I’ve never been on a team that didn’t have too many of these types of issues to address. And, a team should have othee guards in place that validates that code before it gets merged somewhere important. I don’t have to review every single decision one of my teammates is going to make, even those less experienced teammates, but I do prepare teammates with the proper tools (specs, documentation, etc) so they can make a best effort first attempt. This is how I treat Claude Code in a lot of scenarios.
• josefrichter 8mo ago
  Radically different? Sounds to me like the standard spec driven approach that plenty of people use. I prefer iterative approach. LLMs give you incredible speed to try different approaches and inform your decisions. I don’t think you can ever have a perfect spec upfront, at least that’s my experience.
• MagicMoonlight 8mo ago
  So we’re back to waterfall huh
• islandfox100 8mo ago
  It strikes me that if this technology were as useful and all-encompassing as it's marketed to be, we wouldn't need four articles like this every week
  • prplfsh 8mo ago
    People are figuring it out. Cars are broadly useful, but there's nuance to how to maintain then, use them will in different terrains and weather, etc.
  • hombre_fatal 8mo ago
    How many millions of articles are there about people figuring out how to write better software? Does something have to be trivial-to-use to be useful?
• turingsroot 8mo ago
  I've been running AI coding workshops for engineers transitioning from traditional development, and the research phase is consistently the part people skip — and the part that makes or breaks everything. The failure mode the author describes (implementations that work in isolation but break the surrounding system) is exactly what I see in workshop after workshop. Engineers prompt the LLM with "add pagination to the list endpoint" and get working code that ignores the existing query builder patterns, duplicates filtering logic, or misses the caching layer entirely. What I tell people: the research.md isn't busywork, it's your verification that the LLM actually understands the system it's about to modify. If you can't confirm the research is accurate, you have no business trusting the plan. One thing I'd add to the author's workflow: I've found it helpful to have the LLM explicitly list what it does NOT know or is uncertain about after the research phase. This surfaces blind spots before they become bugs buried three abstraction layers deep.
• ZeelRajodiya 8mo ago
  [dead]
• des429 8mo ago
  The author discovered plan mode in cursor.
• gabrieledarrigo 8mo ago
  Does anyone still write code? I use agents to iterate on one task in parallel, with an approach similar to this one: https://mitchellh.com/writing/my-ai-adoption-journey#today https://mitchellh.com/writing/my-ai-adoption-journey#today But I'm starting to have an identity crisis: am I doing it wrong, and should I use an agent to write any line of code of the product I'm working on? Have I become a dinosaur in the blink of an eye? Should I just let it go and accept that the job I was used to not only changed (which is fine), but now requires just driving the output of a machine, with no creative process at all?
  • prescriptivist 8mo ago
    Honestly? Yeah. I've been writing code for 25 years. A year ago my org brought cursor in and I was skeptical for a specific reason: it was good at breaking CI in weird ways and I keep the CI system running for my org. Constants not mapping to file names, hallucinating function names/args, etc. It was categorically sloppy. And I was annoyed that engineers weren't catching this sloppy stuff. I thought this was going to increase velocity at the expense of quality. And it kind of did. Fast forward a year and I haven't written code in a couple of weeks but I've shipped thousands LOC. I'm probably the pace setter on my team for constantly improving and experimenting with my AI flow. I speak to the computer probably half the time, maybe 75% on some days. I have multiple sessions going at all times. I review all the code Claude writes, but it's usually a one shot based on my extensive (dictated) prompts. But to your identity crisis point, things are weird. I haven't actually produced this much code in a long time. And when I hit some milestone there are some differences between now and the before days: I don't have the sense of accomplishment that I used to get but also I don't have the mental exhaustion that I would get from really working through a solution. And so what I find is I just keep going and stacking commit after commit. It's not a bad thing, but it's fundamentally different than before and I am struggling a bit with what it means. Also to be fair I had lost my pure love of coding itself, so I am in a slightly weird spot with this, too. What I do know is that throwing myself fully into it has secured my job for the foreseeable future because I'm faster than I've ever been and people look to me for guidance on how they can use these tool. I think with AI adoption the tallest trees will be cut last -- or at least I'm banking on it.
• neuronexmachina 8mo ago
  My flow is pretty similar, except I also add in these steps at the end of planning: * Review the plan for potential issues * Add context to the plan that would be helpful for an implementing agent
• foobarincaps 8mo ago
  I’ve begun using Gpt’y to iron out most of the planning phase to essentially bootstrap the conversation with Claude. I’m curious if others have done that. Sometimes I find it quite difficult to form the right question. Using Gpt’y I can explore my question and often times end up asking a completely different question. It also helps derisk hitting my usage limits with pro. I feel like I’m having richer conversations now w/ Claude but I also feel more confident in my prompts.
  • kristianp 8mo ago
    What's "gpt'y"?
    • foobarincaps 8mo ago
      ‘ji-pi-tee’, heard it jokingly pronounced like that a few times and I guess it kind of stuck.
• dabedee 8mo ago
  I appreciate the author taking the time to share his workflow even though I really dislike the way this article is written. My dislike stems from sentences like this one: "I’ve been using Claude Code as my primary development tool for approx 9 months, and the workflow I’ve settled into is radically different from what most people do with AI coding tools." There is nothing radically different in the way he's using it (quite the opposite) and the are so many people that wrote about their workflows (and which are almost exactly the same, here's just one example [1]). Apart from that, the obvious use of AI to write or edit the article makes it further indigestible: "That’s it. No magic prompts, no elaborate system instructions, no clever hacks. Just a disciplined pipeline that separates thinking from typing." [1] https://github.com/snarktank/ai-dev-tasks https://github.com/snarktank/ai-dev-tasks
  • hibikir 8mo ago
    There's no way I'd call what I do "radically different from what most people do" myself, under any circumstances. Yet in my last cross-team discussions at work, I realized that a whole lot of people were using AI in ways I'd consider either silly or mostly ineffective. We had a team boasting "we used Amazon Q to increase our projects' unit test coverage", and a principal engineer talking about how he uses Cursor as some form of advanced auto complete. So when I point claude code at a ticket, hand it readOnly access to a qa environment so it can see how the database actually looks like, chat about implementation details and then tell it to go implement the plan, running unit tests, functional tests, run linters and all, that, they look at me like I have three heads. So if you ask me, explaining reasonably easy ways to get good outcomes out of Codex or Claude Code is still necessary evangelism, at least in companies that haven't spent on tools to do things like what Stripe does. There's still quite a few people out there copying and pasting from the chat window.
    • gwerbin 8mo ago
      > We had a team boasting "we used Amazon Q to increase our projects' unit test coverage" Well are the tests good or no? Did it help the work get done faster or more thoroughly than without? > how he uses Cursor as some form of advanced auto complete Is there something wrong with that? That's literally what an LLM is, why not use it directly for that purpose instead of using the wacky indirect "run autocomplete on a conversation and accompanying script of actions" thing. Not everyone wants to be an agent jockey. I don't see what's necessarily silly or ineffective about what you described. Personally I don't find it particularly efficient to chat about and plan out all bunch of work with a robot for every task, often it's faster to just sketch out a design on a notepad and then go write code, maybe with advanced AI completion help to save keystrokes. I agree that if you want the AI to do non-trivial amounts of work, you need to chat and plan out the work and establish a good context window. What I don't agree with is your implication that any other less-sophisticated use of AI is necessarily deficient.
• vmware508 8mo ago
  How about following the test-driven approach properly? Asking Claude Code to write tests first and implement the solution after? Research -> Test Plan -> Write Tests -> Implementation Plan -> Write Implementation
• jefecoon 8mo ago
  Here's my workflow, hopefully concise enough as a reply, in case helpful to those very few who'll actually see it: Research -> Define 'Domains' -> BDD -> Domain Specs -> Overall Arch Specs / complete/consistent/gap analysis -> Spec Revision -> TDD Dev. Smaller projects this is overkill. Larger projects, imho, gain considerable value from BDD and Overall Architecture Spec complete/consistent/gap analysis... Cheers
• aabajian 8mo ago
  I'm going to offer a counterpoint suggestion. You need to watch Claude try to implement small features many times without planning to see where it is likely to fail. It will often do the same mistakes over and over (e.g. trying to SSH without opening a bastion, mangling special characters in bash shell, trying to communicate with a server that self-shuts down after 10 minutes). Once you have a sense for all the repeated failure points of your workflow, then you can add them to future plan files.
  • pk455 8mo ago
    An approach that's worked fairly well is asking Codex to summarize mistakes made in a session use the lessons learned to modify the AGENTS.md file for future agents to avoid similar errors. It also helps to audit the AGENTS.md file every once in a while to clean up/compact instructions
• QuiEgo 8mo ago
  I find a spend most of my time defining interfaces and putting comments down now (“// this function does x”). Then I tell it “implement function foo, as described in the doc comment” or “implement all functions that are TODO”. It’s pretty good at filling in a skeleton you’ve laid out.
• straydusk 8mo ago
  This got upvotes? Literally just restating basics.
• __mharrison__ 8mo ago
  This is very similar to the RECR (requirements, execute, check, repeat) framework I use and teach to my clients. One critical step that I didn't see mentioned is testing. I drive my agents with TDD and it seems to make a huge difference.
• Centigonal 8mo ago
  The idea of having the model create a plan/spec, which you then mark up with comments before execution, is a cornerstone of how the new generation of AI IDEs like Google Antigravity operate. Claude Code also has "Planning Mode" which will do this, but in my experience its "plan" sometimes includes the full source code of several files, which kind of defeats the purpose.
• snowhale 8mo ago
  [dead]
• riknos314 8mo ago
  Sounds similar to Kiro's specs.
• notjes 8mo ago
  Holy moly, I just applied the principles to DND campaign creation and I am in awe.
• deleted 8mo ago
  [deleted]
• TrailingArbutus 8mo ago
  LLMs hallucinations on macro isn't about planning and not planning like sparin9 pointed out. It's like, an architectural problem which would be fun to fix using overseeing system?
• georgecalm 8mo ago
  > This is the most expensive failure mode with AI-assisted coding, and it’s not wrong syntax or bad logic. It’s implementations that work in isolation but break the surrounding system. This is spot on. Zooming out, a perfectly written implementation that follows all the conventions but misses the mark on its business goal is as, if not more, expensive. I think adding a brief.md artifact to the beginning of the flow (where you store the problem, desired change, primary metric, feature-kill criteria) can go a long way.
• gck1 8mo ago
  Very similar to what I'm doing, but I take a more unsupervised approach, then introduce as much determinism as possible in the right layers, while cutting out as much magic as possible. One thing these sort of loops gloss over though, is that _plans change_ during implementation and I've never seen anyone talking about how they address this. With pre-generated detailed implementation plan for an entire feature or a subsystem, the model will try to stick to the plan when reality has changed during implementation. So I would advice against a detailed plan. Plan and tasks within it are only valid for a single task for a feature. When codebase, i.e. reality changes - plan has to be regenerated. The only thing that is immutable and untouchable during implementation is a high level spec.md file that lists goals and non-goals. I spend 1-2 hours specing a subsystem together in an interactive session with Opus, have it write a spec.md file, then a simple ralph loop. So it ends up: 1. Spec.md - interactive, extremely human-in-the-loop, high level objectives with acceptance criteria Loop starts: 2. Plan - opus is instructed to read all specs using subagent to get general understanding. Then read the spec that we're currently working on. It will also read codebase to see what's the current state, what are the last changes in git, and what does log.md for the spec contain. Then it has to read the previous plan.md file and REWRITE it entirely, putting the most important next task at the top. It will have to log what it has done in specname_log.md (just a few lines max, no more) 3. Build: this is basically instructed to pick the most important thing from the plan and build it. All tests, lints etc must succeed before it can commit. It also logs to specname_log.md This can loop for as long as both plan/builder iterations don't say that there's nothing to be done. And when that happens (usually after hours or days), reviewer agent steps in to do a more thorough review that everything listed in spec is done. I also maintain a directives.md file in spec dir. I always review the TUI every 30 minutes or so to check if its getting stuck somewhere or taking path I don't like. I then put a single line in directives.md: "- X is the wrong approach and must be dropped" All agents in their prompt have a line that says: "read directives.md - it contains human overrides that must be followed and they override everything". This works extremely well. But the biggest downside is that you'll hit weekly Max 20x limits in 3 days. I also advice ignoring any tooling that hides these things from you. All of this is a 300 line bash script and a few template prompt.md files that I built in a few minutes with opus, based on what I observed were the pain points. You need to be able to tweak your system in a few minutes down to the minute details. Using things like GSD, gastown, spec-kit, openclaw, etc locks you into the paradigms of people who also, don't know what we're all doing and what approach will win. In a few years, it's possible something will emerge that we all universally adopt, but right now, nobody has an idea what works.
• snigsnog 8mo ago
  [dead]
• hobrokang 8mo ago
  [dead]
• DustinKlent 8mo ago
  This is basically how "Roo Code" works. It's a VSCode extension.
• intellegix 8mo ago
  This separation of planning and execution is exactly the pattern I ended up building into an open source toolkit for Claude Code. The key insight that made autonomous loops work was giving the loop driver awareness of the CLAUDE.md file as the "plan" layer — the human edits CLAUDE.md between runs to steer the project, and the loop driver handles execution (session continuity, budget enforcement, stagnation detection, model fallback from Opus to Sonnet on consecutive timeouts). The other piece that helped was a multi-model council system — before committing to a major architectural decision, the toolkit queries GPT-4, Claude, and Gemini simultaneously through Perplexity, then synthesizes with Opus. Having three models surface their assumptions (as the top comment here describes) catches more blind spots than any single model. 194 pytest tests, MIT licensed: https://github.com/intellegix/intellegix-code-agent-toolkit https://github.com/intellegix/intellegix-code-agent-toolkit
• charlax 8mo ago
  Great article. I have a similar process, described here: https://www.dein.fr/posts/2026-01-08-write-and-checkout-the-plan https://www.dein.fr/posts/2026-01-08-write-and-checkout-the-...
• edgecasehuman 8mo ago
  Separation of planning from execution mirrors what we optimized in complex build systems: a predictable planning layer that abstracts immutables and a fast executor can dramatically improve iteration time.
• aesopturtle 8mo ago
  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.
• ianlpaterson 8mo ago
  I'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.
• leadfootdrums 8mo ago
  1000% 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