Developers are great at asking clarifying questions when someone hands them a task. We probe assumptions, surface edge cases, and push back on vague requirements. When the roles flip, and we're the ones writing a spec for an AI agent, that skill mysteriously evaporates. We assume too much, leave too much implicit, then act surprised when the agent confidently builds the wrong thing.

The obvious answer is "write a better spec." But sloppy specs miss the same things sloppy prompts miss. The gap isn't between code and prose. It's between what we ask for and what we actually wanted.

This talk walks through a spec-driven workflow that takes that gap seriously. We start with a deliberately under-specified feature request and see how many clarifying questions a careful spec pipeline can surface that a developer-in-a-hurry would miss. We go through the pipeline I use now (proposal, spec, criteria, rules, review, plan, execute) and look at where each step earns its keep.

The deeper claim is that AI coding agents amplify whatever engineering discipline you bring to them. Without it, you get faster vibe coding. With it, you get something that looks more like engineering, where system design skills and software fundamentals matter more than ever, not less.

This isn't a pitch for any specific toolkit or an agent. Get the thinking right, and you can adapt to whatever SDD tooling shows up next. The point is the thinking, not the dogma.