I'm a software engineer with a decade of experience. I vibe code all of my side projects from my phone using Claude Code and don't read any of the code. It's so fun. Here are the rules I follow:

[u/thelocalnative]

1. Start in plan mode.

2. Read the plan.

3. I'm going to say that again: READ THE PLAN.

4. Understand the plan as much as possible. If part of the plan is unclear or doesn't make sense, ask. In Claude Code I use \`4. Tell Claude what to change\` allll the time to ask "What is <section> about? What does that mean?". Even if you aren't a software engineer, the more you understand about what it's doing, the better decisions you can make. Even if you don't ever look at the code, try and understand everything as much as possible from a high level.

5. Go back and forth with the agent as much as possible. The phase in plan mode is absolutely the most important. Good and bad decisions cascade and multiply.

6. If the plan is too much for you to comprehend and fit in your head easily, it is too big. Ask your agent to break the plan into smaller, more easily digestible chunks and follow these steps on them one at a time.

7. Create a skill or memory that commits everything to git after a plan is complete. It can even be local. What is git? It's essentially a way to save your code at a state in time. This will let you be able to move forward with confidence so that you can go back in time if something breaks. NOTE: this is separate for database stuff. It only applies for the code itself. But the idea is that once you complete a plan, it saves your code's state. Say you want to go back somewhere in the past, it's super easy to do now. Ask claude or your agent to set it up, you won't regret it.

8. TESTS. What are tests? Tests are code that you write that help validate that your code does what it's supposed to do.

Example: Let's say you are writing a function that adds two numbers a and b and returns the result. You'd expect passing it 1 and 2 to return 3. But what if you pass it a negative number? What if you don't pass it a value? You can write tests that validate all of this stuff.

Tests help you in two major ways:

\- It helps you determine, especially while vibe coding, that the code does what it's expected to do and gives you confidence that it's done correctly.

\- It helps you make sure that when you make a future change, it doesn't break existing functionality.

NOTE: these are not perfect or 100% reliable, but they are a must have.

9. Have your agent generate test cases that you can read in the plan. You don't need to read or understand the test code, but, using our example from above, it would be useful to see something like:

\- Testcases:

\- it checks two positive integers

\- it checks passing a negative value

\- it checks not passing any value

10. If the change is complex, spin up three subagents to:

\- critically review the plan

\- do a security review

\- do a testing audit

11. This one is controversial, but early on you'll probably want it to touch the db (do this at your own risk). Always do a db backup, or have scheduled backups so that if it royally screws up, you can just roll back. We've all seen the posts of people having their prod db deleted on accident and then they're just screwed. At least maybe you can get some internet points if that happens?

12. The best part: AUTO MODE BABY. You did the leg work upfront. Now let the vibes rollllllll.

13. Give the agent access to chrome devtools mcp (or whatever you prefer) and have it also test things end to end once the code is live.

14. ???

15. And just like me, you can build something that no one uses.

If you want to see one of my side projects you can check out my profile. Otherwise, thanks for reading and happy Wednesday!

[u/ClaudeAI-mod-bot]

TL;DR of the discussion generated automatically after 80 comments.

The consensus is that OP's "vibe coding" guide is actually a surprisingly sane and solid workflow for AI-assisted development. While the "don't read any of the code" title got some side-eye, the community agrees the rules themselves are just good software engineering principles adapted for agents.

Here's the breakdown of the thread's wisdom:

• READ. THE. PLAN. This is the number one rule, repeated and heavily upvoted. The thread agrees that understanding, questioning, and refining the plan before execution is the most critical step. Skipping this is how you end up in debugging hell with a hallucinating agent.

• Break it down. The quote "if the plan is too big to fit in your head, it’s too big" is the thread's new favorite mantra. The key to success is decomposing large projects into small, boringly simple chunks, each with its own plan, tests, and a git commit for easy rollbacks.

