Spec-Driven Development turns a prompt into requirements, a design, correctness properties, and an executable task list.
2
Kiro uses structured natural language, property-based testing, MCP servers, and steering documents to make agent output more reproducible.
3
Teams can improve results by spending more time on requirements and designs, then changing the generated artifacts and workflow to fit their own practices.
Summary
Al Harris explains how the Kiro team uses Spec-Driven Development to control agentic coding on larger software tasks. A prompt becomes requirements with acceptance criteria, a design document, correctness properties, and a task list. The specification is intended to describe the system over time, rather than disappear after implementation. Harris shows how MCP servers can add information during requirements, design, and implementation, and how teams can customize artifacts with wireframes or explicit test cases. Steering documents capture local coding and deployment practices. He also demonstrates a workflow that researches alternatives before implementation, although an early S3 decision can bias the agent. Kiro's longer-term direction includes bidirectional updates between code and living specifications, plus more automated reasoning over requirements. Harris is candid about current limits, including session context growth, imperfect summarization, and weaker performance on poorly structured codebases.
Spec-Driven Development turns an agent prompt into a complete delivery workflow
Harris says Kiro starts with a prompt and produces clear requirements with acceptance criteria, then a design, correctness properties, and a task list. The specification contains functional and non-functional constraints and becomes a natural-language representation of the system. He describes it in three parts: artifacts that capture the system at a point in time, a workflow through requirements, design, and execution, and tools that help produce reproducible results. The goal is to connect the original requirements to the finished code, so the team can check whether the delivered system matches what it intended to build.
Structured requirements make automated checks possible
Kiro represents acceptance criteria using EARS, the Easy Approach to Requirements Syntax. Harris describes this as structured natural language that can be processed with more deterministic techniques. The team is translating EARS requirements into properties, which are invariants the system should satisfy. Property-based testing then tries to find an input that falsifies each invariant. If it finds a counterexample, the requirement is not met. If it does not, the team gains confidence, although Harris says that confidence depends on how well the tests were written.
MCP servers add outside information at every stage of the specification workflow
Harris says developers often use MCP servers during implementation but should also use them while generating requirements and designs. In his examples, an Asana MCP server imports product tasks and turns them into requirements. A fetch server can gather examples from similar products, while an AWS documentation server gives the agent access to service documentation. MCP tools can be enabled or disabled and can be allow-listed. Harris warns that changing MCP configuration deep into a long session is a caching operation and can slow the session considerably.
Teams can change the generated artifacts to match how they work
Harris treats Kiro's default requirements, design, and task documents as a starting point. He asks the agent to add ASCII wireframes to a design so the team can discuss proposed screens before implementation. He also asks it to put explicit unit test cases into tasks, so completion means that those tests pass rather than simply trusting the agent's claim that it is finished. The same approach can add sections for non-functional requirements, code coverage, code style, or other project-specific concerns.
Agents should research alternatives before a user preference hardens into a design
In a demo, Harris asks Kiro to add memory to an agent and initially directs it to store conversations in S3. He then points out that this choice may be an accidental bias based on his familiarity with S3. Kiro researches whether there is a more idiomatic approach, using MCP tools and available documentation. It identifies AgentCore Memory as another option. Harris says developers should keep asking about alternatives instead of treating the initial request as the final architecture. The specification workflow can be challenged during design, before implementation costs make the decision harder to change.
Living specifications should be updated instead of accumulating disconnected task lists
Harris wants specifications to support bidirectional synchronization over time. When a requirement changes, the existing specification should be amended and the design implications should be visible as a diff. The Kiro team reviews design documents as specification reviews, sharing Markdown through an internal wiki and discussing the changes with the team. He gives message-history sanitization as an example of a specification that gains acceptance criteria as new validation rules are discovered. A spec generally describes a feature or problem area, and older specs can be deleted when they are no longer useful.
Codebase structure affects how well an agent can work on an existing project
For brownfield work, Kiro researches the working tree and tries to understand what already exists. Harris says agents do better when modules have clear separation of concerns, high cohesion, understandable decomposition, and reliable tests. Poorly structured code makes it harder for an agent to find the right context, just as it makes the system harder for a developer to understand. Kiro also has background indexing and semantic search, but Harris says the index is mainly used for interface features such as code search. The agent is usually given tools to discover context instead of receiving the entire codebase at once.
Spec-Driven Development prioritizes reproducibility and accuracy over prompt latency
Harris distinguishes the cost of a short prompt from the cost of a detailed engineering process. If an agent gets a ten-second prompt wrong, the loss is relatively small. A requirements review and design process that takes much longer creates a stronger expectation that the implementation will be correct. He says Spec-Driven Development is mainly intended to improve reproducibility and accuracy, while the Kiro team separately works on execution speed and interaction latency. The tradeoff is deliberate: more upfront work should produce a result that is easier to inspect and repeat.
"We don't want to load too much at the beginning of the context and conversation with the agent. We want the agent to self-discover the right context for the task."43:03
Who should watch
You are using coding agents on work that needs reviewed requirements, repeatable implementation, or stronger acceptance checks.
Your team has an existing codebase and wants to understand how module boundaries, tests, and searchable context affect agent performance.
You want to customize an agent workflow with MCP servers, project rules, wireframes, test cases, or deployment guidance.
