I built the specshop.dev website using Cursor and Claude. Not a mockup. Not a wireframe. The actual website — copy, structure, flows — assembled with AI, iterated in real-time, adjusted as the thinking changed. I’ve done the same with client prototypes: described a product in plain language, had a working, clickable thing within hours, and walked into the next conversation with something real to put in someone’s hands.
I’m telling you this not to impress you. I’m telling you this because the way it changed every conversation that followed is the actual story here.
For 20 Years, “MVP” Meant: Ship Something Ugly and See If Anyone Cares
Eric Ries codified it in The Lean Startup (2011). Frank Robinson coined the term before that. The logic was airtight for its time: building software was expensive, precision was expensive, and “figure it out in production” was the only rational strategy when getting it exactly right upfront cost more than the project itself.
So we shipped ugly. We called it lean. We iterated. Sometimes it worked brilliantly. More often, it produced something that was viable for nobody — a half-formed thing that neither validated the idea nor impressed the users expected to tolerate it.
The inconvenient data underneath the MVP era was always there.
Then Vibe Coding Happened
In February 2025, Andrej Karpathy — co-founder of OpenAI, former AI lead at Tesla — posted a tweet that got 4.5 million views and ended up being named Collins Dictionary’s Word of the Year. He called it “vibe coding”: describe what you want in natural language, let AI write the code, and evaluate the output on whether it works rather than whether you understand every line.
Here’s what almost everyone missed in the wave of hot takes that followed.
The Prototype Isn’t the Product. It’s a Spec That Built Itself.
When I build a prototype using Cursor or Claude, something specific happens in every conversation that comes after it.
The ambiguity disappears.
Not because I wrote better requirements. Not because I ran a better discovery process. Because I made the invisible visible. I took the thing that lived inside my head — approximate, fuzzy, full of unstated assumptions — and turned it into something that clicks and flows and behaves like real software. And the moment you can put that in front of a stakeholder, a user, or a co-founder and say “is this what you meant?” — the entire conversation changes register.
You stop debating abstractions. You start reacting to reality.
This is what nobody writing about vibe coding is saying: the prototype wasn’t the deliverable. It was the negotiation. It was the mechanism for surfacing every assumption that would have cost you weeks of rework at $150/hour if you’d only discovered it after code was written.
The brief became the build. The build became the brief. And somewhere in that collapse, the MVP — as a concept — became redundant. Not because shipping fast became wrong, but because the excuse for shipping unclear was gone.
Why the MVP Was Always a Workaround, Not a Solution
The MVP was a rational response to an economic constraint. When precision was expensive and building was expensive, “ship something and iterate” made sense. You traded clarity for speed because clarity cost too much.
Vibe coding inverted that equation.
Now the cost of building a first version is negligible. The remaining cost — the only remaining cost — is knowing exactly what you want. And suddenly, the workaround doesn’t justify itself anymore.
The Spec Was the Product All Along
Here’s the thought experiment that changed how I think about this.
Imagine a PM with no engineering background who builds a working prototype of her product idea in an afternoon using Lovable or Cursor. Not a Figma mockup. A thing that clicks, flows, and behaves like real software. She walks into a stakeholder meeting and says “here, use it.” She hands it to five users and watches silently where they hesitate. She sits with her CTO and they have a conversation about architecture that starts from shared understanding instead of competing assumptions.
That single session eliminates more than half the back-and-forth that buries most projects. Not because AI writes better code. Because the conversation changed from “what do we think this should be” to “here’s what it is — what’s wrong with it?”
That working prototype is a spec. The most honest spec anyone has ever written, because it was built from intent rather than language, and intent doesn’t lie the way language does.
Karpathy himself has moved past “vibe coding.” By February 2026 he was calling it passé and proposing “agentic engineering” instead — the idea that you orchestrate AI agents with oversight and scrutiny, not just give in to the vibes. He’s right. And that evolution proves the point: the era of vibe coding wasn’t really about coding at all. It was proof of concept for a bigger idea. The bottleneck was never code. It was always the conversation.
What This Means If You’re Building Something Right Now
- Stop writing specs for developers. Build the first version yourself. Even if it’s held together with tape. The artifact teaches you more about your own product than any Google Doc ever will — because you can’t fake a working button the way you can fake a requirement.
- Use the prototype as a stakeholder tool. Nothing kills ambiguity faster than putting a working thing in someone’s hands and asking “is this what you meant?” The places they hesitate are your real requirements. Not the ones you wrote down.
- Treat it as a feedback magnet. Hand it to five users. Watch silently. The moments of confusion are worth more than any survey.
- Then — and only then — hand the validated prototype to an engineering team. The clarity is the value. The build is what clarity makes possible.
What Comes Next: The Minimum Lovable Product
The MVP was born from scarcity. When building was expensive, “viable” was a meaningful bar — it meant you’d done enough to test the hypothesis without wasting money on precision you couldn’t yet afford.
That bar no longer exists.
When AI-assisted development can collapse months of effort into days, “viable” is no longer the constraint. You can make it lovable in the same time it used to take to make it viable. The economic excuse for shipping ugly is gone.
The new question isn’t “what’s the minimum we can ship?” It’s “what does this need to be before users feel seen by it?” Same speed. Ten times the clarity. That’s the Minimum Lovable Product.