Spec-driven development

The idea is older than coding agents. Design by contract, model-driven engineering, behaviour-driven development with Given/When/Then scenarios and test-driven development all tried to make an explicit, checkable statement of intent precede or govern the code. What changed in 2025 is the consumer of the specification: a coding agent that will implement whatever it is told, quickly and confidently, so ambiguity in the request turns directly into plausible but wrong software. Writing the spec forces decisions about scope, edge cases, error handling and non-functional requirements before thousands of lines exist that embody the wrong ones.

Two tools shaped current practice. GitHub's open-source Spec Kit, announced in September 2025, provides a CLI named specify and a set of agent slash commands that walk through a fixed sequence: a project "constitution" of non-negotiable principles, a feature specification (spec.md) focused on what and why, a technical plan (plan.md) choosing architecture and stack, a task breakdown (tasks.md), and implementation task by task. Amazon's Kiro IDE, launched in 2025, structures each feature as requirements (user stories with structured acceptance criteria), a design document and a task list traced back to requirement numbers, plus "steering" files that hold standing product and technology context. Both treat Markdown artefacts under version control as the durable interface between people and agent.

Birgitta Böckeler's October 2025 analysis on martinfowler.com distinguishes three levels. Spec-first writes a spec before the work and may discard it afterwards; spec-anchored keeps the spec and evolves it with the feature; spec-as-source makes the spec the only artefact humans edit, with code regenerated from it. She also recorded the main criticisms: generated specs can be longer and more tedious to review than the code, a single workflow imposes the same ceremony on a one-line bug fix as on a new feature, agents still ignore or misread instructions despite elaborate templates, and spec-as-source risks repeating the failures of model-driven development with added non-determinism.

Done well, the spec is where security and compliance requirements become testable. Threat-modelling outcomes, data-protection constraints and acceptance criteria such as token lifetimes or rate limits can be written as explicit requirements that tests verify and reviewers check, which aligns with NIST SP 800-218's practice of defining security requirements for software development (PO.1). The spec does not remove the need to review code; it gives the reviewer a reference against which divergence can be detected, and it must itself be kept current, since a stale spec misleads the agent as effectively as a missing one.