AI Coding

Specification-Driven Development (SDD): Analysis and Insights on Kiro, Spec-kit, and Tessl

Honghao Wang

— 3 min read
Specification-Driven Development (SDD): Analysis and Insights on Kiro, Spec-kit, and Tessl 
# Understanding Spec‑Driven Development (SDD) in AI Coding

Spec‑Driven Development (**SDD**) is one of the latest buzzwords in **AI‑assisted coding**. After testing three tools that describe themselves as SDD implementations, I’ve distilled what the concept currently means in practice.

---

## What Is Spec‑Driven Development?

Like many concepts in AI‑driven engineering, the definition of SDD is evolving. Based on current usage, SDD can be summarized as:

> **Documentation‑first** coding with AI: write a structured “spec” before writing any code.  
> The spec is the **single source of truth** for both human developers and AI assistants.

### Current References

- [GitHub Spec‑kit](https://github.com/github/spec-kit/blob/main/spec-driven.md):
  > *In this new world, maintaining software means evolving specifications… Code becomes the “last‑mile” artifact.*

- [Tessl](https://docs.tessl.io/introduction-to-tessl/concepts):
  > *Specs — not code — are the primary artifact. Specs describe intent, and agents generate matching code.*

---

## Levels of Implementation

SDD can be practiced at several levels:

1. **Spec‑First**  
   Create a spec before coding; it guides the AI on a specific task.

2. **Spec‑Anchored**  
   Keep the spec after initial delivery; evolve and maintain it as features change.

3. **Spec‑as‑Source**  
   The spec *is* the authoritative source. Developers edit specs, not generated code.

**Observation:**  
All SDD approaches I’ve found are *spec‑first*, but few clearly commit to *spec‑anchored* or *spec‑as‑source* long‑term.

---

## What Counts as a “Spec”?

There’s no universal agreement on what a **spec** is. Most descriptions liken it to a **Product Requirements Document** — but with structure, behavioral focus, and intended for AI agents.

**My working definition:**

> **A spec is a structured, behavior‑oriented artifact — or set of related artifacts — written in natural language that describes functionality and guides AI coding agents.**

### Specs vs. Context

- **Spec:** Relevant only to implementing or modifying a specific feature.
- **Context (Memory Bank):** Broader, persistent documentation — rules, configs, architecture — relevant to *all* AI sessions in the codebase.  
  Example: [Memory Bank in Cline](https://docs.cline.bot/prompting/cline-memory-bank).

Maintaining this distinction helps with **clarity and maintainability**.

---

## Evaluating SDD Tools

Testing SDD tools realistically is time‑consuming:

- Requires trying greenfield & brownfield projects.
- Needs deeper artifact review, not just surface runs.
- Integration into existing code is often labor‑intensive.

Many open questions remain without long‑term usage reports from real teams.

---

## Tool Overviews

### 1. [Kiro](https://kiro.dev/)  
**Workflow:** Requirements → Design → Tasks  

- **Spec‑First focus.**  
- Requirements formatted as *User Stories* (**As a…**), with acceptance criteria (**GIVEN… WHEN… THEN…**).
- Guides you through 3 Markdown docs inside VS Code.
- Uses a “**memory bank**” called *steering*, with optional docs (`product.md`, `structure.md`, `tech.md`).

**Strengths:** Simple, lightweight structure.  
**Weaknesses:** Can feel verbose for small fixes.

---

### 2. [Spec‑kit](https://github.com/github/spec-kit) — GitHub CLI

**Workflow:** Constitution → Specify → Plan → Tasks  

- CLI sets up workspaces for coding assistants.  
- **Constitution** = immutable high‑level principles applying to every change.  
- Produces many interconnected files & checklists per workflow stage.
- Branch per spec suggests *task‑lifecycle*, not *full‑feature lifecycle* anchoring.

**Strengths:** Highly customizable; integrates “living” specifications.  
**Weaknesses:** Verbose output; better suited for larger tasks.

---

### 3. [Tessl Framework](https://docs.tessl.io/introduction-to-tessl/quick-start-guide-tessl-framework) *(Private Beta)*

**Workflow Goal:** Spec‑anchored; exploring **spec‑as‑source**.

- CLI + MCP server; can reverse‑engineer specs from code.
- One spec = one code file mapping (for now).
- Generated code marked:

// GENERATED FROM SPEC - DO NOT EDIT

- Experimenting with more complex mappings in future.

**Strengths:** Clear spec‑to‑code link; potential for true spec‑as‑source.  
**Weaknesses:** Limited abstraction; non‑deterministic outputs can occur.

---

## Observations and Questions

- SDD is **not** a uniform methodology.
- Tools often have **opinionated workflows** — may not fit all problem sizes.
- Potential **overkill**: small fixes can balloon into multiple stories & markdown files.
- Reviewing spec docs can be more tedious than reviewing code.
- **Core needs for effective SDD tools:**
  - Flexible workflows for different change sizes.
  - Efficient spec review process.

---

## Key Challenges

### Matching Tool to Problem Size
Heavy workflows on small tasks waste effort.

### Markdown Review Fatigue
Excessive, repetitive artifacts slow down work.

### False Sense of Control
LLMs can still ignore, misinterpret, or over‑apply specs despite larger context windows.

### Iteration vs. Overplanning
Up‑front verbose specs clash with agile, iterative feedback loops.

---

## Separating Functional vs. Technical Specs

- The goal: tech stack independence by having AI fill solution details from **functional specs**.
- Reality: difficult to maintain a pure functional layer — boundaries are fuzzy.

---

## Who Is the Target User?

- Many SDD demos assume developers can handle requirements analysis roles usually performed by product managers.
- Likely best for **small to medium tasks** with clear goals — not ambiguous large features.

---

## Lessons from Past: MDD Parallels

- **Model‑Driven Development (MDD):** Specs were models (UML, DSL), generated into code.
- MDD’s overhead & abstraction limited adoption.
- LLMs reduce some overhead — but add **non‑determinism**.
- Spec‑as‑source could inherit **MDD inflexibility** plus LLM unpredictability.

---

## Conclusions

- **Spec‑First** can be valuable — structure matters.
- “Spec‑Driven Development” is loosely defined; often used interchangeably with “detailed prompting.”
- Beware **semantic diffusion**: term losing precision.
- Over‑complicated processes risk becoming *Verschlimmbesserung* — making it worse while trying to improve.
- Effective SDD adoption will require:
  - Clear spec definition.
  - Scalable workflows.
  - Pragmatic integration with existing dev practices.

---

**Final Takeaway:**  
SDD offers promise — but must balance **structure** with **agility**. Tooling should fit task size, streamline review, and let teams iterate without excessive upfront overhead.

Read more