Spec-driven development is a software development pattern in which structured specifications are written and validated before any implementation code is produced. The specifications define what needs to be built (requirements), how it will be built (design), and the ordered steps to build it (tasks). This pattern has historical roots in formal methods and has been given a modern, AI-native formalization by Kiro, an agentic AI IDE from AWS that generates and enforces a three-document specification workflow.

Origins and History

The principle that specifications should precede implementation is foundational to software engineering. Formal methods research dating to the 1960s and 1970s, including Edsger Dijkstra’s structured programming discipline and Tony Hoare’s axiomatic semantics, established that rigorously specifying program behavior before coding reduces defects and improves reasoning about correctness [1]. The Z notation (Jean-Raymond Abrial, 1977), Vienna Development Method (VDM), and later the B method formalized specification languages for industrial use.

In practice, most software teams adopted lighter-weight versions: requirements documents, design documents, and task breakdowns in project management tools. Agile methodologies from the early 2000s de-emphasized upfront specification in favor of iterative discovery, but the core tension between “think first” and “build first” persisted.

The modern spec-driven development pattern was formalized by Kiro, announced by AWS in 2025, which introduced a structured three-document workflow specifically designed for AI-assisted development [2]. Kiro’s approach acknowledges that AI coding assistants produce better results when given precise, structured context rather than vague natural language prompts. The spec documents serve as both human-readable plans and machine-readable context for the AI.

The Three-Document Structure

Kiro’s spec-driven workflow centers on three files created in sequence for each feature or change [3].

requirements.md captures what needs to be built using user stories and acceptance criteria written in EARS format (Easy Approach to Requirements Syntax). Each requirement is specific enough to be testable. The document ensures alignment between stakeholders and developers on the feature’s purpose before any design work begins.

design.md outlines the technical architecture: components, data models, interfaces, API contracts, and integration points. It serves as a blueprint for implementation and is generated by the AI after the requirements are reviewed and approved by the developer.

tasks.md breaks the design into an ordered checklist of discrete coding tasks. Each task builds upon the previous ones and is specific enough that an AI assistant or human developer can execute it independently. Tasks can be tracked as in-progress or completed, providing real-time implementation progress.

Workflow

The workflow enforces a sequential discipline: requirements are defined and reviewed, then design is generated and reviewed, then tasks are generated. Only after all three documents are validated does implementation begin. At each stage, the developer can provide feedback and iterate before proceeding. This upfront investment in specification typically reduces rework during implementation, as ambiguities and design conflicts are surfaced early.

During implementation, Kiro includes all three spec files as context in every AI interaction, ensuring generated code aligns with documented specifications. The #spec command in Kiro’s chat interface explicitly loads spec context into the conversation.

Beyond Kiro

The spec-driven pattern is not exclusive to Kiro. GitHub’s Spec Kit and the BMAD-METHOD implement similar structured specification workflows [4]. The pattern is broadly applicable to any AI-assisted development workflow where providing structured context to the AI meaningfully improves output quality. The key insight is that the cost of writing a specification is repaid many times over in reduced iteration cycles, fewer misaligned implementations, and better AI-generated code.

Sources

  1. Hoare, C.A.R. (1969). “An Axiomatic Basis for Computer Programming.” Communications of the ACM, 12(10), 576-580.
  2. Kiro Documentation. “Specs.” https://kiro.dev/docs/specs/
  3. AWS re:Post (2025). “Kiro Agentic AI IDE: Beyond a Coding Assistant.” https://repost.aws/articles/AROjWKtr5RTjy6T2HbFJD_Mw/
  4. Fowler, M. “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl.” https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html