Spec-Driven Development in the age of AI coding assistants

AI coding assistants made writing code cheap. They did nothing to make deciding what to build cheap. If anything, the gap got wider: an assistant can produce a working feature in minutes, and if the requirements were vague, you now have a confident, well-structured implementation of the wrong thing. That is why I think Spec-Driven Development matters more with AI coding assistants than it did before them.

I drove SDD adoption on my team, where I lead 7+ engineers and own the backend, infrastructure and CI/CD. I covered the original reasoning in Spec-Driven Development: what it is and why I rolled it out. This post is about what changes when part of the implementation is done by an assistant or an agent.

Assistants amplify whatever you give them

A human engineer who hits an ambiguous requirement usually stops and asks. An assistant fills the gap with the most plausible guess and keeps going. Plausible guesses are the dangerous kind, because they survive a quick glance in review.

So the quality of the input sets the ceiling on the quality of the output. A clear spec turns an assistant into a fast, reliable implementer. A one-line ticket turns it into a generator of reasonable-looking assumptions that someone has to find and unwind later.

The spec was always the cheapest place to make decisions. With assistants in the loop, it is also the prompt.

Numbered specs, and amendments for change

The workflow I use is simple and strict about one thing: every change traces back to a spec.

• A new feature gets a new spec, with a number. The number is how everyone refers to it: in the branch name, the PR, conversations and the assistant's context.
• A change to something that already shipped amends the spec that owns it. It keeps the same number and gets an amendment section. The flow keeps one history in one place.
• One branch per spec, named after it. Reviewers know from the branch name which document to open.

I worked this way on the in-app AI assistant for the Recond Flutter app. The base behavior lives in numbered specs: streamed replies, cards for records with an Open button, a confirm-or-cancel card when the agent proposes creating a record. When a detail changed, for example making sure a cancelled create card stays cancelled, it went in as an amendment to the spec that owns that flow. Whenever someone asks later, the answer to "why does it work like this?" is one document away.

Amendments matter more with assistants for a practical reason. When an agent works on a flow, you hand it the spec that owns that flow. If the latest behavior is scattered across closed tickets, the agent works from a stale picture and "fixes" things back to how they used to be.

Conventions belong in the agent's context too

A spec says what to build. Team conventions say how this team builds anything: naming, branch and PR workflow, comment style, which tools to use for testing. Assistants follow neither unless you give them both.

My team's conventions are served to AI coding agents from a conventions server, an MCP server grouped by platform (backend, frontend, Flutter, integrations, shared). It carries rules like spec-first development, branch-per-spec naming, the PR workflow and comment style. Before an agent writes code, it pulls the conventions for the platform it is working on. That keeps the rules in one maintained place, and every engineer's assistant reads the same version. I go deeper on that setup in making team conventions machine-readable for AI agents.

The spec-first loop with an assistant

Day to day, the loop looks like this:

1. Settle the spec first. New feature, new spec. Change to a shipped flow, find the owning spec and amend it. The assistant can help draft, and a person approves.
2. Branch from the spec number. Everything for that spec lives on that branch.
3. Hand the agent the spec plus conventions. The prompt is short, because the spec carries the detail.
4. Review against the spec. The reviewer's question stays the same whoever typed the code: does this match what we agreed?
5. Update the spec if reality changed. If implementation revealed something, the spec gets amended before merge, so the document stays true.

Step four is where SDD protects quality. Without a spec, reviewing assistant output turns into reading a lot of plausible code and trying to reconstruct intent from it. With a spec, review is a comparison.

What changes for the people

The engineer's job shifts toward the parts assistants are weakest at: resolving ambiguity, choosing trade-offs, spotting the edge case nobody wrote down and judging whether the result is actually right. Writing a good spec is a senior skill, and it is now the skill that most directly decides how useful the team's tools are.

It also changes what "fast" means. Generating code is rarely the bottleneck anymore. Rework is. A team that settles intent before implementation spends less time throwing away code, human-written or generated. If you want to see how I write specs an agent can follow without guessing, I break down the structure in writing specs that AI coding agents can actually follow.

The short version

AI coding assistants raise the value of a clear spec, because they execute ambiguity at full speed. Number your specs, amend them when shipped behavior changes, name branches after them, and give the agent both the spec and the team's conventions. Then review the result against the spec, the same way you would review a person's work.