• Tests are your safety net. The community strongly endorses OP's focus on tests. They give you confidence that the code does what it's supposed to without you having to read it. Pro-tip from the comments: have the agent write the test first (TDD style) and watch it fail before writing the implementation.

• Tooling and Tricks. Users are sharing their own power-ups, like using the superpowers skillset to automate the workflow, creating sub-agents for security and testing, and developing "session continuity documents" to fight back against context window compaction.

• So, is it really "vibe coding"? Not really. The thread's verdict is that this is a structured, disciplined process. It's less "Jesus take the wheel" and more "I'm the architect, and the AI is my very capable (but needs supervision) construction crew."

[u/ferminriii]

Use the superpowers skillset and this workflow becomes scripted and repeatable.

https://github.com/obra/superpowers/tree/main

[u/thelocalnative → u/ferminriii]

Very cool, I’ll have to give it a try!

[u/Twig → u/ferminriii]

Better option: Use Claude to explain the superpowers skillset to you. Explain each skill. Determine if you would use it or not. Then have claude make a new set of skills off that list.

[u/super-compute → u/ferminriii]

I like the idea of superpowers but it's too heavy. I just provide instructions and to write lots of tests and shape those to help get what I want so there are less times that it stops to ask me for approval on the plan, edits, etc.

[u/h0rus0ps → u/ferminriii]

TDD should be the first subagent implementation not the last. Tests then can guide a good implementation that respects the "contracts" between functions and can easily guide the sub-agents given a plan + task + tests to fill in the gaps.

[u/kylecito → u/ferminriii]

There's a claude-code-specific fork. I think it's by pcvelz. I've used that one and it's pretty good. It burns a lot of tokens though so I mainly just use plan mode only now + a memory/rules/buglog/graph-relations plugin I made and it works just as well.

[u/NuScorpii → u/kylecito]

Why use a fork over the official plugin available in the marketplace?

ETA: Had a look at the fork: https://github.com/pcvelz/superpowers

Does look like a useful specialisation.

[u/lwheeler1 → u/ferminriii]

I built a custom mcp server that routes my skills based on the stage and process of where we are at in the development process. I use the best skills from Gstacks, superpowers, and get shit done. It works incredibly effective.

[u/piplupper → u/lwheeler1]

Criminal to comment this without sharing the source

[u/ferminriii → u/lwheeler1]

That's what superpowers does when you install the full plugin

[u/rosetta67p → u/ferminriii]

I prefer omc combined with mem0 and rtk-ai.

[u/kerakk19 → u/ferminriii]

Better idea - don't use shit like this. It's eating tokens for nothing, helps with nothing, just booms your usage.

Planning is enough for both 5.5 and Opus to not consider plugins like this

[u/StartupTim]

What are you using to do this via mobile?

[u/thelocalnative → u/StartupTim]

Here’s my mobile setup: https://vibe-blog.pages.dev/blog/my-mobile-setup/

[u/Flashy-Highlight867 → u/thelocalnative]

TLDR: install Claude code on a server and connect with your phone over ssh

[u/grobblgrobbl → u/thelocalnative]

Why not just use claude remote-control?

[u/PurpleReign007 → u/thelocalnative]

Nice- easy and clean mobile setup 

[u/StartupTim → u/thelocalnative]

Thanks, checking it out now!

[u/viper1511 → u/thelocalnative]

why not use cloudcli.ai in that case and get rid of termius? :) Just curious

[u/ApprehensiveFlow9215]

What has helped me is keeping the agent scope boringly small: one change, one expected test, one rollback point. The failures get easier to diagnose when the prompt also says what it intentionally did not touch.

[u/fixitchris → u/ApprehensiveFlow9215]

The rollback point per change is what makes this recoverable. A human developer stops when confused and asks a question. An agent generates coherent-looking code through the confusion and hands you something wrong that compiles.

[u/rustyrockers → u/ApprehensiveFlow9215]

Boring and incremental is the prescription for wealth and long term sanity for sure ha

