This started life as a Reddit post that picked up some unexpected traction. I’m putting it here so it has a permanent home, and so you can subscribe if you want the next one. — Adam

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

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

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 big for your head, it’s 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. Set up a commit-on-plan-complete habit.

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:

  • Test cases:
    • 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. 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. Wire up end-to-end checks.

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 Saturday!