For twenty years, product teams have misunderstood the Minimum Viable Product (MVP). They treat it like a diet version of the real product. Fewer features. Same architecture. Same team. Same timeline, just compressed.

That was never the point. The MVP was supposed to be the fastest path to validated learning. Not a smaller product. A cheaper question.

Now AI has entered the picture, and something strange has happened. The MVP hasn't become obsolete. It's become confused with something else entirely. That something else is vibe coding, and founders are making a category error that's going to cost them.

Let's sort this out.

What the MVP Was Always Supposed to Do

Go back to the original idea. An MVP exists to answer one question as cheaply as possible: will anyone want this?

Not: Can we build it? Not: Does it scale? Not: Is the architecture sound? Rather: Is there a real problem here, and does our approach to solving it resonate with real people?

Most teams never got this right even before AI. They built MVPs that were really just v1 with corners cut. It’s got half the features, all the technical debt, and none of the learning. The output looked like a product because it was built the way products are built. Slowly, with real engineers, using real infrastructure decisions that were hard to walk back.

That was the first MVP distortion. The adoption of AI has introduced another type of distortion.

AI Changes the Economics of "Trying"

Here's what's actually different now. The cost of generating a working piece of software has collapsed. Not the cost of a good product. The cost of something that runs, that a person can click through, that looks and feels like software.

Five years ago, testing an idea meant wireframes, a clickable Figma prototype, or, best case, a scrappy engineer burning a sprint. Now a single person with no engineering background can describe an idea in plain language and have a working application in an afternoon.

This is genuinely new. It is not hype. And it is exactly why teams are getting confused about what an MVP even is anymore.

Vibe Coding: What It Actually Changed

Vibe coding is the practice of generating software by describing intent to an AI system and iterating conversationally, rather than writing code by hand. You describe the screen. You describe the flow. The model produces something. You react to it, adjust, and it produces something else.

What vibe coding actually changed isn't the MVP. It changed the cost of the artifact that used to sit before the MVP: the prototype.

That distinction matters more than almost anything else in this conversation, so let's be precise about it.

A prototype answers a narrow question: does this interaction make sense, does this flow feel right, can a person understand what we're asking them to do? A prototype does not need to be secure. It does not need to handle edge cases. It does not need a real database, real auth, or a scaling plan. It exists to generate a reaction.

An MVP answers a different, harder question: will real usage, under real constraints, validate that this is worth building further? An MVP must actually work. It has to hold up to a real user doing a real task with real data, even if the scope is narrow and the implementation is rough.

Vibe coding is spectacular at the first job. It is dangerous when teams mistake it for the second.

The Trap: Treating the Vibe-Coded Artifact as the Product

I'm seeing two approaches right now, and the gap between them is widening fast.

The first approach treats the vibe-coded output as the product. Show it to a few users, get some positive signal, and start selling it. Then they try to add real customers, real data, and real load, and the thing falls apart. Not because the idea was wrong. Because the artifact was never built to survive contact with reality. It was built to survive a demo.

This is the same mistake teams made pre-AI when they called a fragile v1 an MVP, except now it happens in days instead of months, and founders are much more confident about it, because the thing feels so real. That confidence is the trap. A polished-feeling interface generated in an afternoon creates a false sense of engineering maturity that isn't there.

The second approach treats vibe-coded output as evidence. Use it to test a hypothesis, gather a reaction, and then make a deliberate decision about what gets rebuilt properly and what gets thrown away. The artifact did its job the moment it generated a real signal. It was never meant to be shipped.

The second approach moves faster in the long run, even though it feels slower in the first two weeks. That's the whole game.

So Can You Vibe Code an MVP?

Yes, with a real caveat. You can vibe code an MVP when its job is genuinely narrow, and when "working" doesn't require much beyond what the tools can already produce reliably. A single-user tool, an internal workflow, a lightweight consumer app with no sensitive data and no complex business logic. In those cases, the line between prototype and MVP nearly disappears, and vibe coding can carry you the whole way.

