When the agent writes the code, your highest-leverage artifact is no longer the code. It is the spec it builds from.
TL;DR
- Spec-driven development means the specification is the primary artifact; code is generated from it.
- Good agent specs are precise about behavior, constraints, and acceptance criteria.
- Teams report restructuring around this — a handful of humans directing several agents.
- The spec doubles as the verification checklist.
Why specs are back
For years "write a spec first" was advice everyone nodded at and few followed — by the time you finished, the code had moved on. Agents change the economics. If an agent can implement a well-written spec in minutes, the spec stops being overhead and becomes the leverage point. Some teams have restructured entirely around this: a few engineers writing and reviewing specs, several agents implementing them, output multiplied.
What separates a buildable spec from a wish
An agent cannot read your mind, and unlike a senior colleague it will not push back when something is underspecified — it will guess. A buildable spec closes those gaps:
- Behavior, not vibes. "Validate the email" → "Reject inputs that fail RFC 5322; show the error inline below the field; do not block submit of other fields."
- Explicit constraints. Which libraries are allowed, what patterns to follow, what not to touch.
- Acceptance criteria. The concrete conditions that mean "done" — ideally expressible as tests.
- Edge cases named up front. Empty states, failures, limits. The places an agent silently guesses are exactly where it guesses wrong.
## Feature: Bulk archive
### Behavior
- User selects 1+ rows and clicks "Archive".
- Archived rows leave the active list and appear under "Archived".
- A single undo toast appears for 8 seconds and reverses the whole batch.
### Constraints
- Reuse the existing `useSelection` hook. No new state library.
- Optimistic update; reconcile on server response.
### Acceptance
- [ ] Selecting 0 rows disables the Archive button.
- [ ] Undo within 8s fully restores all archived rows.
- [ ] A failed server call rolls back the optimistic change and surfaces an error.
A spec vague enough to be quick to write is vague enough for an agent to get wrong. The precision you skip becomes the bug you debug.
The spec is also the test plan
The acceptance criteria are not just instructions for the agent — they are how you verify what it produced. Write them as checkable conditions and you get a review checklist and, often, a literal test suite for free. This is the discipline that keeps agentic delivery from becoming "merge it and hope."
Where humans stay essential
Spec-driven development does not remove engineering judgment; it concentrates it. Deciding what to build, what the constraints are, and what "correct" means is harder and more valuable than typing the implementation. The agent handles the how. You own the what and the proof.
Write the spec like the agent will build exactly what you said — because it will.