Spec-driven development answers the wrong half of the question

If you’ve moved your AI coding from “describe it and hope” to something structured, you’ve probably landed on spec-driven development. Instead of jumping from a prompt straight to code, the work flows through a sequence: intent, spec, plan, tasks, then code. Tools like AWS Kiro and GitHub Spec Kit make that pipeline real, turning an agent’s work into something reviewable and decomposable instead of a chat log you scroll back through. It’s a genuine step up from vibe coding, and if your team has adopted it, you’ve already removed a lot of ambiguity.

But there’s a half of the problem it doesn’t touch.

A spec answers what the agent should build. It says nothing about which architectural decisions have to stay true while it builds. Those are different questions, and the gap between them is where things quietly break. An agent can satisfy every line of a feature spec and still introduce a forbidden dependency, bypass an approved abstraction, reach for a deprecated pattern, or contradict an ADR your team ratified six months ago. The spec was met. The architecture wasn’t.

That’s why a mature workflow needs one more layer. Between the plan and the agent’s execution, you retrieve the constraints that must hold: the architectural decisions, the engineering standards, the project-specific rules that live outside the spec. The agent generates inside those guardrails, and you verify against them afterward. The pipeline becomes intent, spec, plan, guardrails, execution, verification, and each stage has a job the others can’t do.

The reason this matters more as agents get better is counterintuitive. The more capable the agent, the more confidently it will produce code that satisfies the spec and violates the architecture, because it’s optimizing for the thing you gave it and blind to the thing you didn’t. Specs improve generation. Guardrails preserve architecture. You need both, and most teams have only built the first.

If you’re rolling out spec-driven development this year, the question worth asking isn’t whether your specs are good enough. It’s whether anything stops a well-specified change from quietly eroding the system it’s supposed to fit into.

I wrote the full version, with the failure modes and the workflow in more detail, here: https://mnemehq.com/insights/spec-driven-development-still-needs-governance/?utm_source=substack&utm_medium=newsletter&utm_campaign=spec-driven

That’s the layer we’re building at Mneme HQ.