Spec-driven development creates requirements, design, and implementation documents before code, giving coding assistants more context and direction.
2
The developer must review the generated documents, correct errors, and remain responsible for the code produced by the agent.
3
The workflow can be done manually or with tools such as Kiro and Spec It, and it fits complex features, legacy applications, and some bug fixes.
Summary
Erik Hanchett presents spec-driven development as a way to control coding assistants during larger software changes. The workflow starts with written requirements, moves to a design document, and ends with an implementation task list. The developer reviews and edits each stage before allowing code generation. Hanchett compares language models with eager interns that need written instructions, supervision, and review. He demonstrates the approach in Kiro using a movie website project, including clarifying questions, Mermaid diagrams, EARS-format requirements, an MVP task grouping, and property-based tests. He also explains how MCP can bring requirements and technical details from project-management systems into the workflow. Kiro is one option, but he also describes a manual process and GitHub's open-source Spec It. The approach adds planning time and document review, so Hanchett suggests using it mainly for complex features, while smaller changes may be better suited to a faster coding workflow.
Written specifications give coding assistants direction before implementation
Hanchett defines spec-driven development as creating structured specifications before writing code. The working documents are Markdown files containing requirements and a design document. He says this structure fits large language models and coding assistants because the assistant receives the project's intended behavior before it starts producing implementation code. The goal is not only faster coding. The workflow is meant to help produce higher-quality code by making the expected behavior explicit before development begins.
Coding assistants need supervision because they behave like eager interns
Hanchett compares coding assistants with AI interns. They need strong prompts and clear guidance, because giving them too much freedom can send the work off course. He recalls being an eager intern who dropped existing work after a VP casually suggested an idea, then learned to write requests down, schedule them, and discuss them with his manager. Specifications provide similar discipline for an assistant. They turn an informal request into instructions that can be reviewed before code is produced.
More context helps, but steering documents need the right amount of information
Hanchett argues that even improving frontier models still need project context because software and requirements keep changing. He recommends care with documents such as agents.md or a similar steering file. Too little information leaves the assistant without useful rules, while too much can become counterproductive. He calls the desired amount a Goldilocks zone. He also recommends skills, which are instruction files activated by keywords or slash commands. Skills can support document creation and task implementation without putting every instruction into the main context.
The developer remains responsible for reviewing every stage and every change
The human stays in the loop throughout the process. Hanchett says developers should inspect the requirements and design documents, then review all generated code because the agent will not be blamed when something goes wrong. This does not exclude normal team review. Developers can use additional people, AI review tools, and pull-request review systems. The point is that generated documents and code need active review before they are accepted.
The workflow has three stages, requirements, design, and implementation tasks
Hanchett describes a repeatable flow that begins with user requirements, continues with a higher-level design document, and ends with implementation details in the form of tasks. The assistant can ask clarifying questions before producing the requirements. The design may include Mermaid diagrams or ASCII art. Hanchett advises editing the generated documents with the developer's own knowledge and preferences, then checking them for inconsistencies, hallucinations, and errors. The final task list can include property-based tests tied to the requirements and design.
An MVP task group makes a large generated plan easier to validate
After the task list is created, Hanchett recommends asking for the first four tasks to be moved to the top and turned into an MVP. This gives the developer a working slice to inspect before implementing the entire plan. In his movie website example, the first tasks produced a browsable movie grid with search, genre filtering, sorting, and an 80s synthwave theme. He implemented that MVP first. The approach provides an early way to see whether the generated plan matches the intended product.
Spec-driven development works with existing projects and external requirements
Hanchett says the workflow is not limited to new, greenfield applications. Existing applications can contain many specification files, and the process can support in-depth features in older codebases. Kiro also has a spec mode for bug fixes, although Hanchett suggests that smaller fixes may be better handled with a faster coding approach. Through MCP, an assistant can pull requirements and technical details from systems such as Jira or Asana into the specification process. Steering instructions can tell it which MCP source to consult.
Kiro packages the workflow, but the method does not depend on one tool
Hanchett presents Kiro, AWS's AI coding assistant, as an application built around the requirements and design pattern that teams were already creating themselves. Kiro includes spec mode in the IDE and plan mode in its CLI. Developers can also perform the process manually by asking an assistant to create requirements, reviewing them, requesting a design, reviewing that, and then generating implementation tasks. He also mentions Spec It, GitHub's open-source approach, which can be installed in different coding assistants.
"I would highly recommend, if you're trying this at home, to stop and go in and update it with your knowledge and expertise and taste to exactly what you're looking for."11:37
Who should watch
You are building a substantial feature in a large or unfamiliar codebase and want an assistant to plan before it edits files.
Your team needs requirements and design documents that can be reviewed before generated code is merged.
You are deciding whether to adopt Kiro or recreate the same workflow manually with an existing coding assistant.
