A few weeks ago, I spent a weekend and part of the week building a thing called PaymentMinder.com with Claude Code. Somewhere around hour six, it hit me that I wasn't really coding. I was writing a PRD. And the PRD was doing the work.
That's when I stopped calling what I was doing, "vibe-coding." With a little research, I discovered that a thing now being called specification-driven development (SDD) is roaring back to life after a 30 year stint in the tomb.
Two modes, and they are not the same
Vibe-coding is the thing most people think AI-assisted development is. You open a chat, describe what you want, the model writes code, you run it, something's off, you nudge, repeat. The state of the project lives in the conversation. The spec is whatever you remembered to mention before the context window filled up. It's great for prototypes and exploration. I'm not knocking it.
Try to build something real that way and you start noticing the seams. Context drifts. Decisions you made on Tuesday get re-litigated on Thursday because the model doesn't remember them. The LLM can't tell you what the system should do versus what it does do, because it never had a fixed picture of the former. It's very easy to get started, but as your application gets more complex, you run into more problems because of the lack of forethought.
Spec-driven development inverts the relationship. The PRD — or whatever you want to call the spec — is the source of truth. The LLM's job isn't to invent intent on the fly. Its job is to reconcile code against a spec that exists independently of the chat.
Same tools. Wildly different experience.
Where the differences actually show up
A few places, and they all compound.
Source of truth. Every PM I know has written PRDs that died in Confluence. In vibe-coding, the spec lives in chat and dies with the session. In SDD, the PRD becomes load-bearing — Claude reads it, reasons over it, checks code against it. For the first time in my career, the PRD is the most-used document in the project instead of the most-ignored one. I'm not sure I'd have believed that a year ago.
Context continuity. Vibe-coding is like working with a contractor who forgets everything between standups. SDD is like working with one who reads the wiki before every session. On PaymentMinder, a fresh Claude Code session is productive in about two minutes because the /docs folder does the job a good onboarding doc does for a human engineer.
Change management. Requirements change. That's not a bug in product management, that's the job. Vibe-coding handles this by silently overwriting intent. SDD handles it the way any decent product team does: explicitly call out the change, update the spec, review the diff, then change the code. The spec diff becomes a decision log — which is the artifact every PM wishes they had six months into any project and never does.
Debugging. This one sells itself. Without a spec, every deviation is ambiguous. Is the code wrong, or did we change our minds? SDD collapses that ambiguity into one clean question. Mismatch with spec = bug. Spec update = intentional change. Those are two different conversations with two different workflows, and you want them separated.
Time shape. Vibe-coding has a fast start, a painful middle, and an abandoned project. I've done it. If you've been vibe-coding, I bet you have too. SDD has a slower start and then velocity compounds, because the spec keeps paying back every session. It's the same shape as good product work generally. Invest in the definition. Ship faster forever after.
The punchline
Here's the part I want PMs to sit with.
Vibe-coding rewards people who can code fast. That's a real skill and I respect it, but it's not mine, and it's not most PMs'.
SDD rewards people who can specify well. Crisp requirements. Clear acceptance criteria. Tight scoping. Good decomposition. The ability to describe a system precisely enough that someone — or something — can build it without guessing.
That is the PM skill stack. That is literally the craft.
The LLM doesn't replace the PM. It makes the PM's existing craft the bottleneck, in a genuinely good way. The better your spec, the better your output. The worse your spec, the more obvious it gets, fast.
I used to think "10x engineer" was a personality trait attached to someone who types quickly and skips meetings. I'm starting to think the actual 10x now is a PM who can write a spec so clean that a reasonably competent LLM can build against it without needing to be babysat. That's not a hypothetical. I've been living it on a side project for a couple of months.
The tradeoff is real — SDD front-loads work, and there are weekends I just want to mess around in a chat window and see what happens. Fine. Use the right mode for the job.
But if you're a PM watching the AI conversation and wondering where you fit: you already have the skill. You've been training it for years. The tools finally caught up.