If a PM Can Vibe Code a Prototype in 30 Minutes, Why Does V1 Still Take Three Months?

Andrew films a 47-second walk-and-talk through a leafy New York street and asks one pointed question, pinned on screen the whole time: "Why are PMs coding faster than devs now?" His observation is that AI coding tools have made prototypes nearly free. A PM can vibe code a working V1 in an afternoon, yet the dev team still quotes weeks or months to ship the real thing.

He does not fully take either side. The PM's prototype looks good, works, and might even be connected to a database. But he also acknowledges what the non-technical builder cannot see, then turns the question back on engineering teams: some of that three-month timeline is probably bloat.

The New Awkward Meeting

The scenario Andrew describes is happening on a lot of teams right now. A PM vibe codes an entire V1 in a single afternoon, brings it to the dev team, and says it is finished. The dev team responds with a four-week estimate, and the PM does not understand why.

His take is that the PM is not entirely wrong to be confused. The prototype looks pretty good, it works, and it could actually even be connected to the database. The gap between "demo that works" and "shipped product" used to be obvious because building the demo took real engineering effort. Now the demo is cheap, and the remaining gap is invisible to the person who built it.

What the Non-Technical Builder Cannot See

Andrew points to the other visible symptom of this shift: the kid who does not know how to code launching a new app to the App Store in about a week. He is direct about the tradeoff. The non-technical person is cutting corners and probably has security issues they do not realize.

That is the standard engineering rebuttal, and he grants it. Prototypes skip the work that makes software safe to put in front of real users: security review, error handling, edge cases, and the operational plumbing that never shows up in a demo.

The Uncomfortable Part for Dev Teams

The video does not end on the engineering side's win. Andrew closes by saying he cannot help but feel there has to be some unnecessary bloat in a lot of dev processes still. If a working, database-connected prototype takes an afternoon, a three-month V1 timeline invites scrutiny. Some of that time is legitimate hardening. Some of it, he suspects, is process that predates the tools.

He leaves the question open. The video is a provocation, not a prescription: both the PM overestimating their prototype and the dev team defending every week of the old timeline are partly wrong.

Key Takeaways

• AI tools let PMs and non-technical builders produce working, database-connected prototypes in an afternoon, which makes traditional multi-month V1 timelines look inexplicable to them.
• The prototype-to-production gap is real: non-technical builders cut corners and ship security issues they do not know exist.
• Andrew grants the engineering rebuttal but argues it is not the whole story, since dev processes likely carry unnecessary bloat that predates AI tooling.
• The tension he describes, a PM demoing a "finished" V1 to a dev team quoting four more weeks, is a preview of a conversation most product teams will have.