Spec-driven development: when it helps AI-assisted coding

What spec-driven development means

Spec-driven development, or SDD, uses an explicit specification to guide implementation and validation. In an AI workflow, it communicates expected behaviour to both the agent and the people reviewing its work.

Kiro organises specs into requirements or bug analysis, design and tasks. Spec Kit provides tools for working from specifications. Both structure the process; the resulting documents still require review.

When a specification earns its place

Specifications are particularly useful for business rules, multiple contributors or decisions that must remain consistent over time. A small fix may need only the current bug, expected behaviour and what should remain unchanged.

A useful specification answers:

• Which problem the change solves, and for whom.
• Which inputs and outputs are expected.
• Which limits and permissions apply.
• What happens in error cases.
• How completion will be judged.

Length is not a quality measure. More pages do not resolve contradictory requirements.

Write behaviour you can check

“Improve search” leaves too much open. “Allow exact product-reference searches and show an empty state when there are no matches” defines testable behaviour.

You still need decisions about case, whitespace, partial references and access permissions. Resolving them before implementation can reduce later changes.

Keep the specification with the code and update it when approved behaviour changes. An outdated document can misdirect people and agents alike.

What the evidence can establish

Research on AI coding productivity is not automatically evidence for or against SDD. In February 2026, METR described task and participant selection problems in its developer experiment and announced a redesign.

That distinction matters: results from particular developers, tools and repositories do not describe every team. A feeling of increased speed is not sufficient evidence either.

Test it within your team

Compare changes of similar scope. Count specification, implementation, review and correction time. Track defects, missed requirements and rework.

Choose the intended benefit in advance: less ambiguity, fewer errors or easier handover. If maintaining the document costs more than it contributes, reduce the detail.

For permanent repository guidance, see how to write a useful AGENTS.md. Feature specifications and general project instructions serve different purposes.

To try it on a real job, tell us which part of the work repeats and where the time goes.