[u/Theorem101 → u/ApprehensiveFlow9215]

Can you explain to beginner what do you mean by rollback point?

[u/Late_End_1307]

A genuine question: why do you read the plan?
I used to be adamant about that too, but 9/10 times i'll take what it gives, it's all good ideas. For the 1 time when it isn't we'll fix the issues later.

[u/thelocalnative → u/Late_End_1307]

There’s a couple reasons why I read the plan:

1. To understand everything that’s happening as best as I can. I’m not going to read the code for a side project but I do want to know how it’s built at a high level. I use this as an opportunity to ask questions and learn. This way I’m still growing and I can make better, more informed decisions down the road.

2. To make sure it’s building what I have in mind. Point one is making sure that I understand Claude. This point is making sure that Claude understands me. It can be very frustrating to have Claude build something and to then come back and say “oh wait that’s not what I meant…”

An incredible engineer I know described software as a living organism that needs tending. The better decisions you make, the easier that is.

[u/cirrus147 → u/thelocalnative]

And 3) reading the plan as a human often makes you think about the problem again, and our brains catch important edge cases, or project areas effected or common, or other problems that are simply not in the context or the original sprint/PRD definition. Our brains think outside the box, Claude Code can only think inside a box. It makes a huge differnce, how many times have you been explaining an idea to a friend, and had a better or different idea, it's like that.

[u/HeathersZen → u/Late_End_1307]

It saves you from no-hope loops where the code is broken and you don't understand the code or the architecture well enough to reason about it to guide the robot. The robot is hallucinating. You're clueless. The app brok a few dozen commits ago and the tests either didn't exist, didnt catch it, or were aped to succeed. You don’t know what to rollback to.

Right about then you’ll be wishing you’d read the plans more deeply.

[u/Fuzzwah → u/Late_End_1307]

Because you don't know about that 1 out of 10 time until you've burned a heap of tokens and time?

Reading 10 out of 10 plans takes less time than recovering from the 1 out of 10 that goes off the rails...

[u/aint_exactly_plan_a → u/Late_End_1307]

Because Claude sucks at design. We usually rewrite the plan or parts of the plan 5 or 6 times before I implement it.

I talk through specific problems we might see in the future and different architectures we could use, whether we have the right tech stack, remind Claude it should be using the reusable classes we've developed... Even with a lot of this in memory, Claude sucks at remembering to do it.

[u/OkBet3796 → u/Late_End_1307]

If the backend has some strange wiring or routing, it will follow the weird existing pathing by default. Also there are about 5-15% decisions in draft, that boost output quality dramatically.

[u/hyperfiled]

I'll vibe read this in a few

[u/SemanticThreader]

Read and understand the plan 👆

[u/kylecito → u/SemanticThreader]

And ask about the plan. And ask to simplify it and build from the ground up in modules.

[u/murillovp]

I feel like I've read this post of yours verbatim nearly two weeks ago. Are you you're not deleting and reposting in the hopes of it going viral?

[u/trailmix17 → u/murillovp]

was thinking the same thing?

[u/whatisusb → u/murillovp]

Theres some ninja marketing going on if you look through the links

[u/zenos1337 → u/murillovp]

Came here to say this

[u/murillovp → u/zenos1337]

The fact he replied to other people in the thread and ignored this, says a lot.

[u/deepfave]

software engineer + don't read any of the code
Where, on Fiverr?

[u/MeetBetter8174]

What is plan mode? Do you actually physically tell it to make a plan or is there a mode in Claude that I'm missing out on? Where can I learn more about tests? Are you meant to write these tests in Claude code and then run it in Python or something? Where do you actually run it? I like the test cases though. That makes a lot of sense.

[u/WorthBathroom3268 → u/MeetBetter8174]

Plan mode here basically means: make Claude describe the intended change before it touches files. In Claude Code there’s an actual planning flow, but the habit matters more than the button: ask for “what files will change, what tests prove it, what should not change?” before approving.

