Vibe Coding: Enter the PRDs

The promise of AI is a product manager's dream - build an MVP in hours. But what happens when the magic runs out?

When I started vibe coding, I did so with an open mind and threw out my product best practices rulebook to see if AI was indeed magic. AI is very impressive, but not the magic some would lead you to believe. Best practices for product development still apply; it's still a lot of work, and PRDs (Product Requirements Documents) are still an important part of building a product properly.

While vibe coding is a powerful prototyping tool, traditional product development practices like PRDs are essential for scaling a viable, long-term product beyond the Spaghetti Code Limit.

The Spaghetti Code Limit (SCL) of Vibe Coding

Spaghetti Code Limit (SCL) - The limit of how far you can take a product with vibe coding alone, beyond which the product becomes unviable.

To be clear, I am extraordinarily impressed by my experience. What would normally take weeks can be done in hours. However, even with advanced models like Claude Opus 4.5, I've danced on the edge of the spaghetti code limit and had to work hard to pull it back from the brink with deep review from my AI Agents and very thoughtful prompting. Even with that, it feels like the gravity of the SCL is close at hand.

NOTE: I made up the term SCL, but it is a real thing.

Adding Agents - simulating a real dev team - is an example of product development best practices. We're now at the point where, to push the SCL, I'm going to increasingly deploy product development best practices and see how far we can get.

The next challenge is to replace tacking on features with implementing functionality in a more coherent way.

Tacking on Features v. the Big Picture

I started Burrow the way I believe most people start vibe coding: I entered some basic ideas, got a result, and iterated features with additional prompts. In this process, Replit with Claude Opus 4.5 made assumptions about areas I didn't explicitly specify. Those assumptions were significantly better than when I started using Replit with Claude Sonnet 3.5 seven months ago, but they still led to some messy logic.

The other problem with this approach is that developing features one by one is a more microscopic view of a product, and the code reflects that. Taking a step back and viewing feature and functionality blocks as a whole can help extend feature blocks in context, rather than tacking on disparate functionality. PRDs are how traditional product development captures that larger picture.

Adding PRDs to Vibe Coding

Recently, we got to what I believe is an MVP for Burrow, but we had also reached the SCL. I could tell because it was getting difficult to add new features without other things breaking... I found myself in loops of logic, having to rollback from GitHub and try over and over again.

So, I prompted Replit to create PRDs for several key functional blocks (e.g., search, filter, and mapping features). Documenting what had been implemented compared to what was intended helped me identify discrepancies and fix some of the issues I was seeing. The issues fell into two categories: incorrect assumptions and missing concepts.

I also saw some clever tactics in the documentation (that Replit had implemented) that I hadn't considered, which made it easier for me to prompt for extensions of these logic blocks.

Now, as part of new features, I can reference the appropriate PRD in prompts to pull the bigger picture into context, and it seems to have improved code quality by incorporating a more holistic approach. The SCL has been pushed a little bit further out.

What comes first, the PRD or the Vibe Coding?

I don't know.

Traditionally, a PRD would always come first, but one of the undeniable benefits of vibe coding is that it lets you rapidly prototype and better understand if there is a real idea there. Maybe it's better to play around and add the PRD as soon as you see functional blocks that make sense. Maybe you work with an AI Agent ahead of time and talk through the idea to generate the PRDs from the start. Maybe either approach can work in the early days, depending on your personality.

Regardless, my opinion at this point is that getting to PRDs is critical if you intend to build a real product.