RCF and spec-driven developmentCopy link

Spec-driven development (SDD) is the dominant 2026 framing for AI-assisted software work. Any methodology piece written this year has to engage with it on its own terms, which is what this page is for. The honest answer to “how is RCF different from SDD?” is that they’re addressing adjacent problems with overlapping vocabulary. They look more similar than they are, and the differences matter when you’re choosing where to spend your team’s discipline.

What spec-driven development isCopy link

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.

The category has serious backing. GitHub Spec Kit ships as a first-party toolkit. Martin Fowler is publishing on it, surveying Kiro, Spec Kit, and Tessl as three different bets on what an SDD tool should look like. 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.

None of this is wrong. The spec-as-source-of-truth idea is the right move for the moment AI stepped into the build. Treating the code as a regenerable output rather than a hand-crafted artefact is the only way agent-scale productivity becomes survivable. SDD is doing genuine structural work, and any team shipping software with agents in 2026 ought to read it carefully.

What RCF is doing differentlyCopy link

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.

In a lot of SDD tooling, the spec ends up looking like a YAML file, a structured prompt, or a config document. That’s a fine artefact for an agent to consume. It is not, in itself, a description of what the business wants. The human-judgement layer above the spec, the layer where someone decides which features matter, which constraints are load-bearing, which scope to cut, sits unaddressed. Spec-without-requirements is a faster way to build the wrong thing. The agent will produce code that matches the spec. Whether the spec matched the actual need is a different question.

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. 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’s an output of the upstream discipline, not the centre of gravity.

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 reachCopy link

Plenty of teams should reach for SDD before they reach for RCF, and pretending otherwise would be dishonest.

If you’re a small team building a single product where the requirements are stable, well understood, and largely owned by the same people who write the code, the human-judgement layer that RCF formalises is already happening in your heads. Adding the ceremony of a separate PRD and requirements layer would slow you down without buying you much. SDD’s spec-as-source-of-truth gives you the agent speed-up with the lightest framing on top.

If your codebase is the kind where regeneration makes sense, a well-bounded service, a library with a tight API surface, a backend where the spec really can drive the code, SDD’s tooling pays off immediately. Tessl-shaped workflows where the code is an output, not a kept artefact, are the cleanest expression of this. You don’t want a methodology stack on top of an artefact you treat as disposable.

And if you’re experimenting, prototyping, or in the discovery phase of a new product, SDD’s lighter top end is the right tool. The requirements layer in RCF assumes you know what you’re building. In discovery, you don’t. Forcing a PRD before there’s anything to write down is the kind of waterfall mistake the lineage has spent twenty years escaping.

When RCF is the right reachCopy link

Reach for RCF when the requirements layer is the part that’s breaking your project, not the spec layer.

If your team is shipping plausible code that nobody can stand behind, that’s AI drift, and it’s a requirements-layer problem dressed as a build-layer problem. The agent did what the spec said. The spec did what the prompt said. Nobody in the chain decided whether that was the right spec for the right need, because the chain didn’t reach up that far. RCF reaches up that far on purpose.

If the product owner keeps changing the spec because they didn’t know what they wanted until they saw it, that’s the living spec problem. SDD assumes the spec is the stable thing and the code revolves around it. RCF assumes the spec is going to change and that the mechanism for absorbing change has to live above the spec, at the requirements and stories layer where the “why” stays put even when the “what” is still moving.

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.

And if your team is large enough that the writers of the requirements and the writers of the spec are different people, RCF’s explicit handoffs are worth the structural cost. The acceptance criterion is the joint between business intent and machine behaviour. With it, handoffs are clean. Without it, every handoff is an opportunity for drift, and the spec-only version of the discipline gives no specific tool for closing it.

Using them togetherCopy link

The framing that’s held up best, in the months of writing this methodology out, is that SDD and RCF sit at different layers of the same chain. RCF is the layer above the spec, where requirements live. SDD is the layer at the spec, where the agent works against a precise target. A serious project uses both.

In the RCF chain, the spec belongs around the functional build specification, after the requirements and acceptance criteria have set the scope and the contract. An SDD toolchain consuming that spec gets the precision benefits SDD’s advocates talk about: validation, regeneration, traceability into the code. What it also gets, that spec-as-source-of-truth alone doesn’t, is a chain back to the business decision the spec is implementing. If the spec is later found to be wrong, the requirement it serves is right there in the chain, and the wrongness is contained.

Reading the SDD literature with this layered framing in mind, most of the apparent disagreements between RCF and SDD evaporate. The vocabularies overlap because they’re looking at adjacent layers of the same problem. SDD is doing necessary work at the spec layer. RCF is doing necessary work above the spec, where the requirements and the “why” live. Each one is incomplete without the layer the other names.

The teams getting the most out of agent-assisted development in 2026 are the ones that adopt both. They use SDD’s tooling to get the agent reliably hitting the spec, and they use something like RCF’s traceability and document chain to make sure the spec they’re hitting is the one the business asked for. The combination is more disciplined than either alone, and the cost of the extra layer is small once the chain is in place.

That’s the position, plainly. RCF and SDD are not in competition. Anyone framing them as competing is missing the layer separation. The methodology lineage traces the throughline from waterfall to RCF and includes SDD as a step in its own right. The story it tells is that the trade has been moving toward requirements-first for forty years, with detours, and the agent era is the moment that movement starts to pay off.