vibe coding Is Dead — Write Specs Instead? PMs Have a Third Option: Speak It, AI Builds It
The methodology crowd is in a fight right now, and the headlines are alarming: “vibe coding is dead — switch to spec-driven development immediately.”
The wind really is shifting. Spec Kit on GitHub is past 90,000 stars. AWS launched Kiro, built entirely around “spec first, code second.” Thoughtworks put spec-driven development on the Technology Radar. The mainstream argument: specs are the single source of truth; code is just the output. When they conflict, fix the code — never the spec.
Sounds reasonable. But if you’re a product manager, don’t rush off to take a “writing specs” crash course just yet.
The pendulum has swung too far
Here’s how the story went:
First, vibe coding exploded — throw one line at AI, watch it generate a mountain of code. Intoxicating, until it all fell apart: no structure, can’t maintain it, nobody can explain what it actually does. So the overcorrection hit: fine, write everything as a spec first, the more detail the better, then let AI follow it.
The problem for product managers is that “write a pile of detailed upfront specs” is something you know all too well — that’s a PRD. The document that runs to dozens of pages, is outdated the moment it’s done, and nobody ever reads to the end. One of AI’s great gifts was lifting you out of that document drudgery. Now spec-driven is loading it right back onto your shoulders and handing it a trendy new name.
Swinging from “winging it” to “writing specs” is just trading one extreme for another. Neither end of that pendulum is where a PM should stand.
The third path: specs aren’t written — they’re spoken and run
vibe coding is too brittle. Heavy specs are too heavy. There’s a path in the middle, and it’s the one doaipm has been walking all along — speak it, AI builds it.
The core idea: you don’t need a spec living in a document. You need to say clearly what you’re trying to build. And “saying things clearly” is the most fundamental PM skill there is — not a new one.
Break it into two things:
First, specs live in the conversation, not in a document. You don’t need to produce a complete spec before you start. You articulate your intent — who has what problem, what the key constraints are, what “done right” looks like — then let AI turn it into something runnable on the spot. Where you’re unclear, AI asks back (a good agent should ask 3–5 sharp questions before touching anything), and you sharpen it in the exchange. Clarification happens in dialogue — not in a document nobody wants to read.
Second, a runnable high-fidelity prototype is the best spec there is. A written spec gets ten different readings from ten different people. A prototype you can actually click through — with real states (loading, empty, error, success) — tells everyone instantly whether it’s right. A high-fidelity prototype is a spec that speaks for itself. It doesn’t need to be interpreted; it’s experienced directly. This is also why doaipm pushes back on low-fidelity wireframes: in the AI era, building the real thing is faster than sketching a fake one, and causes far less misunderstanding.
Where does structure come from? — Small steps and a safety net
Someone will ask: without heavy specs, how do you avoid repeating vibe coding’s chaos?
Two things — not thick documents:
- Small steps, fast moves. Change one thing at a time, run it, check it, take the next step. Structure grows out of a chain of verifiable small moves — it isn’t planned to death upfront.
- Safety net. No real API keys or real data in prototypes. Irreversible actions — publish, delete, pay — always go to a human. Stay off production. When in doubt, ask. Judgment stays in your hands at all times — that’s exactly the part of this job that can’t be automated.
The argument that specs are the single source of truth is missing one line: in the AI era, the highest-fidelity “source of truth” isn’t a document — it’s the product running in front of you.
So what should you actually believe today?
Don’t pick a side between “vibe coding” and “spec-driven.” That’s a false choice.
- Don’t do what vibe coding does — think nothing through and outsource your brain to AI.
- Don’t do what heavy specs do — reload the document burden AI just helped you put down.
- Take the middle path: say what you mean (you already know how), let high-fidelity prototypes speak for you (AI makes that possible), move in small steps, and hold the safety net.
This isn’t another new framework to learn — there are already enough frameworks. It’s a return to the most basic PM move there is: get clear on what you want, say it out loud, then make it run.
Speak it. AI builds it.
Discussion