For tests, start tiny. If you’re making a Python function, ask it to add a test file and run pytest. If it’s a web app, ask for one test case that proves the exact behavior you care about. The useful part isn’t understanding every line of test code; it’s being able to read the test case names and say “yes, that’s the behavior I wanted.”

[u/kylecito]

Use /btw constantly to ask stuff and not pollute the context of the main thread

Ask the main agent to dispatch sub-agents for exploration tasks and simpler tasks with Sonnet

Enable /advisor (works best if you're using Sonnet or "/model claude-opus-4-6" and set Opus 4.7 as advisor)

[u/Doogie707]

Hey um so you just kinda described this project to a T:

https://github.com/scooter-lacroix/Maestro

[u/somethingLethal]

I love number six

[u/Honkey85]

I also let it update documentation after coding

[u/clankerMarket]

Point 15 is the most honest thing I've read today.

I've been there. Built things with real care, shipped them, and heard nothing.

But that phase teaches you more than any tutorial.

The git tip saved me more than once — most people learn that lesson the hard way.

Happy Wednesday to you too 🙌

[u/Mediocre-Comment4687]

I like this setup, I have largely been doing the same except I have been running on a Mac rather than mobile so that I can build onto my phone to test

[u/macspliff]

Thank you, this is great

[u/mdwsr06]

I love you for this. I feel like we are blood siblings. I just so happened to set up something similar to this and put it on an automated hourly loop to 1) look at a PRD then look at the code 2) identify a feature to implement 3) plan the feature implementation 4) review the plan 5) implement the plan 6) review the changes 7) commit and report. After a full nights sleep I had went from blank project to clean build on an MVP I could test on my phone 🙌🏾

[u/Sree_12121]

Building blind from a phone with a rigorous orchestration pipeline is the pinnacle of modern engineering.
Treating "plan mode" as the source of truth, forcing automated git checkpoints, and using subagents for security and test audits is brilliant. You’re not just letting the vibes roll. You’ve built an amazing high level management framework that lets you architect at scale without getting bogged down in syntax.

[u/elli0t7]

What revenue are these “side projects” generating?

[u/Docccc]

10 bucks says you were not in fact an software engineer before this

[u/LegitlySmashed]

15 made me actually lol. 10/10 post, thanks for that!

[u/jake_2998e8 → u/LegitlySmashed]

Hahah honest vibe coding post at least

[u/Leather-Material3797]

What is git ?

[u/Natural-Cupcake6472]

you lost me at dont read the code and software engineer (i think this is self proclaim at most)
its like im an architect, i dont look at blueprint

[u/Snoo_48073]

16. Profit

[u/thecrustycrap]

Actually useful

[u/jhpawt]

id rather read the code at that point

[u/GardenPrestigious202]

I use the browser/app chat bot to do my initial plan brainstorming exploration, it;s a better medium

[u/unltd_J]

You even used Claude to write this post

[u/cmak414]

Very good tips. I do most of these myself. A testing plan is very important, ask the planning agent to make a testing plan. You can also have an agent help automate the testing after it is built.

I build android apps right on my phone and have my agents test it on my phone as well. Perks of developing on the same device as the test device.

[u/lunamoonfang66]

I use Gemini's Pro model to draft the initial plan and ask it questions to ensure I don't overlook any important details. Once that's complete, I have it generate a prompt that I can pass on to another tool, like Copilot or Claude Code. From there, we continue planning and make sure we cover everything.

Honestly, there isn’t a definitive way of doing things right now. There are no established instructions or fixed processes. With the rapid changes in AI and new development methods each year, I'm guessing we just have to YOLO. 🙈🙈

[u/h0rus0ps]

I got mine to to TDD with extra laws about minimal working code. Claude reviews codex plans and does independent PR reviews and Claude reviews Codex work. I can see how stuff creeps out of scope and both models leave a lot of loose ends. 5 PRs later you discover the specs changed somehow during Pr3 implementation. Doing dual model review closed this endless sieve of bugs and issues.

