Spec-Driven Development for Product Managers: Beyond Vibe Coding

Andrej Karpathy coined "vibe coding" in February 2025: accept all LLM suggestions, move fast, iterate by feel. For a solo developer building a weekend project or a PM prototyping a concept in v0, it was a genuine unlock. But by early 2026, Karpathy himself acknowledged that the vibe coding era was ending for serious engineering work.

The failure mode is predictable. AI coding agents that work from natural language prompts without a formal specification tend to produce code that works in isolation but drifts from architectural intent. As the codebase grows, the agent misses edge cases, hallucinates APIs, and generates code that conflicts with existing patterns it cannot fully hold in context. The result is a codebase that looks right in individual files and breaks at integration.

GitHub reports that teams using SDD on internal projects ship features with roughly an order of magnitude fewer "regenerate from scratch" cycles than teams using ad hoc prompting. Early adopters at AWS report 3 to 10 times higher first-pass success rates on non-trivial tasks. The methodology works because it gives agents the context they need to stay aligned across a multi-file, multi-session implementation.

Spec-driven development is a software methodology where the executable specification, not the code, is the source of truth. The team writes a detailed spec describing what the system should do. An AI coding agent (or a human engineer) then derives an implementation plan, breaks it into atomic tasks, and generates code against that plan. The spec persists between sessions and anchors the agent whenever work resumes.

The key insight is that the spec file persists between sessions. An AI coding agent that picks up a feature mid-implementation can read the spec to recover context that would otherwise require re-prompting or produce drift. This is especially important on features that take more than a single session to build.

A spec that guides an AI coding agent is different from a traditional PRD. PRDs are written for humans: they can tolerate ambiguity, fill in gaps from context, and ask questions. AI agents interpret the spec literally and fill gaps with their own assumptions, which may be wrong. An effective spec for AI implementation is more precise than a PRD but narrower in scope.

In a traditional engineering team, the PM writes a PRD and engineers translate it into technical requirements. In a spec-driven team, the PM's leverage point shifts: the spec is closer to executable than a PRD, and the quality of the spec directly determines the quality of what the agent builds.

PMs who write precise specs find that they reduce the back-and-forth with engineers by 50 to 70%. The ambiguity that used to live in "requirements refinement meetings" gets resolved at spec-writing time instead. This is a significant shift in where PM time goes.

By mid-2026, every major AI coding tool has shipped a spec-driven workflow. The implementations vary in how tightly they integrate the spec into the agent context, but the core pattern is consistent: write a spec, agent reads it, agent works task by task.

Spec-driven development has overhead: writing a good spec takes one to three hours for a well-scoped feature. Not every change justifies that investment. Here is the decision framework for when SDD pays for itself versus when it is engineering theater.