But most B2B products are not that simple. The moment you introduce multi-tenant data, permissions, integrations, compliance requirements, or anything resembling real business logic, vibe coding stops being an MVP tool and reverts to a prototyping tool. It's still useful. It's just doing a different job than the one founders want to believe it's doing.

The honest answer is this: vibe coding collapses the distance between idea and prototype almost to zero. It does not, however, collapse the distance between prototype and MVP nearly as much as one might think. That second gap is still mostly about judgment, not generation speed.

Is the Vibe-Coded Prototype the New PRD?

This is the question I’m most often asked right now, and I understand why. If you can generate a working, clickable artifact faster than you can write a document, why would anyone write the document?

The best answer is that the vibe-coded prototype replaces part of what the Product Requirements Document (PRD) used to do, but not all of it, and the part it replaces was arguably the weakest anyway.

The traditional PRD tried to do three jobs at once. It described the user problem. It described the intended experience. And it specified the requirements, constraints, and edge cases an engineering team needed to build something real. Most PRDs were mediocre at all three, because a static document is a poor medium for describing an experience, and most PMs aren't rigorous enough to fully specify edge cases anyway.

A vibe-coded prototype is a dramatically better medium for the second job. Nobody argues about what a flow feels like when they can click through it. That's not a small win. That's the death of an entire genre of unproductive PRD debate.

But the prototype does almost nothing for the third job. It doesn't tell your engineers what happens when the payment fails. It doesn't tell them what the permission model is for a second workspace admin. It doesn't tell them what "done" means for compliance, audit logging, or data retention. Those things don't emerge from "vibing". They emerge from a PM who has actually exercised thought, and increasingly, from a PM working alongside AI to pressure-test edge cases the same way they'd pressure-test them with a sharp engineer.

So the PRD isn't dead. It's shrinking to the part that was always the actual value: the requirements, the constraints, the definition of what "working" means for this specific narrow slice. The parts about "picture the user journey" are increasingly replaced by an actual clickable journey, and that's a good thing. Nobody will miss those pages.

The Roll-Up: From Vibe-Coded Signal to a Fully Baked Product

Here's how I'd frame the whole pipeline for a team trying to do this well.

Start with the prototype. Use vibe coding to get something a real person can react to as fast as possible. Don't worry about whether it's "real." It isn't supposed to be. Its only job is to produce a reaction you can trust.

Convert the reaction into a decision. This is where most teams skip a step. A positive reaction to a prototype is not validation that the product is worth building. It's validation that the problem framing and the interaction concept are worth pursuing further. Those are different claims, and conflating them is how teams end up building the wrong thing quickly instead of slowly.

Write the narrow spec. Once you know what you're building, write down the requirements that the prototype couldn't show you. What data model does this actually need? What happens at the edges? What does this look like for your second customer, not just your first? This is the surviving core of the PRD, and it's still a PM's job to get it right, even with AI in the loop drafting it.

Build the real MVP with engineering discipline, even if it's small. This is the part teams want to skip because the prototype felt so close to done. Resist that. A real MVP needs real data handling, even at small scale. It needs to survive a second user, a slow network, a bad input. It doesn't need to scale to a million users. It just shouldn’t embarrass you in front of the first hundred.

Only then do you start hardening toward a fully baked product, and that's a straightforward extension of good engineering practice: real observability, real security review, a real plan for what happens as usage grows. None of that gets shortcut by AI, and teams that assume it does are the ones who end up rebuilding everything 18 months in, at the worst possible time, with customers already depending on a product that was never built to hold their weight.

The Real Shift

The MVP concept hasn't changed. What has changed is how cheap it now is to get the first real signal, and how easy it is to mistake that signal, and the artifact that produced it, for the thing you're actually supposed to be building.

Vibe coding didn't kill the PRD. It killed the worst part of the PRD, the part that tried to describe an experience in prose rather than showing it. What's left is smaller, sharper, and honestly more useful than what most teams were writing before.

The teams that win this moment won't be the ones who generate the fastest. They'll be the ones who are most honest with themselves about the difference between a prototype that got a good reaction and a product that's actually ready to carry real weight.

That discipline was always the hard part. AI didn't remove it. It just moved it earlier in the process and raised the cost of skipping it.