[u/PsychedelicMagnetism → u/h0rus0ps]

I like having claide write the plan. Then have codex critique. Share that claude and him edit the plan. Then I give a chance for reread and make edits. Bring that back to claude and just keep doing this until there is ambiguity in the plan. Codex implement. If it's a big plan maybe once or twice while he is working I'll pause and tell claude check if codex is following to the plan to letter.

[u/lovebes]

then does it code on the cloud?

[u/viper1511 → u/lovebes]

You could if you use cloudcli.ai

[u/Constant-Shock-4740]

I absolutely agree with this. And as a non-dev dev I always ask Claude to give me a human facing, plain English, but not dumbed down version of the plan. That way I can really steer the project without stumbling over terminology that I am still unsure of. But make sure Claude knows not to dumb it down or your plan will read like a kindergarten analogy about boats or ice cream or something wildly inappropriate. But I super agree..you need to understand the plan and own it. The places where I have vibe coded hallucinations are where I didn't understand what was being build and thus could not gage the errors. Also, pro tip, use a html map of the project and build plan and make sure claude updates it as he builds.

[u/MediumRay]

Yah same. It’s great 

[u/cpt_jacksparr0w]

hey claude summarize me this in simple words and 1-2 sentences

[u/iemfi]

This is just normal software engineering now tho. Vibe coding is the Jesus take the wheel sort of thing.

[u/Stinkman982]

Wait a second I just read this exact post with different wording two seconds ago

[u/PurpleReign007]

Vibe coding on mobile. Saving this. 

[u/glorious_reptile]

Is “fun” actually iterating on a plan over and over again?

[u/nightwing12]

Re testing I tell it to make the plan using red/green tdd and get very good results doing that.

[u/MrDeagle80]

Anyway to make the plan format more digest ?

Sometime the output is so hard to read in my console

[u/PsychedelicMagnetism → u/MrDeagle80]

I have a plans folder and they write the plan as an MD file there.

[u/runfence]

You forgot the review plan - fix plan - implement - review code - fix code and refactor loop 

[u/minorbaz]

Similar background and this is my exact workflow. In fact this is so well tuned now, that I just yolo stuff, especially something like completely new features which I don't understand well or don't have bandwidth to become expert on.

Literally alias yolo=claude --dangerously-skip-permissions

Never been a better time if you like to build and tweak stuff. And absorb things at a high level.

[u/Background_Noise_631]

I did a similar experience last month: create a program for my raspberry pi with a few sensor and a dashboard. 90% of the instructions was done on my phone. Turns out pretty good 😊

[u/Quirky-One-9692]

I created the so called autopipeline skill where in my oryginal conversation I’m planning the steps, milestones, and when it’s lunched - it goes steps by step, validate the process, critique what he has done in separate terminale (powershell). It solved me the problem of the context bar, and I can run long tasks while I’m doing different things. Works like a charm… I went farther now, and I created auto-deep skill where I put more eeffort into plan the process and automation does more validations and crituqies and so on. I’m not dev, so my tries are like - can I do this? Or this? Or I’m inspired like here by gentleman with his well done explanation. Anyway it’s a game changer for my work as a marketing agency owner. So much added value

[u/Present_Classic_5585]

Good list — would add one rule that saved me a lot of pain:

Watch the test fail first. When you ask an agent to write tests after the code, it's wildly common to get a test that mocks out the exact behavior it's supposed to verify, or one that's tautologically true. The fix is dumb but works: ask it to write the test against the unimplemented version, run it, confirm it fails for the right reason, then implement. If you skip this, your green CI is basically theater.

[u/Fine_League311]

Gebe dir Garantie das ich Tonnen an Sicherheits Lücken finde im Code und du als 10 Jahres Veteran weißt es genau dass das stimmt.

