The methodology lineageCopy link

I had the realisation a few months into building everything through AI agents. The thing I’d been doing for thirty years finally had a name, and the name tied back through every methodology the industry has ever taken seriously. Requirements that anchor the work. Acceptance criteria the test can’t cheat on. A chain you can walk from a business decision to a line of code. I called it RCF because I needed a label for the things I kept reaching for to stop the agents drifting. But the label was new. The discipline wasn’t.

So this is the long version of where RCF comes from. Six stops, each one solving the previous stop’s open problem and quietly leaving the next. Waterfall, Agile, TDD and BDD as a pair, spec-driven development, and then RCF. The point isn’t that the older methods were wrong. They were rational for their moment. The point is that the throughline kept moving, and somebody had to notice where it had landed.

Waterfall: clarity before commitmentCopy link

Waterfall gets a kicking in modern writing, and most of it is unfair. When it took shape in the 1970s, the alternative wasn’t agile. The alternative was nothing. Software projects were getting bigger, contracts were getting bigger, and somebody had to put a structure on the work so the people paying for it could tell what they were paying for. Requirements, design, build, test, ship. In that order. With a signed document at each handover.

What waterfall solved was the prior problem, which was that no one had agreed what the software was supposed to do before they wrote it. The requirements phase forced a shared definition of done. The handovers forced decisions to be made by the right people at the right time. The audit trail meant that when a project went sideways, there was a paper record of who decided what, when. That’s a real contribution. Regulated industries still use it for exactly these reasons. Finance, healthcare, and government workloads still ship on waterfall variants because the audit and compliance shape of the model is a feature, not a bug.

What it left open was feedback. The big-document-at-the-start design only works if your understanding of the problem doesn’t change while you build. In practice, it always does. The spec went stale before the code shipped. Customers wanted something different by the time it arrived. Engineers found constraints in week eight that should have changed the design in week one. Waterfall had no graceful way to incorporate any of that. You either ploughed on with a spec you no longer believed in, or you reopened the contract and watched everybody’s budgets explode.

So the next stop had to invent feedback.

Agile: feedback, adaptability, shorter cyclesCopy link

The Agile Manifesto turned twenty-five in February 2026. That’s long enough for the manifesto to be older than some of the engineers reading this page. It’s also long enough for the practice to have drifted a long way from what the seventeen people in that Utah ski lodge were trying to do.

What the manifesto solved was the waterfall problem. Build a small thing, show it to someone, find out what was wrong, build the next small thing. Compress the feedback loop until the spec couldn’t go stale because there was never a single spec to begin with. Ship working software. Talk to the customer. Respond to change. Read in 2001, in a world where most large-IT projects ran years and shipped late, those four values were a genuine intervention.

What it left open is the thing every honest agile practitioner will admit after a drink. The rigour got thrown out with the rigidity. Somewhere in the gap between the manifesto and the consulting industry that grew up around it, “we’re agile” came to mean “we don’t write requirements down.” The sprint became the unit of accounting. The standup became the status report. The retrospective became therapy. The acceptance criteria, on most teams I worked with, got drafted by the developer five minutes before the ticket got closed, because the product owner had gone quiet again. Documentation became the thing you didn’t do because agile.

The manifesto didn’t say that. The manifesto said working software over comprehensive documentation, which is a preference, not an absolution. But twenty-five years of practice has bent the preference into an excuse. Even the manifesto’s twenty-fifth-anniversary retrospectives tend to circle the same point: the first principles got replaced with rituals, and the rituals don’t carry the rigour the principles assumed.

So the next stop had to put the rigour back in. Not as documentation. As tests.

TDD and BDD: tests as the contractCopy link

I’m treating these as a pair because they share an ambition, even though TDD came first and BDD grew out of it. Both wanted to stop the writing-prose-about-what-the-code-should-do habit and replace it with executable checks that fail until the code does what was asked.

Test-driven development solved the verification problem. Write the test first, in code. Watch it fail. Write just enough of the implementation to make it pass. Refactor. The discipline forces you to know what success looks like before you build, and it leaves a regression net behind as a side effect. Behaviour-driven development took the idea up a level and gave product owners a vocabulary to write checks they could read. Given/When/Then. A precondition, an event, an observable outcome. The stakeholders write the scenarios. The developers wire them up. Everybody reads the same sentences.

On a good team, this is real. Acceptance criteria become genuine contracts. Tests stop being a thing you add after the feature works and start being a thing you write before. The codebase accumulates a description of its own behaviour, in code, that nobody has to remember to update because the build fails when it’s wrong.

What it left open was the layer above the test. TDD and BDD both assume somebody else figured out what was worth testing in the first place. Neither of them anchors on requirements above the test layer, and on most projects the requirements layer is exactly where the rot starts. Worse, BDD in particular has a failure mode I’ve watched a few times now. The Gherkin scenarios get written, but they get written by the developer, after the fact, to match what the code already does. The product owner skims and signs off. The shared vocabulary becomes theatre. The tests still pass, because they were written to pass. Nobody’s wiser.

The methodology didn’t fail. The discipline ran out. Tests are a brilliant contract when the thing being tested is the right thing. They’re a thorough way of being wrong when it isn’t. So the next stop had to put the spec back in.

