Tokenless

Spec-Driven Development: Sharpening your AI toolbox - Al Harris, Amazon Kiro

Spec-Driven Development offers a structured, reproducible, and reliable alternative to 'vibe coding' in the AI era. Al Harris from the Kiro team explains how to leverage specs as living documentation, integrate external tools via MCPs, and use property-based testing to create a tight feedback loop from natural language requirements to verified code.

3 min read
Spec-Driven Development: Sharpening your AI toolbox - Al Harris, Amazon Kiro
source: https://www.youtube.com/watch?v=HY_JyxAZsiE

Spec-Driven Development (SDD) provides a structured methodology to scale AI-driven development for more complex problems, enhancing control over AI agents and improving the quality and reliability of the generated code. It stands in contrast to “vibe coding,” which relies heavily on the operator’s ability to provide perfect guardrails and workflows for an AI agent. SDD respects decades of software development life cycle (SDLC) experience, compressing the process by creating a tight, iterative loop between requirements, design, and implementation.

The spec itself is viewed as a combination of three things:

  1. A set of artifacts representing the system’s state at a point in time (requirements, design, tasks).
  2. A structured workflow (requirements -> design -> execution) to reliably deliver high-quality software.
  3. A set of tools, like property-based testing and requirements verification, to ensure reproducible results.

The Kiro Spec-Driven Development Workflow

The process in Kiro, an agentic IDE, follows a structured flow designed to translate an initial idea into verified code:

  1. Prompt to Requirements: A user’s initial prompt is transformed into a clear set of requirements and acceptance criteria. Kiro uses the EARS (Easy Approach to Requirement Syntax) format, which provides a structured, natural language representation of what the system should do (e.g., “when-then-shall” syntax). This structure is crucial for enabling non-LLM based automated reasoning.

  2. Design and Properties: From the requirements, a design document is generated. Crucially, the system also extracts correctness properties—effectively system invariants—that must hold true.

  3. Property-Based Testing (PBT): This is a key feature that connects requirements to code quality. The EARS requirements are translated directly into properties that can be tested using frameworks like hypothesis in Python or fast-check in Node. PBT aims to find a single test case that falsifies an invariant. If no such case is found after extensive testing, it provides a high degree of confidence that the implemented code meets the specified requirements.

  4. Task Generation and Execution: A detailed task list is created from the design and requirements. The agent then executes this plan to generate the final code, with a clear definition of success for each task.

Sharpening the Toolbox: Customizing the Process

The SDD process is not rigid; it’s a toolchain that can be sharpened and adapted to specific needs.

Integrating External Knowledge with MCPs

Multi-Capability Providers (MCPs) allow the agent to access external tools and data sources at any stage of the workflow. For example:

  • Requirements Generation: An MCP can pull tasks directly from a project management tool like Asana to create the initial spec.
  • Design Phase: The agent can be prompted to use documentation MCPs (e.g., AWS documentation) or search tools to research the most idiomatic or “future-proof” way to solve a problem, rather than just implementing the user’s initial, potentially biased, suggestion.

Customizing Artifacts

Since the generated artifacts are natural language, they are fully customizable. This allows developers to enrich the spec with additional context:

  • UI Mockups: A user can ask Kiro to include ASCII wireframe diagrams directly within the design document to provide a clearer vision of the UI being built.
  • Explicit Test Cases: To combat an LLM’s tendency to declare a task “done” without full verification, developers can instruct the agent to include explicit unit test cases that must pass for a task to be considered complete.

Specs as Living Documentation

Unlike ephemeral plans, specs in Kiro are intended to be living, version-controlled documents. When a new feature request comes in that relates to an existing part of the system, the agent can find the relevant spec and amend it. This creates a diff of the requirements and design, which the team can review. The Kiro team itself uses this “spec review” process in place of traditional design document reviews, ensuring that documentation about the system’s behavior evolves alongside the code.

Share post

Stay In The Loop! Subscribe to Our Newsletter.

Get updates straight to your inbox. No spam, just useful content.

Recommended for You

Devin 2.0 and the Future of SWE - Scott Wu, Cognition

Devin 2.0 and the Future of SWE - Scott Wu, Cognition

Scott Wu, CEO of Cognition AI, discusses the exponential growth of AI capabilities in software engineering, likening it to a "Moore's Law for AI agents" with a doubling time of every 70 days. He chronicles the evolution of their AI agent, Devin, from handling repetitive code migrations to autonomously managing entire backlogs, highlighting the key technical challenges and paradigm shifts at each stage.

The Infinite Software Crisis – Jake Nations, Netflix

The Infinite Software Crisis – Jake Nations, Netflix

In an era of the "Infinite Software Crisis" where AI-generated code outpaces human understanding, this talk argues for choosing "simple" design over "easy" generation. The speaker presents a three-phase methodology—Research, Planning, and Implementation—that forces developers to think critically before generating code. This approach leverages AI for mechanical tasks while ensuring that human judgment, context, and a deep understanding of the system remain the core of the software development process, turning human insight into the ultimate competitive advantage.