Spec-Driven Development Is Simpler Than You Thought
Spec-driven development usually arrives as a framework: a sequence of phases, a command for each, templates, a governing document, and the assumption that one developer drives one agent through one repository. Seen that way, it looks like a heavy process to adopt – and for a team with its own tracker, its own roles, and dozens of services, adopting it that way is heavy and often unnecessary.
Under the packaging, SDD is a handful of ideas. My team runs it without a framework. I designed the process around those core ideas; the team adopted it, and five months later it is simply how we work – a team lead, two engineers, a PO/BA and two QA engineers, responsible for 80+ microservices. Agents write every document; people decide, direct each stage, and take responsibility for the result. Two things made it simple: an AI-native meta-repo, where the agent sees the whole system at once, and a triage step that keeps most work away from specifications altogether.
It isn't free. A home-grown process has no community or upgrade path behind it. It fits one team's context rather than every team's, and it leans on the workspace – without one, it becomes considerably heavier.
This piece is the argument, with my team's version as the example. The mechanism, decision by decision, is in RA-005.