The Best Spec-Driven Development Method: Inside SPEED (And How We Use It to Build SQUEIL)

Ask ten teams what spec-driven development means and you will get ten answers that all sound right, and all end the same way: a beautifully structured spec, generated in about ninety seconds, that nobody opens again after the third pull request.

That is not a tooling problem. Every SDD tool on the market can produce a requirements document, a design document and a task list, and most of them do it well. The question none of them answers on its own is the one that decides whether the method holds:

When the code and the specification disagree six weeks from now, which one is wrong?

If the honest answer is "the spec, obviously — it is out of date," then you are not doing spec-driven development. You are doing documentation with extra steps, and you will get documentation's results.

The best spec-driven development method is the one that can answer that question the other way and then survive being taken seriously. This is a field guide to what that takes, a test you can run against any SDD framework you are evaluating, and an honest account of the method we use ourselves — including the part we do not publish.

What SDD is actually promising

Strip the tooling away and spec-driven development makes one claim: the specification is the authoritative artifact, and the code is its compiled form. Everything people like about SDD — fewer iteration cycles, AI coding agents that stay on task, reviews that are about the right thing — is downstream of that one claim being true.

It is a big claim, and it is much harder to keep than to make. If you are new to the idea, start with Spec-Driven Development Explained and the SDD pipeline lesson; this post assumes you already know the shape and want to know which shape is worth adopting.

Four ways spec-driven development quietly stops being spec-driven

Almost nobody abandons SDD. What happens instead is that it decays, in four recognisable moves, and every one of them looks reasonable on the day it happens.

1. The spec becomes a draft. Someone ships a fix directly, with a note to "update the spec later." Nothing breaks. The next person does it twice. Within a month the specification describes a system that no longer exists, and the only reliable description of the product is the code — which is exactly the state SDD was adopted to escape.
2. The gate is somebody's attention. Quality is "enforced" by a reviewer who is thorough on Tuesday and underwater on Friday. A gate that depends on how busy a human is has not been implemented; it has been hoped for.
3. Context dies at the handoff. The work pauses. It resumes next week, or with someone new, and the first two hours go into reconstructing what was already known and verified. Multiply that by every pause in a quarter. This is the single most expensive line item in most engineering organisations and almost nobody measures it.
4. Automated contributors are trusted on different terms than human ones. An agent's output gets waved through because it looked confident, or blocked on principle because it came from a model. Either way the gate is now about who produced the work rather than whether it passes — and the moment that is true, your quality bar is a social convention.

Notice what none of these are: a missing template. You cannot fix any of them by generating a better document.

A test you can run on any spec-driven development method

Before you adopt a framework — ours or anyone else's — run it through five questions. They are short, they are uncomfortable, and they sort serious methods from repackaged templates faster than any feature comparison.

1. Authority. When the spec and the code disagree, which one is the defect? If the method does not answer this in one sentence, it has no position, and the code will win every argument by default.
2. Mechanism. Is quality enforced or inspected? Enforced means a check runs and can refuse. Inspected means a person reads it and feels good about it. Taste is coaching; it is not validation.
3. Order. Can a stage be skipped? What happens when someone tries? A pipeline where every stage is optional under pressure is not a pipeline — it is a suggestion, and pressure is exactly when you needed it.
4. Continuity. Can a competent stranger resume this work on Monday from what is written down? Not "could they figure it out" — could they resume, from a known state, without an archaeology session?
5. Symmetry. Does work from an automated contributor pass the same gates as work from a human? If the answer differs by author, you do not have a quality bar. You have a reputation system.

Any method that answers all five is worth your time. Most answer one or two, and the gap between them is not a matter of taste — it is the difference between a method that compounds and a method that decays.

SPEED: one rule, and everything else follows from it

SPEED — Structured Parallel Engineering for Evolved Deployment — is the methodology DevForge Academy teaches and SQUEIL runs on. It is a way of delivering software in which the specification is the authoritative artifact, quality is enforced mechanically, and every cooperating role — human, automated, or both — coordinates through explicit information boundaries.

It has one rule, and the rule is the entire argument:

