On this page

Related reading

← RCF

Concept

RCF and spec-driven development

Spec-driven development (SDD) generates code from a specification. RCF derives that specification from requirements and verifies code against acceptance tests. SDD fits inside RCF’s Build stage.

Last updated

SDD treats the specification as primary. RCF treats requirements as primary, derives the specification from them and uses criterion-derived tests to assess the code.

SDD is a dominant approach to AI-assisted software work in 2026. It addresses a different part of delivery from RCF, despite their shared vocabulary. This page explains that distinction and when each approach fits.

What is spec-driven development?

Spec-driven development treats a written specification as the primary artefact, with the code as a regenerable output. The spec is the place intent lives. Tooling around it validates, regenerates, and traces. When the spec changes, the code follows. When the spec is right, the code is right by construction. The agent has a precise target to aim at, instead of inferring intent from a chat thread.

Several published tools use this approach. GitHub Spec Kit ships as a first-party toolkit. Martin Fowler is publishing on it, surveying Kiro, Spec Kit, and Tessl as three approaches to SDD tooling. AWS shipped Kiro as an agentic IDE built around the idea. Tessl has gone the furthest, treating the spec as the source artefact and the code as a derivable output. BCMS positions SDD explicitly as the answer to the vibe-coding failure mode, where agents produce plausible code that drifts from intent.

Treating code as regenerable output gives agents an explicit target. SDD provides useful structure for teams building with agents.

How is RCF different from spec-driven development?

RCF treats requirements as the source of truth and the spec as a downstream artefact derived from them. The order matters. A spec answers “what does the software do?” A requirement answers “what do we need the software to do, and why?” The second question contains the first. The reverse isn’t true.

SDD specifications often use YAML, structured prompts or configuration documents. These are suitable agent inputs, but do not themselves establish business needs. Priorities, constraints and scope need decisions above the specification. Code can match a specification that describes the wrong product.

RCF answers that question by putting the PRD at the top of the chain and requirements one layer below it, with stories, acceptance criteria, and test cases descending from there, and the code that satisfies each criterion tied back into the same graph. Each layer points up to what justifies it and down to what proves it. The document chain is the chain. The build cycle is how work moves through it. The spec, in the SDD sense, slots in as one artefact among several, somewhere between functional build specifications and the test suite. It is derived from the upstream requirements.

The practical difference: RCF gives you a chain that survives change. When a stakeholder asks why a feature exists, the chain answers. When a requirement changes, traceability makes the impact mechanical. The spec-as-primary version of this is harder, because a spec change doesn’t carry the “why” with it, and the chain back to business intent has to be reconstructed from outside the toolchain.

When SDD is the right reach

SDD alone can be appropriate in the following cases.

A small team may already share stable requirements and write the code themselves. A separate PRD and requirements process can add cost with little benefit. SDD provides a lighter structure for agent-assisted implementation.

SDD suits a bounded service, library or backend whose specification can drive regeneration. Workflows such as Tessl treat code as derived output. Additional methodology may offer little value for code treated as disposable.

SDD can be sufficient for experiments and disposable prototypes. RCF can also use sparse, short requirements while the product is being explored. Scale requirements to what is known and expand them when the prototype becomes a product.

When RCF is the right reach

RCF targets enterprise delivery where the goal is reliable automation from agreed requirements to software. The requirements layer supplies the decisions that the automation must follow.

When a team cannot justify generated code, AI drift may originate above the build. The agent may follow a specification that fails to represent the actual need. RCF links the build back to those business decisions.

When requirements change as stakeholders see the product, the living spec process applies. RCF records change in requirements and stories, above the build specification. It preserves the reasons while requested behaviour changes, supporting automation under enterprise change.

If your organisation has multiple stakeholders, regulated obligations, or audit requirements that need a defensible chain from business decision to running test, the spec-as-source approach doesn’t give you a defensible chain on its own. You can build one on top of SDD tooling, but you’ll be reinventing the requirements layer to do it. That’s the layer RCF starts from, which is why it’s the right reach for organisations that take ownership of intent, not just output.

RCF’s explicit handoffs help when different people write requirements and specifications, with agents implementing code. The acceptance criterion connects business intent to verifiable behaviour and gives each handoff a stable contract.

Is RCF a spec-driven development tool?

No. RCF is requirements-first; SDD is spec-first. RCF uses SDD’s mechanism inside exactly one stage of its build cycle, Build, where an agent generates code against a precise spec, and keeps the criterion-derived tests as the authority on whether the output is right.

How does RCF compare to Spec Kit, Kiro, and BMAD?

GitHub Spec Kit, AWS Kiro, and BMAD are SDD tools: each takes a spec as the primary artefact and drives an agent against it. RCF isn’t a rival tool at that layer. It’s the requirements discipline above them: any of the three could sit in RCF’s Build stage, generating code against a spec the chain has already tied to a business decision, with the AC-derived tests as the gate.