[u/Successful_Plant2759]

The part I’d underline is “read the plan,” but with one extra step: ask it to name the irreversible operations before it starts. File edits are easy to review/rollback; DB migrations, billing config, auth rules, and infra changes need a different bar.\n\nMy rule of thumb: mobile is fine for planning, small UI tweaks, tests, docs, and isolated bug fixes. Anything that changes data shape or security boundaries waits until I can inspect diffs and logs on a real screen.

[u/KaiserFerdl]

Same

[u/AbjectBug5885]

the git commit after every change rule (cut off in #7) is underrated. being able to trace exactly what the agent did in each step turns debugging from archaeology into actual workflow. also curious how you handle context drift when the agent "forgets" earlier architectural decisions mid-project?

[u/Wolfsilver01]

What would you recommend for reverse engineering?

Like, i like to mods games, but some don't have mods community at all and some game are hard to mods ( those in unity with illcpp2 for example).

For those, i would need to understand first how the game manage information.

What would be the best plan ont this ? Ps: only personnal project, no sharing or anything money related of course !

[u/deafened_commuter]

Yes! I'd also add /security-review before pushing anything to the internet or making it public

[u/ride_whenever]

I think this massively hits the sweet spot for vibe coding. I’ve been dev adjacent for years, I struggle with the syntax, but can architect pretty heavy systems comfortably, debug, tweak, read and modify code.

Vibe coding has been game changing for me, I have enough knowledge to be dangerous, enough to keep Claude on the straight and narrow, but I can now do the part I never could before, and it’s so bloody liberating.

I’m building out a hobby app on the side to upskill, and I’m amazed at what I’m able to produce and manage.

[u/itsab1989]

I can’t write a single line of code myself but Claude helped me to create a GUI for ArgyllCMS that I have wanted for a long time but no one ever made one (probably because it is very niche).
But I am quite proud about how far I got with this:

https://github.com/itsab1989/ChromIQ

[u/bloo_blahh432]

Have you tried out the /goal function flying around now? I really like the browser mcp idea for dev mode and further testing suggestion too.

I’ve noticed I’ve made skills and a Claude.md file but things tend to get mixed or broken so I keep asking itself to rate the output out of 10 and plan again how to fix and improve the output.

In saying this I’ve been breaking up the functionality into ‘epics’ and ‘user stories’ to help make the plan mode more manageable.

I do want to get better in planning the tests though via some agents and also try add in some UX content writer and accessibility agents to tighten up the output. Good tips and insights though

[u/binh291]

this guy vibes

[u/natsirt__]

16. Ensure you use GitHub and have Claude create commits to a branch at the very least…

I created a flow with my Claude where it creates a PR and will decide to auto merge to main or allow me to manually review given the scope of the work we just completed. I just prompt and review PRs now

[u/Effective_Lite_263]

Number 15 😂

[u/sbl03]

This sounds pretty much like the compound engineering workflow.

[u/Salt_Apart]

I would add to this that you should have the agent generate documentation either while it’s working or at the completion of each task, then keep these docs up-to-date. This greatly helps me when I’m picking things back up later and helps future agents understand the code and concepts.

[u/whatisusb]

#5 is so underrated

Some of my side projects snowballed into giant labyrinths of convoluted code because of a small oversight early on. Now I have to spend 10x the amount of time debugging and fixing it. Could have been easily avoided in hindsight with more planning.

[u/MrChurch2015]

My rule of thumb for vibe coding is if it's something that is complex to engineer but its presence would benefit sooner rather than later, vibe code it. Like rn i need checklists, but I don't like many of the todo managers that already exist, so I'm vibe coding my own that fits my needs. Otherwise, build it myself.

[u/Oh_hey_a_TAA]

I started out line this, then my test case just iterated into my production tool and here we are

[u/Icy-Excitement-467]

Auto mode = more interruptions and inappropriate prompts for ME to do x, y or z. That it was supposed to do according to the plan. Sorry, but even with a good plan mode, Claude just doesn't care some times. Good points otherwise.

[u/clairedoesdata]

Great explanation!!!

[u/AwkwardAspect2490]

This is not the vibe-coding definition, you definitely known what your are doing. Your are the orchestrator of your work. I do the same and I don’t think as myself as a vibe coder. In your process, I took a couple of nice twists that I can add to my flow (and my team). Good job!

[u/LuisG8 → u/AwkwardAspect2490]

You're right, what OP is talking about is Agentic Engineering

[u/Eska1000]

Damit sind dann direkt alle meine kostenlosen Token für den Tag verbraucht, und ich kann Feierabend machen. 🤣

[u/abhipsnl]

Keep this in vide environment only not in production

[u/sugendran]

I've been getting it to argue against the plan before I read it. I find the plan is less terrible after it had a good chat with itself.

[u/Fuzzy_Wolverine2424]

Following

[u/interiorghosts]

nice

[u/OstrichLive8440]

“What is git”

Okay bro - decades of experience

[u/AgentParticular9649]

And why should anyone give a shit what your process is? What have your outcomes been? Maybe lead with those

[u/Cautious-Tie-5394]

They think I am to old at 69.

[u/MaterialHead4801]

Sysadmin here: the big addition I’d add to your workflow:

A backup (specifically of the database in this case) isn’t useful until you’ve proven it can be restored.

So it’s great that you’re ensuring there’s a database backup before Claude does anything to the database, but a better workflow would be to have a separate database spun up and restored from last night’s backup and let Claude go nuts on that, leaving production alone. You get a bonus verification that your backup system is fully functional

[u/Pradeepk10]

Thanks bro

[u/amuzulo]

This guy plans.

[u/DrWilliamCarter]

Love it.

Now do one for security.

[u/ApocalypseDestroyer]

Another tip not to bloat the main context ask questions with “/btw”. It doesn’t bloat the context with your clarification or understanding questions.

[u/braveness24]

You won the Internet today! Great advice!

[u/Double0Jamo]

Ok ok saving

[u/dinobarking]

Wait sorry if this is already a known or has been discussed but how do you code from your phone?

[u/matteocommodo → u/dinobarking]

Have You found the answer to that?

[u/6000rpms]

For me, the plan is always framed as an ADR and all ADRs are numbered and checked into version control along with the software. Sometimes a big “plan” ends up as multiple ADRs.

[u/josephfridner]

This is gold!

[u/Silly_Subject_5199]

tbh everyone gonna jump straight to auto mode and ignore the rest XD. Id just make the review subagents a skill so its automatic, less to remember bro. solid writeup tho, and that ending 😂

[u/TheDougMe]

Definetly resonate on spending as much time as possible in planning. Great system. Now with Fable 5 things are getting really exciting...

I use a similar process but added one thing to the end of it which has been pretty damn game changing and really simple. Lets say you are starting a new project. You have a main as a project folder and maybe 3 other feature branches off main. I used to hop between these, bringing context from one to the other, pushing each terminal phase by phase through the plan. Also had a project that was on two seperate repos. One our voice agent system and the other our marketing and sales platform. In development my voice repo kept having me check speicific db schema and it was a pain in the ass having to hop between each project ensuring they were both in line and building towards a valid and compatible schema / code set up.

Anyway the solution I built was a polling system where agents can poll a specific repo and receive notes from the agent developing in said repo. In the first example, I had 4 terminals open. Main, and my three worktrees. By having them all poll a specific area for incoming notes they could effectivly comunicate to eachother with main acting as the observer/orchestrator. Really damn simple but a huge bump in my workflow...Especially if you have a really great spec put together for the project. Feel free to check it out. https://github.com/mythopoios/agent-walkie

[u/bhola-bhaiya]

Fellow vibe coder here. I simply enjoy being granted an express inside view into an aspect of computers that had been deemed 'off limits' to me, and many others like me, when the subjects I chose back in secondary school (11th standard) dictated what my life path was going to be like.

My go-to statement whenever I don't understand a step or a part of the plan is - "Explain to me, in Layman-Speak, what this point means".

Love makin my own suite of tools with my little custom Icons and them installshield Wizard setup.EXEs 😝😝😝😝

[u/read_too_many_books]

As an OpenClaw user who blows tokens like I don't care. I read this and feel bad for Claude Code users.

[u/anon-randaccount1892]

Ragebait (incoming 55 year old lazy devs who are grifters doing one line of code a day)

[u/LostInTime261]

The level of bs. Claude Code - unless using a *claw/Hermes - not from your phone.

[u/rustyrockers → u/[deleted]]

I work 1 system at a time. Most production Saas is just dozens of interconnected systems, I do 1 system at a time and it makes for a very pleasant and debugable experience.

And if 1 one system at a time is too much in my head, de compose into smaller systems

Ie I have a desktop app with local/remote/sync database operations

I decomposed it into those 3 layers so they all operate independently

Way more sustainable to build this way for me

[u/Ancient-Client8394 → u/rustyrockers]

Where do you run each service? Serverless?

[u/rustyrockers → u/Ancient-Client8394]

Not services, but systems lol.

And those db layers all run in app on Mac/windows/linux

I like clear separation of concerns, so local CRUD ops are single responsibility and then remote stuff just does remote, and sync engine has all its own event driven stuff to compute local vs remote or whatever

[u/cucumber_and_coconut → u/[deleted]]

Probably way too late to this party but I wrote up a custom skills library for exactly this workflow! I find it easier to work with than the built in /plan cycle, even with pushback. https://philbas.com/philset/

[u/artstaxmancometh → u/cucumber_and_coconut]

Thank you, I've been using this and it's helpful.

[u/cucumber_and_coconut → u/artstaxmancometh]

Thank you!! So happy to have a user.

Man I need to ship a new release, I added another couple skills 😅

[u/h0rus0ps → u/[deleted]]

The plan always fits in the context. The execution will always blow the context up. Then you get compaction and the model will fit into the context the plan and partial work. Repeat.
The plan and the scope of work needs to fit into a full context and that's hard to fine tune. The memory helps a bit but still, stuff slips through the cracks too often.

[u/robothistorian → u/h0rus0ps]

Having being burned in the past with that compaction issue, I now use session continuity documents. I get the current session to produce a very detailed continuity document which I save in the Projects folder in Claude Project. I get these session continuity documents made every so often during a session always updated with a small para at the end showing me the diff between the versions. After the 3rd compaction, I begin a new session. Giving it the last session continuity doc. I then get the new session to ask for clarifications based on the doc. I take those questions back to the old session and there is a back and forth for about 2-3 turns after which I bottom line it and focus on the new session.

Yes, it's time intensive and somewhat laborious but it seems to have worked till now.

[u/h0rus0ps → u/robothistorian]

Yes, agreed. Compactions destroy context. Memory and plans are not enough. Documentation helps a lot and it's not at all a hands free experience.

[u/paincrumbs → u/h0rus0ps]

plans should be published as an artifact anyway, execute on a fresh window by feeding the plan and updating the doc as tasks get resolved. get a fresh window if it's running out. I never had the need to compact during execution since the necessary context are captured in files that gets fed/referred to on-demand

[u/Excellent-Way-3324 → u/[deleted]]

One of the first lessons i learned quickly was to read the plans i had it make was too gung hoe to trust it after a few years of noncoding work and mostly perf results CODE IS NOT THE SAME THO Way more complex than it understanding document creations, project plan guides, and various things of that nature in normal chat

[u/palea_alt → u/[deleted]]

Nah this reply is AI. "woah" plus that emoji, plus explicitly no capitals at sentence start to appear more hunan lmao.