Spec-Driven Development

The alternative is the familiar chat loop: describe a feature in a sentence, get a block of code, find what it got wrong, ask again. Spec-driven development slows the start down. For a “export my invoices as CSV” feature, the spec says who can export, which fields appear, how dates are formatted, what happens with 10,000 rows, and how to tell it works. The agent proposes a technical plan from that, breaks the plan into small tasks, then implements and tests them one at a time.

Tools differ in the details. GitHub’s open-source Spec Kit moves through specify, plan and tasks stages with whichever coding agent a developer prefers. Kiro, from AWS, keeps requirements with acceptance criteria, a design document and an implementation task list for each feature. In both, changing the spec is the normal way to change direction.

The idea is close to a software factory, where specs and acceptance scenarios drive staged agents. In episode 76 at 5:29, Sonar CTO Andrea Malagodi describes an engineer whose workflow starts with “a level of specification” that agents break into deeper detail before writing code. Malagodi uses it to make a point about metrics, not to name the method. Episode 76 names Svix, Walrus Memory and Inngest as the season’s presenting sponsors; the Svix read is at 14:55.

A spec only helps if it is checked. Pair it with tests or evals that encode its acceptance criteria, and with review of the code that comes out. A long spec doesn’t by itself make an agent follow it; see instruction adherence. Contrast vibe coding, which steers by results instead of a written plan.