A year ago, vibe coding went viral. Describe what you want, let the agent build it, ship the demo. It lowered the floor and made prototyping faster than anyone expected. It also introduced a surplus of code nobody wants to maintain — architectural drift, silent contract breaks, and the agent's favorite move: confidently building the wrong thing.
Spec-driven development is the pattern that raised the ceiling. The specification becomes the source of truth, and code becomes a generated artifact that implements it. If the code and the spec disagree, you fix the code, not the spec. It sounds like waterfall. It isn't — because when regeneration takes minutes instead of months, the economics of "getting the spec right" completely change.
In this session, we'll build the same small app twice. First the vibe-coded version: fast, demo-ready, and quietly broken in the ways that matter. Then the spec-driven version using GitHub Spec Kit, walking through the six elements every agent-ready spec needs — outcomes, scope boundaries, constraints, prior decisions, task breakdown, and verification criteria. We'll look at where the two versions diverge, what kinds of defects each approach catches, and where SDD is genuinely better versus where it's just extra process.
You'll leave with a working mental model for when to reach for vibes, when to reach for specs, and how to tell the difference before your users tell you.

-Level: Intermediate
-Format: Technical Session, 35–45 minutes