When the specification and the code disagree, the specification is correct and the code is the defect.

Read that as an operating instruction rather than a slogan, because it costs something. It means the one-line hotfix you just shipped is, formally, a defect until the specification says it is behaviour. It means "we will document it later" is not a shortcut but a known break. Teams who adopt SDD and then quietly exempt small changes have not adopted a lighter version of the method; they have adopted the failure mode, on day one, by consent.

What you buy for that price is the thing every other benefit hangs off: a written artifact that is worth reading because it is true, and stays true because nothing is allowed to make it false without a record.

What the five letters carry

• Structured — explicit, not tribal. Decisions, roles and artifacts are named and bounded. Knowledge that lives only in someone's head is a single point of failure that goes on holiday.
• Parallel — built for concurrent work on one governed foundation. Not "we have many contributors," but "many contributors can act at once without colliding, because the boundaries are written down."
• Engineering — measurements, gates and repeatable technique, not improvisation. If the outcome depends on who happened to do it, it is craft, not engineering.
• Evolved — change is expected, governed, and recorded so it can be revisited. A method that treats change as an exception will be wrong within a quarter.
• Deployment — the goal is deployed, operating, observable software. Not a merged branch, not a demo, not a green board.

Why it exists now, specifically

SPEED is not a rebranding of something that worked in 2012. Three conditions changed at once, and each of them breaks a practice that used to be adequate:

• Distributed cooperation. Contributors rotate and are rarely co-located, so tacit understanding cannot be shared. Written specifications become the coordination layer — not because writing is virtuous, but because there is nothing else in the room.
• Automated contributors. Generators, validators and planners hold no tacit knowledge at all. They need explicit, machine-readable specifications to do useful work. This is the part most teams discover the hard way when their AI coding tool confidently builds the wrong thing from a prompt that a human colleague would have queried.
• Elevated accountability. Partners, auditors and customers now expect traceability: which decision authorized this behaviour, and why. "It evolved" is no longer an acceptable answer to a procurement question.

How work moves: five tiers of specification, three gates

This is the part that turns a principle into a pipeline. Specification is not one artifact; it is five, each with a different job and a different lifetime. The order is fixed and no stage is skipped.

• T1 · Charter — sovereign direction and scope. What this program is for, and what it will not do.
• T2 · Canon — living architecture and authoritative terms. The shared vocabulary and structure everything else must conform to. See Canon Management.
• T3 · Feature — locked acceptance criteria. "Locked" is load-bearing: criteria that move during implementation are not criteria.
• T4 · Execution — the bounded unit of work. Small enough that its completion is not a matter of opinion.
• T5 · Gate — executable quality checks. Specification of what must be mechanically true, written as a specification tier rather than bolted on at the end. This is what Quality Arbitration is about.

Against those, three gates:

• G1 · Structural — does it conform to canon?
• G2 · Functional — does it do what it claims?
• G3 · Operational — is it safe to release?

The ordering is not decorative. Cheapest checks run first, so most defects are caught before the expensive ones are invoked — there is no reason to spend a full functional suite on something that already violates canon. And the enforcement rule is the one that separates this from a checklist:

No artifact progresses past a failing gate. An exception is a governed decision with a record, an owner and a remediation plan — never a silent bypass.

That sentence is the answer to question 3 of the test above, and it is the sentence most methods cannot write, because in most methods the exception path is "ask the lead," which leaves no record and no owner.

The Pentorb: five capabilities, and why the average is the wrong number

Principles are asserted. Capabilities are exhibited. You can claim a principle in a wiki page; you cannot claim a capability, because a capability is something an implementation either demonstrably shows or does not.

SPEED names five, collectively the Pentorb:

• Leverage — find the point where governed effort moves the outcome most, and apply it there.
• Continuity — capture verified state so work resumes with full context.
• Legibility — render the system so time-poor people can read it and act.
• Trust — checks, balances and boundaries; trust granted only as it is earned.
• Tempo — iterate as fast as delivery allows while humans hold the gates that matter.

