My Vibe Coding Process
How I put together real software to test with real users in a matter of days
Why Every PM Should Stop Talking About "Technical Debt" and Start Building
The lines between PM, designer, and developer are blurring fast. While your eng team debates sprint capacity, you could be shipping prototypes that validate ideas in days, not quarters.
The Stack That Actually Works for me
After spending several months vibe coding I have settled upon the following stack of tools:
Windsurf - Best Built-In Agent. Low Cost. Good automation. Calls the right tools at the right time.
Claude - Build PRDs, Requirements, Mockups and initial thoughts. Have Claude play devil's advocate to strengthen your ideas.
Claude Code - Inside of Windsurf, Claude Code makes you a superman.
Netlify - Simple Frontend rendering engine that integrates well with IDEs so that you can ship visual things quickly without the need to know anything about hosting.
Render - For more sophisticated apps that require server side functionality like databases, authentication, sophisticated business logic, data processing etc. Don't fuck with AWS if you are building to learn and test, you can always add on pieces of AWS or migrate if you have a real company.
Github - This should go without mentioning, for version control, but the best part is that you can set up your host to trigger a deploy after each code push. So you can see what you did (or you broke) relatively quickly.
VS Code/Cursor - These are the same as Windsurf, but I don't believe their built in agents work as well, in my opinion. Anything you can do in Windsurf you can do in these two so if you're used to them then feel free to continue. I learned python using cursor and started to vibe code there. I wasn't blown away until I tried Windsurf's agent.
V0 - V0 can make the shit out of a landing page, but I have not used it beyond that. I have no other comment.
Loveable is another one I hear about quite often, but I have not used it.
If you disagree with my takes on vibe coding tools, please comment.
Tools That Will Waste Your Time
Replit - this is the hot one right now, but it basically makes garbage. The UI is confusing and they are trying to both be easy and teach coding at the same time. It does great for going from a prompt to something that looks OK, but if you are planning to build real software, why not start with a real tool? No offense to Replit-heads but you know it could use some work.
The Process That Keeps You From Going Insane
Have a discussion with Claude (or your favorite AI) about your idea. Describe what you are trying to build with the AI. Ask the AI to generate a PRD and technical documentation for your project. I have a great prompt for this, that I will share in a future post.
Take the documents from your Claude discussion and paste them into the IDE you plan to use to generate your software. Create a project with just those files in it to begin.
Put your IDE into Plan Mode (Windsurf does this automatically based on context)
Have the agent review the project documents and begin the development work
Start a github repository from the folder/project in your IDE. Initialize the repository and push your project documents to the cloud repo on GitHub. Now your changes will be tracked and it will be much harder to screw everything up.
Start a new chat for each step in the plan that Claude developed. At the end of each step, remind the Agent to update the project plans and check-in the code. If you are the only person working on this then just have it push the code all the way to GitHub. If you have help, stage the change and review it with your coding buddy before pushing.
Let Windsurf's planning agent set a current goal and continuously update that goal as the llm writes code, fixes bugs and makes changes. It will check off the completed items and list the next goal so that the agent never loses its place. If your agent doesn’t do this automatically, then this is a great practice to keep each task small, and the LLM focused.
When starting a new chat, have the llm review the planning document (it should do this automatically on Windsurf) to get the context and then move on to the next step.
When Agents Go Off The Rails (And How to Rein Them In)
Testing Locally - this is still a challenge for the agents. So when you want to test your software, the agent will correctly start a local version of the environment that your software will run in. Depending on the programming language and technology used, these can do anything from nothing, to completely gum up your machine with processes. Learn the commands to kill development processes on your machine for the various languages, and encourage the agent to use virtual environments whenever possible. Render and Netlify (and I am sure other providers)have staging environments for this, which are great, but they cost money and require double setup. Tradeoffs.
Debugging: The 3-Strike Rule - When something doesn't work like you want it to, always always tell the agent the problem in as much detail as possible. Include screenshots and logs (learn where the various logs live for your particular technology stack.) Learn how to use the dev tools browser console and other features.
For each bug, you are going to start a new chat, describe the behavior and paste the logs and screenshots into the chat. ALWAYS HAVE THE LLM DIAGNOSE a root cause AND COME UP WITH A METHOD TO PROVE THAT IT IS RIGHT BEFORE CHANGING ANY CODE. So the LLM may put in debugging statements or build little tests to get functionality working and then use that to identify the bug. Then, once it proves that it is right, have the LLM give you alternatives to fix the code and you pick the solution.
This is the only way I have been able to not get it to go haywire, and it still does at times. Once you are satisfied with the root cause and the solution, then give the LLM one chance to fix the problem. If the problem still is not fixed, describe the new behavior and give it another chance. If it is still not fixed, have it go back and PROVE AGAIN its hypothesis for why the problem is failing. If it is not fixed after three attempts, have it revert the code and try the next root cause/fix method that it suggests. Don't let it keep going on its own because it will go insane and burn your whole token wad (and likely make things worse).
For example, a lot of problems can be caused by CORS or API Communications Issues. Having the LLM build a simple test program to isolate these types of communication problems to prove its hypothesis will make fixing these types of bugs much less of a headache.
Why This Matters for PMs Right Now
The old model of "write spec, throw over fence, wait for eng. estimates" is dying. PMs who can validate ideas with working prototypes will own product strategy. Those who can't will become glorified project managers.
That’s the theory anyway. I am planning to test my first vibe coded prototype with real customers in a few weeks. I fully expect it to break and embarass me, but it will give me valuable feedback that no Figma or Balsamiq every could. Plus, they can keep using it after I leave so we can understand how the product is used over time (or if they abandon it 5 seconds after I leave, which will tell us something too).
Start small, fail fast, and remember - the best prototype is one that actually works. Pick one idea from your backlog, follow this process, and build something real this week.
What are you going to build?
Want the Claude prompts I use for initial ideation? Drop a comment and I'll share them in the next post.