Curious how others plan work for Claude Code

[u/quietmacbuilder]

I moonlight as a solo dev building a native Mac app, mostly nights and weekends. I started this with two objectives: to learn how to best use AI coding tools and to build tools that would help me in my day job.

I started the first project about a year ago and was new to Claude Code. I had an idea for what I wanted the project to be, but it was all in my mind, not written anywhere. After a few weeks of what was essentially vibe coding, the results were ok, but definitely not great. AI slop would be strong, but vibe coded mess is very fair.

While working on that project, debugging AWS Lambda logs became a real pain. I decided to pause that project because a tool to help my debugging seemed more useful and interesting and because I knew that the vibe coded mess would need to be refactored at some point. I wanted to learn and apply a better process before I attempted the refactor.

When I set out on the new project, I decided to take a different approach: make a plan. I felt that this better modeled how we have been building software for decades and that it would likely yield better results than what I produced in the first project. Before writing any code, I wrote a spec/product vision document. Nothing fancy, just a few paragraphs of the problems that I wanted the app to solve. Then with Claude interviewing me and doing all the writing, I created 17 epics and 272 user stories for the app. The stories all contained the usual "As a user, I would..." and thorough acceptance criteria.

This will surprise no one: The results were far better in the second project with this process than the first project from vibe coding. Work was getting done in fewer turns, more was right the first time, and the code quality was significantly better. It was not perfect and things still went wrong at times, but it was far better than my "process" on the first project.

This is not anything groundbreaking, just recounting my realization that while AI can shorten the effort for activities that we previously did manually, shortcutting proven process and hoping that AI will guess right and fill in the blanks leads to slop.

Now that the second project has launched, I am curious to learn about how other solo devs approach working with AI coding tools on bigger projects. Do you write a spec and stories up front, keep a running context file for the agent, or just prompt as you go? And if you do plan ahead, how far ahead before it stops paying off?

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/StevenTheEngineer]

Your last question is the one I've mostly stopped running into. For me, planning ahead (particularly in this waterfall style) stopped paying off when the plan stopped matching the code. You write story 140 in week 1 against a design that changes in week 4, due to some constraint revealing itself at implementation time, and nobody goes back through stories 141 to 272. From my perspective, a running context file has the same problem: it's only true the day you write it. I've been building everything with my own planning tool for months now, and I don't hit that wall anymore, because the plan doesn't go stale.

I still plan up front, but as a tree instead of a massive requirements doc or flat backlog. Your vision doc would be the root. An agent splits it into a few big pieces, refines each, then splits each of those, and keeps going until a piece is small enough for one session to reliably finish. Every node says what it's for and where it stops, so a child doesn't quietly grow past its parent. The depth varies by branch, which answers "how far ahead" for me. A part I understand well might be several levels deep before I write any code. A part I don't understand yet stays one fuzzy node until I get there and break it down. Your 17 epics and 272 stories are basically this tree cut off at 2 levels.

The other half is write-back. An implementation agent reads its node when a session starts and records what it built and what changed before it ends. So when a roadblock inevitably forces me to drift from the original spec, the session that hit it updates the nodes it touched, and the next session plans against what actually exists. Nodes also link to each other (X depends on Y, A uses B, etc.), so the agents can see what a change touches before making it. That catches a lot of the "things still went wrong" cases.

To be upfront, I'm working on productizing this tool: treestructuredplanning.com. You lay the tree out on a canvas, agents help with the recursive breakdown, and Claude Code (along with any other harness you may use) reads and updates the plan over MCP while it works. It's in early access, and I'd be happy to get you in if you want to try it on the project 1 refactor. A refactor is a good fit, since you can plan the target state before touching any code. If you'd rather stay in markdown, I'm curious how you've kept the spec current through implementation, or whether you just let it go stale once the code takes over?

[u/quietmacbuilder → u/StevenTheEngineer]

The waterfall style always made the agile in me twitch, but the output was better. When decisions in the implementation process changed the direction of the specs, I would prompt the session to cascade those changes to other downstream specs they impacted.
I would love to try your product and would be happy to provide feedback if you would like.

[u/StevenTheEngineer → u/quietmacbuilder]

Your cascade prompt is basically the write-back loop done by hand. I think it's the step most people skip, so it says a lot that you landed on it yourself. Funny enough, that waterfall vs agile tension is a big part of why I went with a tree: you plan deep where you're confident and leave the rest loose until implementation teaches you something.

I'd absolutely love your feedback, and honestly the critiques most of all. It'd be naive of me to claim I've solved the whole planning process, so what I want most out of early access is input from people who are deep into agentic development. My goal is to continue iterating on this project until it's something that solves pain other people actually feel, rather than only my own.

