中文
AI Engineer World's Fair

The full spec-driven development flow, tool-agnostic: requirements, design and tasks documents before any code is written, to keep a wandering AI assistant on the rails

Using Spec-Driven Development for Production Workflows - Erik Hanchett, AWS · Erik Hanchett

18 min
AI CodingContextEvals

18 min total·Actually worth watching closely: ~3 min·3 must-watch clips

Orange = the 3 minutes worth watchingFor the rest, the guide is enough
Segment guide · 7 segments
  1. 0:00 3:20Listen

    What spec-driven development is

    Defines spec-driven development: structured specifications — the requirements and design document as markdown files — created before any code is written, an approach that works really well with large language models.

    Specs raise the quality of the code you get, not just the speed

    Pure narration setting up the concept, nothing worth watching — fine to listen to on the commute▶ Jump to 0:00
    Speaker · Erik Hanchett
  2. 3:20 7:02Listen

    Why you need it: the AI intern problem

    Compares coding assistants to AI interns: however good the models get they will go off the rails, so the spec documents keep guiding them, and you stay in the middle reviewing everything generated — if something goes wrong you are blamed, not the agent.

    The human-in-the-loop review is not skippable; the responsibility is always yours

    An argument rather than a visual — this chapter has nothing to see, just listen▶ Jump to 3:20
    Speaker · Erik Hanchett
  3. 7:02 10:00Listen

    Why Kiro has two modes

    Introduces Kiro's vibe and spec modes, which came straight out of customer feedback: people wanted more ways to work with larger features and more complex projects, and needed the coding assistant to know exactly what their project was doing.

    Vibe handles the small changes; spec is what gets you through large features

    Mostly spoken product background — the point at 472s is worth catching but does not need the screen▶ Jump to 7:02
    Speaker · Erik Hanchett
  4. 10:00 14:03Skim

    The three-step flow and context management

    Breaks down the core flow: EARS-format requirements (clarifying questions first, or quick plan mode for a fast pass) → a design document with Mermaid diagrams → a task list, with your own edits and review at each step. Also covers the Goldilocks zone for steering files and how skills fit in.

    Stop at every step and revise the documents with your own knowledge and taste — it is only as good as what you put in

    Slides walking through the steps; a glance at the flow diagram is enough, the value is in the audio▶ Jump to 10:00
    Speaker · Erik Hanchett
  5. 14:03 14:45Listen

    Feeding specs through MCP

    Use MCP to pull a requirements document your product manager already wrote out of a project management service as the input for your specs; tell the assistant where to look either through rules in your steering files or in the prompt at the first step.

    Your specs can start from the PM's existing document instead of a blank page

    A short spoken passage that sets up the demo that follows▶ Jump to 14:03
    Speaker · Erik Hanchett
  6. 14:45 16:20Watch

    Live demo: design document and property-based tests

    Demoed from the prompt "please create me a movie website": Kiro generates a design document with architecture and sequence diagrams, EARS-format requirements spell out the system's behavior step by step, and property-based tests use fast-check to run dozens if not hundreds of times with different values against the requirements.

    Property-based tests check the implementation directly against the requirements and design documents

    The most visually dense stretch of the talk: four consecutive LLM-flagged visual moments (903/937/964s), with the documents and test code on screen — you have to watch▶ Jump to 14:45
    Speaker · Erik Hanchett
  7. 16:20 17:46Watch

    MVP reordering and the close

    Kiro is asked to turn the task list into an MVP, and tasks one through four then deliver a working, browsable, searchable, filterable version; hovering over a property-based test in the IDE shows exactly what it checks. The close stresses that none of this is tied to a specific tool and that existing projects and bug fixes work too — manually with any assistant, or via SpecKit.

    Once the task list exists, reorder it into an MVP so you get something running out the door early

    The reordered task list and the test hover tooltip are hands-on shots on screen (visual moments at 980/1016s); audio alone misses what the tip actually does▶ Jump to 16:20
    Speaker · Erik Hanchett