Spec-Driven Development: From Prompting to Controlled Delivery
AI can produce code faster than most teams can decide what the code should do, and that moves the bottleneck. An unclear requirement used to be resolved quietly while a developer coded; now it becomes twenty files of confident misunderstanding. Spec-driven development is a family of practices that makes intent durable, reviewable and testable. This nine-part series explains what it changes, how GitHub Spec Kit, BMAD, Kiro, OpenSpec, intent architecture and harness engineering differ, what a useful specification contains, how teams and agents share the work, four worked examples, enterprise governance, and a practical adoption playbook with the failure modes to avoid. One fictional South African insurer carries the examples throughout. Written for technology leaders, product owners, architects, engineers, QA and security teams.
9 articles
- Part 1The code is no longer the first hard problemWhen a coding agent can change twenty files in minutes, an unclear requirement becomes twenty files of confident misunderstanding. Part 1 explains what spec-driven development changes, what counts as a specification, and how much of it a change really needs.8 min read
- Part 2Spec Kit, BMAD, Kiro, OpenSpec and the rest: the flavours of SDDAsk five engineers what spec-driven development means and you will hear about five different tools. Part 2 explains what GitHub Spec Kit, the BMAD Method, Kiro, OpenSpec, intent architecture and harness engineering each actually do, and why they combine rather than compete.10 min read
- Part 3Anatomy of a useful specificationA useful specification is not long. It states the problem, draws the boundary, shows the behaviour through examples, turns vague qualities into numbers someone can test, and is honest about what is still unknown. Part 3 takes one real-shaped spec apart, section by section.9 min read
- Part 4Intent architecture: from company purpose to one line of codeLarge systems rarely drift because of one bad decision. They drift because a local change quietly weakens a rule nobody put in front of the person, or agent, making it. Part 4 shows how to layer intent so every task inherits exactly the slice it needs, and how to tell the two kinds of drift apart.9 min read
- Part 5Harness engineering: the workshop around the agentA good specification tells a coding agent what to build. It does not stop the agent reaching production credentials, breaking a boundary or declaring victory on a change nobody can prove. Part 5 covers the harness: the instructions, tools, sandboxes, checks and review gates that turn an agent’s speed into controlled delivery.9 min read
- Part 6AI changes responsibilities, not accountability: team structures for SDDAn agent can draft a requirement, an architecture option or a test. It cannot accept a risk on your organisation’s behalf. Part 6 sets out who owns which decisions in spec-driven delivery, how agents fit as bounded functions rather than pretend employees, three team shapes, a RACI for a material feature, and how to run agents in parallel without chaos.9 min read
- Part 7Four worked examples: greenfield, brownfield, a small defect and an AI featureSpec-driven development should change shape with the work. Four examples from one fictional insurer show what a specification looks like for a new service, a change to an old monolith, a two-hour defect and an AI feature that touches health information.11 min read
- Part 8Govern decisions and evidence, not document volumeEnterprise spec-driven development fails when governance counts completed templates instead of checking whether intent, design, code and runtime evidence agree. Part 8 covers ownership, lightweight traceability, risk-tiered gates, security in the spec, change control and the metrics worth tracking.9 min read
- Part 9Adopting SDD: a playbook, a starting point and the failure modesDo not start spec-driven development with an enterprise mandate and forty templates. Start with a baseline and one real product slice, build the minimum system, run the loop, then scale what worked. The final part of the series adds a reference operating model and the twelve ways adoption goes wrong.10 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala