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:
Start in plan mode.
Read the plan.
I'm going to say that again: READ THE PLAN.
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.
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.
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.
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.
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.
- 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
- If the change is complex, spin up three subagents to:
\- critically review the plan
\- do a security review
\- do a testing audit
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?
The best part: AUTO MODE BABY. You did the leg work upfront. Now let the vibes rollllllll.
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.
???
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!