Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

• Spec-first: A well thought-out spec is written first, and then used in the AI-assisted development workflow for the task at hand.
• Spec-anchored: The spec is kept even after the task is complete, to continue using it for evolution and maintenance of the respective feature.
• Spec-as-source: The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code.

A spec is a structured, behavior-oriented artifact – or a set of related artifacts – written in natural language that expresses software functionality and serves as guidance to AI coding agents. Each variant of spec-driven development defines their approach to a spec’s structure, level of detail, and how these artifacts are organized within a project.

There is a useful difference to be made I think between specs and the more general context documents for a codebase. That general context are things like rules files, or high level descriptions of the product and the codebase. Some tools call this context a memory bank, so that’s what I will use here. These files are relevant across all AI coding sessions in the codebase, whereas specs only relevant to the tasks that actually create or change that particular functionality.