About Vibe Product Management

As a disclaimer: we seem to already be at the stage where the phrase vibe coding has almost stopped being derogatory and describing mindless approval of all agent edits. It's now closer to a thoughtful process with the same specs, proper engineering practices and all that. Just with minimal manual coding. And it doesn't matter what the author of the term actually meant. I've even adjusted too, stopped being pedantic about it and use it myself often.

This post is inspired by my vibe coding experience and content from Boris Cherny (who is Claude Code) on Twitter. He says he delivers about 65 pull requests per week and every line in them was written by Claude Code. That's a lot. We'd be lucky to deliver that much as a team.

The thought is this. In my experience, this is only possible if 3 factors align:

First, the obvious: if you have automated quality gates and you trust them. Tests, static analysis and all that. People in this scheme should ideally be excluded entirely, they're slow.

Second, this pipeline shouldn't take minutes. Otherwise you'll still lose context, despite constantly juggling agent instances and trying not to fall out of it. And if you fall out of context, you physically can't do 10+ PRs a day. Unless they're one line each.

Third, this still doesn't sound very realistic to me if you have fixed requirements. Vibe coding moves the product incredibly fast and well if you have a vibe product mindset. Yes, I coined a new term for startup corner-cutting.

What does a person do if they hit some problem and can't solve the task in a reasonable timeframe? In the worst case — they'll keep banging away, periodically bringing you non-working solutions. Agents are prone to this too. Obviously it's a skill issue, but you have to agree it happens. You push it once, twice, three times, it doesn't work out very well, and now you need to make some decision about what to do. If we've agreed not to touch the code manually, we have one fast option — change the requirements to match the implementation. The other options are slow and unpleasant.

You have some strategic vision for your product, but you allow tactical deviation (even quite significant) from stated requirements or even the absence of formalized requirements in favor of speed of movement. You can understand on the fly with the agent that a different solution is good enough for you and it's much easier to implement. And that's fine.

AI doesn't conceptually change anything here either, but multiplies the importance of what was relevant before.