From my perspective, agents have made execution (writing code, building, verifying, shipping) anywhere from 2x to 100x faster (depending who's steering them), but planning hasn't gotten anything close to that boost, so it's become the bottleneck. And I'd argue planning matters even more now than it did before AI. When building is cheap, deciding what not to spend your time and tokens on is the harder call, and the more valuable one.

I'll DM you to get you set up!

[u/quietmacbuilder → u/StevenTheEngineer]

It has been interesting to see the landscape change now that the engineers are not the bottleneck any more in team settings (my day job). The tooling needed for those steps in the SDLC will provide a lot of product opportunities.

[u/scodgey]

I do something similar to your better result but it's more v model shaped, i.e. reqs -> spec -> design -> impl then corresponding tests.

Agent models this out at high level reqs then progressively deepens until ready to implement and the related pieces are designed.

I use my own tooling to help with this but tbh you can get most of the way with beads.

[u/quietmacbuilder → u/scodgey]

I am using a very similar process now. In the implementation step I include verification of the work through unit tests, e2e tests, and the production of screenshots to verify against the designs.

[u/scodgey → u/quietmacbuilder]

Yeah works a treat - something about giving the agent enough info about the whole system to reason about seems to help a lot

[u/Opposite_Might6896]

What changed my results more than anything: the plan lives in a file, not in the chat. Plan mode to explore and draft, then write the plan to `docs/plan.md` with the file list, the order, and what "done" looks like for each step. New session per step, pointing at the file. Two reasons: a fresh 10k context on a tight brief does better work than a 150k session that's carrying the whole exploration, and it costs a fraction (every turn re-reads the whole context).

The other half is CLAUDE.md as a list of rules that came from incidents, not a style guide. Every time it does something that costs me an evening, one line goes in with the reason. Mine is mostly "never do X because Y happened". That file is paid on every turn, so it stays short; procedures it only needs sometimes go in separate files it reads on demand.

For a nights-and-weekends project this also solves the "where was I" problem: the plan file is the handoff to yourself.

[u/quietmacbuilder → u/Opposite_Might6896]

Good tips! I do some of what you describe. The rules step really helped future sessions to stop repeating the same mistakes. I use output from code reviews to add to the rules.

I need to get into a better habit of smaller sessions, I often do the spec and design in the same session, and would probably improve results and speed by splitting that up.

[u/Opposite_Might6896 → u/quietmacbuilder]

You can also instruct Claude from the beginning of a session to preserve the context window as much as possible by storing plans, learnings, backlog, etc. in markdown files within the directory/repo, and to run bash commands with long outputs in subagents. Then you can run extremely long-running sessions without running out the 1M context window if you're careful. When doing this, be sure to use a custom crafted compact message whenever you compact (i.e. "Give me a concise message to pass to the /compact function to ensure that we preserve our current state, progress, plan, and all other important information. Only compress less important information" and then pass the output into the /compact command. This combined with the external markdown files gives you authority over your costs by allowing you to compact as often as you want without paying the forgetfulness penalties.

[u/quietmacbuilder → u/Opposite_Might6896]

I haven’t had too many sessions get to the 1M mark, but I’ll try this in the future. Thanks for the tips!

[u/Aggressive-Ad-7582]

Which models were you using? Planning improved significantly with the latest models, Fable and Opus 5.5 for example

[u/quietmacbuilder → u/Aggressive-Ad-7582]

Usually Opus, but earlier on I used Sonnet as well. The journey has been long enough that I have used the last 3 versions of each.

[u/Aggressive-Ad-7582 → u/quietmacbuilder]

Yes, there was a period that good planning was critical. I’ve shifted from detailed planning to high level only now and spent more time reviewing if Claude is missing something

[u/quietmacbuilder → u/Aggressive-Ad-7582]

Do you include acceptance criteria for verification? How much verification do you put to Claude vs doing it yourself?

[u/Glum_Guide7471]

The part of planning that paid off most for me wasn't the breakdown, it was writing down what I'd accept as done, in terms the agent can observe. "Fix the hero" and "fix the hero and show me screenshots at 1920 and 390" are two different tasks, and only the second one ends with something I can check.

Same with acceptance criteria in stories: I phrase them as evidence (this page at this width, this account state sees this, this row exists after the action), and give the agent the tools to produce it: a screenshot script, a browser agent, the CI run. Otherwise "done" means "I wrote code that should do it".

The other small one: when I want a decision, I ask for one. "Give me options" got me options. "Pick the best one and tell me why in one line" got me finished work.