Using them together

The cleanest way to see how they fit is through the RCF build cycle. It runs in five stages: Define, Build, Review, Test, Finalise. Spec-driven development lives in exactly one of them, Build, where an agent generates code against a precise target. The other four stay RCF. Define writes the tests from the acceptance criteria before any code exists; Review checks the diff against intent; Test runs the AC-derived suite as the gate; Finalise closes the slice and updates the chain.

Spec-driven development inside the RCF build cycle A left-to-right five-stage build cycle showing where spec-driven development sits within the Requirements Confidence Framework. The five stages in order are Define, Build, Review, Test, Finalise. Four of the five stages are owned by RCF discipline and carry an RCF tag: Define (write the tests from the acceptance criteria before any code exists), Review (the diff is reviewed against intent), Test (the acceptance-criteria suite runs as the gate), and Finalise (CI green, the slice closes, the chain updates). Only the Build stage is owned by spec-driven development: it is filled in burnt orange and tagged SDD, and an agent generates code against a precise spec target. A dashed bracket arc spans from Define over Build to Test, annotated to show that Define writes the tests before Build and Test runs them after, so the Build stage is bracketed by the test contract. The takeaway is that SDD generates the code, RCF verifies it, and the test, not the spec, is the authority on whether the code is right. Define writes the tests from the acceptance criteria before any code exists; Test runs that same suite afterwards as the gate. Build sits between them, so SDD generates code against the spec but the test, not the spec, decides whether it is right. the test is the authority tests written tests run Define, RCF. Write the tests from the acceptance criteria, before any code exists. OUT: the failing test suite committed. Define tests, from AC Build, SDD lives here. An agent generates the code against a precise target, the spec or functional build specification. This is the one stage SDD owns; the test written in Define still decides whether the output is right. Build code, from spec Review, RCF. The diff is reviewed against intent: AI drift, missed criteria, sloppy code. OUT: a review commit. Review diff vs intent Test, RCF. The acceptance-criteria suite written in Define runs as the gate. This, not the spec, is the authority on whether the code is right. OUT: full-suite pass. Test suite is the gate Finalise, RCF. CI green, the slice closes, the chain updates and the build sequence advances. OUT: the slice is shipped. Finalise slice closes Spec-driven development inside the RCF build cycle (vertical layout) A vertical top-to-bottom five-stage stack: Define, Build, Review, Test, Finalise. Four stages are tagged RCF; only Build is tagged SDD and filled in burnt orange. A dashed bracket on the left links Define to Test, showing Define writes the tests before Build and Test runs them after, so the test, not the spec, is the authority. Define writes the tests before Build; Test runs them afterwards as the gate. SDD generates the code in Build, but the test, not the spec, decides whether it is right. the test is the authority Define, RCF. Write the tests from the acceptance criteria, before any code exists. OUT: the failing test suite committed. Define tests, from AC Build, SDD lives here. An agent generates the code against a precise target, the spec or functional build specification. The test written in Define still decides whether the output is right. Build code, from spec Review, RCF. The diff is reviewed against intent: AI drift, missed criteria, sloppy code. OUT: a review commit. Review diff vs intent Test, RCF. The acceptance-criteria suite written in Define runs as the gate. This, not the spec, is the authority on whether the code is right. OUT: full-suite pass. Test suite is the gate Finalise, RCF. CI green, the slice closes, the chain updates and the build sequence advances. OUT: the slice is shipped. Finalise slice closes
SDD generates. RCF verifies. The test, not the spec, is the authority.

Define establishes criterion-derived tests before Build, and Test verifies the result afterwards. Generated code must pass those tests as well as follow the specification. This retains SDD’s precise target and RCF’s independent verification contract.

The spec the agent builds from and the tests it is checked against are siblings: both descend from the same acceptance criteria. SDD builds from one, RCF tests against the other, and if the two ever diverge, that divergence surfaces at Review or Test as a signal rather than slipping through.

SDD treats code as regenerable output. RCF also registers the current implementation as Code Nodes linked to acceptance criteria. Validation checks those references against the working tree and flags links broken by renames or moves. These approaches can coexist: regenerable code can still have a checked trace to its criteria.

The SDD specification sits around the FBS, downstream of requirements and criteria. The SDD toolchain validates, regenerates and traces between specification and code without consuming the higher layers. RCF records the specification’s business decision. If the specification is wrong, its requirement is available for review.

SDD works at the specification layer. RCF supplies requirements and reasons above that layer. Together they cover generation and the justification for what is generated.

Using both adds two checks. SDD builds against the specification. RCF’s traceability and document chain connect it to the business need. Once the chain exists, the additional maintenance cost is small.

The methodology lineage places SDD among the approaches RCF inherits. It describes four decades of movement toward requirements-first work. Agent-assisted development makes that combination increasingly useful.