Spec-driven development: executable source of truthCopy link

Spec-driven development is the dominant 2026 framing in this space, and any methodology piece written today has to engage with it on its own terms. Martin Fowler is publishing on it. GitHub shipped Spec Kit as a first-party toolkit. 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 regenerable output. SDD emerged in 2025 explicitly as a response to the vibe-coding failure mode, where AI agents produce plausible code that drifts from intent.

What SDD solves is real. A written specification, treated as the primary artefact, gives AI agents a stable target. Tooling around it can validate, regenerate, and trace. The spec becomes the place where intent lives, not the chat history. For teams that adopt it well, the first-pass success rate of agent work goes up sharply, because the agent has somewhere precise to aim. The spec-as-source-of-truth idea is the right move for the moment AI stepped into the build.

Where SDD leaves a gap is in what it means by “spec”. In a lot of the tooling, “spec” ends up looking like a YAML file, or a structured prompt, or a config document with placeholder hierarchies. That’s a fine artefact for an agent to consume. It is not, in itself, a description of what the business wants and why. 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, and SDD as currently framed doesn’t take responsibility for it.

How is RCF different from spec-driven development?Copy link

RCF treats requirements as primary, with the spec downstream. SDD treats the spec as primary. RCF sits one layer above SDD in the same chain, addressing the question SDD doesn’t ask. Which spec is the right spec.

SDD treats the spec as primary. RCF treats requirements as primary, with the spec downstream. That’s the honest distinction. The two aren’t opposed. They sit at different layers of the same chain. SDD is doing necessary work at the spec layer. The work above the spec is where this lineage was always heading. For the longer version, see RCF and spec-driven development.

RCF: where the lineage landsCopy link

RCF, the Requirements Confidence Framework, is what falls out the other side of watching this whole sequence. It doesn’t replace any of its predecessors. It inherits what each one earned and addresses what each one left open.

Waterfall’s contribution survives in the apex of the document chain. Requirements as the top layer of the work, owned, written down, with out-of-scope named as deliberately as in-scope. Decisions about what the product is get made before the build, not during it. The audit trail isn’t there to satisfy compliance. It’s there because traceability is how an honest project survives contact with reality.

Agile’s contribution survives as the living spec. The document chain is editable on purpose. When a build finds a constraint nobody saw coming, the spec moves, and the gap between docs and code becomes the next build cycle. Iteration is first-class work. Ship in slices. The planning isn’t a fortress around the build; it’s the structure that lets the build move without losing the plot.

TDD and BDD survive in the test-suite layer, but the contract moves up. The unit isn’t the test anymore. The unit is the acceptance criterion, written in Given/When/Then, owned by the requirement above it, mapped one-to-one to a test suite below it. That phrasing matters: acceptance criteria as the contract, not tests as the contract. Tests are what prove the contract holds. The contract itself lives at the AC layer, where humans can read it, argue about it, and own it. That’s the layer the BDD theatre failure mode collapses. If the AC isn’t agreed before the build, no Gherkin scenario written after the fact will save you.

And SDD’s executable-source-of-truth idea survives, but the source of truth gets put back where it always belonged. The requirement is the source. The spec elaborates it. The acceptance criteria pin it down. The tests prove it. The code makes the tests pass. Five layers, each one earning its place, each one anchored to what justifies it above and what proves it below. The document chain page covers the structure in full; the nine layers and what each one adds is the long version.

The piece none of the predecessors had is traceability as a property of the data model itself, not a tool you bolt on. Every requirement, story, AC, FBS, test suite, and test case carries an opaque ID. Code references the AC ID it implements. The string is the lookup key. Trace forward from a business decision to every test that proves it ships. Trace backward from a function in the export handler to the requirement it serves. Each hop is mechanical, because the structure is mechanical. That’s how you stop AI agents quietly making decisions you didn’t make. The chain is the thing that catches them.

It also adds the per-stage commit discipline of the five-stage build cycle. Define, build, review, test, finalise. Each stage commits. Each commit is honest. Nothing rolls forward on faith. The cycle works as a forcing function. You can’t fake the review if the review has to commit before the test stage starts. Most methodologies stop at the level of advice. RCF runs at the level of structure, because that’s the level AI agents and human teams both need.

The throughlineCopy link

Step back. Each methodology in this lineage was a stage on a single path. Waterfall wanted clarity. Agile wanted feedback. TDD and BDD wanted tests that couldn’t lie. Spec-driven development wanted a primary artefact AI could build from. RCF wants all of them at once, organised around requirements as the apex layer, with acceptance criteria as the contract and a chain that connects every line of code back to the business decision that asked for it.

I’ve watched the industry argue these methodologies against each other for three decades. The arguments were almost always about ceremony budget, not about discipline. With AI eating the typing, the ceremony budget is no longer the bottleneck. The discipline is the work. The methodology that treats requirements as primary, AC as the contract, and traceability as a property of the model itself is what comes out when the throughline lands. RCF is what comes out.

This isn’t a fork. It’s where the throughline goes.

The lineage at a glanceCopy link

For the structural detail, read the document chain and acceptance criteria as the contract. For why the economics of all this changed when AI showed up, read the eighty-twenty flip. For the whole methodology end to end, start with the quick tour.