Each capability is a precondition for the next, and the loop closes one level higher: faster passes reveal where leverage has moved. And then the assessment rule, which is the most useful single idea in this whole post for anyone running a team:

A program is assessed at its weakest capability, never the average.

A team with world-class tempo and no continuity is not an above-average team. It is a team that is fast until the first handoff, and then it is a team that is slow and surprised. Averaging capabilities is how organisations talk themselves out of noticing the one thing that is actually costing them.

Seven of the fourteen principles

The body of knowledge carries fourteen. Seven of them do most of the day-to-day work, and they are the ones printed on the public spec sheet:

• P1 — The specification is authoritative. The code is its compiled form.
• P2 — Specifications precede code. For a one-line fix as for a new subsystem. The exemption you grant for "small" changes is the crack the whole thing leaks through.
• P3 — Quality is enforced at every boundary, not inspected at the end. Defects are caught close to where they entered, which is also where they are cheapest to understand.
• P5 — Validation is mechanical, not opinion. Taste is coaching. Coaching is valuable; it is not a gate.
• P6 — Context is preserved across sessions. Amnesia is a defect. Not an inconvenience, not the cost of doing business — a defect, with an owner, like any other.
• P10 — Decisions are captured as records. The program's long-term memory. A decision nobody can retrieve was a conversation, not a decision.
• P11 — A trained human remains in the loop at every irreversible boundary. Note the precision: not every boundary. Every irreversible one. This is what makes high automation and high safety compatible instead of opposed.

P6 and P11 are the two that people underestimate. P6 is what makes AI-assisted work economically different rather than just faster — see steering files and project memory for the mechanical version. P11 is what lets you run aggressive automation without lying awake, and it is the principle that agentic delivery lives or dies on.

The seven knowledge areas

SPEED organises practice into seven areas. The first five form the forward pipeline of governed delivery; Governance and Observability form the learning loop that keeps the program improving rather than merely producing.

• Canon Management — canonicalization, review, decision capture, glossary, cross-reference verification
• Spec Engineering — authorship, scoping, drafting, linking, validation framing, lifecycle stewardship
• Flight Execution — cycle planning, synchronization, progress tracking, review, retrospection
• Quality Arbitration — gate specification, implementation, operation, failure analysis, maintenance
• Release and Deployment — release planning, environment promotion, execution, post-release observation, rollback
• Governance and Compliance — decision records, steering-file discipline, drift monitoring, attestation, authority accounting
• Observability and Run Events — event specification, signal capture, baselines, anomaly detection, feedback distribution

That two of the seven exist purely to feed learning back into the other five is the structural difference between a delivery process and a program that gets better at delivering. Most frameworks stop at the pipeline.

What SPEED is not

Worth stating plainly, because every methodology gets mistaken for the nearest thing people already have:

• It is not a project-management technique grafted onto engineering.
• It is not a documentation standard.
• It is not a productivity system.
• It is not a compliance checklist.

It is a way of thinking about delivery; the practices follow from it. If you adopt the artifacts without the one rule, you will get the overhead and none of the return, and you will reasonably conclude that spec-driven development does not work.

How we use it to build SQUEIL

SPEED and the SPEED Body of Knowledge belong to SQUEIL LLC, and SQUEIL Ops is the delivery system we actually run on. It is built with SPEED, by the people who wrote SPEED, which means it is also where the method gets tested against reality rather than against a whitepaper — and where it gets to be wrong in public to us before it is ever wrong in public to you.

Here is the shape of it, which is public:

Work is routed to the specialist that suits it, acted on only once the state it depends on has been verified, and put through a gate that can refuse before anything reaches a customer. The model behind any single role can be swapped without touching the system around it — which is what keeps the standard a property of the system rather than of whichever model is current this quarter. You can see the figure and the longer statement of the standard on our engineering standard page.

Three consequences of running your own methodology on your own operation are worth naming, because they are the ones that generalise:

