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.
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.
↳ TL;DR — vibe coding wasn’t the answer. It was the proof that the spec, not the code, was always the product.
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.
This is why we built specshop.dev the way we did
We didn’t arrive at spec-first development because it sounded good in a pitch deck.
We arrived at it after 9 years and 120+ shipped products at our previous studio, watching the same failure mode repeat across clients, geographies, and industries: not bad code, not bad developers — bad conversations that happened too late, after commitments had been made and budgets had been spent.
We shut that studio down in 2025. We saw AI coming before most agencies wanted to acknowledge it. We rebuilt from the ground up around a different premise: that the spec is not the precursor to the product. The spec is the product. Everything else is execution.
Frequently asked questions
What’s the difference between vibe coding a prototype and actually speccing a product?
A vibe-coded prototype is what happens when intent meets a tool. A spec is what happens when you interrogate that prototype — when you ask “why does this work?” and “what does this assume?” and “what breaks at scale?” The prototype surfaces the questions. The spec answers them. Both matter. Neither replaces the other. What’s new is that the prototype now arrives in hours instead of weeks, which means the spec conversation happens earlier, when it costs almost nothing to change course.
Isn’t this just another way of saying “build fast and iterate”?
No. Build fast and iterate is what you do after you know what you’re building. What vibe coding changed is the discovery phase — the messy, expensive, assumption-filled conversation that happens before a single line of production code is written. That conversation used to happen in words. Now it happens in working software. The iteration loop is the same. The thing that changed is what you iterate from.
What if I can’t code at all? Can I still build a prototype?
Yes. Tools like Lovable, Bolt.new, and Claude are designed for exactly this. You describe what you want in plain English and a working interface appears. You won’t ship it to production. You will understand your own product better than you did before you started — and that understanding is worth more than the prototype itself.
What’s the risk of handing AI-generated prototype code to a production engineering team?
It’s real. Security researchers found vulnerabilities in a significant portion of vibe-coded applications. Production code needs human review, proper architecture, security consideration, and test coverage. The prototype proves the idea. It doesn’t replace the engineering. This is precisely why spec-first, build-second is the right sequence: you validate with the prototype, then you build properly from the clarity it gave you.
What does “spec-first” actually look like in practice?
At specshop.dev, it looks like this: before a line of production code is written, you and we produce a document that describes every workflow, every decision point, every user action, every edge case. You approve it. Then we build. No surprises in week three. No “that’s not what I meant” at handoff. The spec becomes the contract, and the contract is written in plain language, not technical jargon.
How is this different from what agencies have always done?
Most agencies write specs to protect themselves, not to serve the client. A change order is a revenue event. Ambiguity in week one is a billing opportunity in week six. We write specs because we work on fixed price. Our incentive is to get it right upfront, not to discover requirements expensively mid-build.
Essay — Spec-first Product Development · specshop.dev · April 2026