• The gates are written as specifications, then implemented as programs. T5 is a specification tier, not a CI afterthought. A check that has never been observed failing is not yet a check — it is a hope with a green tick, and every gate we ship has a control that has been watched to fail on purpose.
• A claim about state is not the same as state. "RLS is enabled on every table" is a claim. Reading the live catalog is state. We have had documentation confidently assert the opposite of what the system was actually doing, and the only thing that caught it was a discipline of verifying before asserting rather than after being contradicted.
• Amnesia is treated as a defect, so sessions are designed to end well. The expensive part of distributed, partly-automated delivery is not the work; it is the reconstruction. P6 is a budget line.

The part we do not publish, and why

The methodology is public. The body of knowledge is intended for publication, the spec sheet below is a free download, and the seven knowledge areas are open to read with nothing held back.

What is not public is the run-level detail of SQUEIL Ops itself: the specific orchestration, the internal canon records, and how a tenant system gets built end to end. That material is released to contracted implementors under an agreement, and it stays there.

We would rather say that plainly than pretend the public material is the whole thing. It is not mystique — the honest reason is that how we run it is operational detail specific to our contracts and our clients' systems, and publishing it would turn a methodology you can adopt into a product tour you cannot. The method transfers. Our implementation of it is ours.

Which is also why the five-question test earlier in this post matters more than any vendor's feature list: you do not need our pipeline. You need a method that can answer those five questions, and then the discipline to not grant yourself exceptions.

Adopting the method on Monday, without adopting our tooling

If you take nothing else from this, take these five. None of them require a purchase, a platform, or permission.

1. Write the authority rule down and put it where arguments happen. One sentence, in the repository, in the contributing guide, at the top of the review template: when the spec and the code disagree, the spec is correct and the code is the defect. Half the value is that it becomes a thing someone has to argue against rather than a thing someone has to argue for.
2. Pick one boundary and make its check mechanical this week. One. Not a quality initiative — one check, that runs, that can refuse. Then confirm you have watched it fail on purpose, because a gate nobody has seen refuse anything is indistinguishable from a gate that is wired to nothing. We have shipped that exact defect and caught it in our own audit.
3. Give exceptions a record, an owner and a remediation plan. You will need exceptions. The rule is not "never bypass a gate," it is "never bypass one silently." A bypass with a name on it and a date gets fixed; a bypass with neither becomes the architecture.
4. Treat the end of a work session as a deliverable. What was verified, what state it is in, what the next person needs. If resuming costs two hours, that is not a personality trait of your team — it is an unpriced defect you are paying for every single week.
5. Run agent output and human output through the same gate. Identical bar, identical checks, no exemption in either direction. This is the cheapest way to make AI-assisted delivery safe, and it is the one most teams skip because the asymmetry feels like caution. It is not caution; it is an unmeasured quality bar. Our TDD with AI coding tools and agent guardrails posts go into the mechanics.

Do those five and you will be running most of the value of a spec-driven method before you have chosen a single tool — and you will be in a far better position to judge the tools, because you will know what you need them to do.

The one-pager

The whole methodology fits on one sheet. It is free, it is the real one, and it is designed to be printed and put on a wall rather than filed.

Download the SPEED one-pager (PNG) — SPEED Methodology Body of Knowledge, Rev 2.0. No email, no form, no gate.

The sheet summarises the body of knowledge. Where the sheet and the body of knowledge disagree, the body of knowledge is correct — which is the one rule applied to the methodology's own documentation, and the only honest way to ship a summary.

Where to go next

• New to the idea? Spec-Driven Development Explained covers what SDD is and when it pays for itself.
• Want to run a spec-driven feature today? Your first spec-driven feature in 30 minutes, and Kiro files explained for the steering-file layer.
• Writing the specs themselves? User stories that actually get built, use cases vs user stories, and the plain-language advantage.
• Coming from agile? Agile in the AI era is the honest comparison, and the standard we build to is the shorter statement of the disciplines above.
• Want the whole methodology? Start at the SPEED overview and work through the knowledge areas. It is free, and it is not a trailer.

The best spec-driven development method is not the one with the best templates. It is the one that can tell you, without flinching, which artifact is wrong when two of them disagree — and then enforce that answer mechanically, at every boundary, for every contributor, including the ones that are not people.