Section 1 · The gap
AI agents are extraordinary
at the first 80%.
They stop being useful
at the 20% that matters.
The demo runs. The screens look right. Underneath, the agent has made a hundred decisions you never made. Each one quietly wrong in a way that surfaces six weeks later.
AI gets you to demo-ready. Production-ready is a different problem, and the same problem it always was.
Section 1 · The gap
Four blockers, named.
- Intent drifts. AI produces code without really understanding the business requirement behind it. The output looks right but the intent behind it has quietly slid sideways.
- Hallucinations ship. AI invents methods, misreads schemas, quietly introduces bugs that only surface in prod.
- Trust doesn’t scale. Engineers read every line, which eats back the productivity gain.
- Audit is absent. When something breaks, nobody can trace the code back to the decision that asked for it.
Section 1 · The gap
You’re not alone in this.
- 31% of software projects classed as fully successful. Standish CHAOS
- <30% of organisations report material productivity gains from gen-AI in engineering. McKinsey, 2025
- 96% of engineers say they wouldn’t trust unverified AI-generated code in production. Industry survey, 2025
Section 3 · The principle
The core idea.
Anchor in requirements. Every requirement breaks into user stories. Every story carries acceptance criteria. Every acceptance criterion maps to a test. Code arrives last, as a node in the same graph, anchored to the criteria it implements.
Every line points up to the decision that justifies it, and down to the test that proves it.
If this sounds like requirements-driven development, you’re half right. Hold the thought; I’ll place it in a minute.
Section 3 · The principle
Traceability,
forward and backward.
From any line of code, rcf trace resolves its Code Node and walks back to the AC, the story, the requirement, and who signed it off. From any business decision, trace every test that proves it ships.
The audit becomes a query, not guesswork dressed up as seniority.
Section 3 · The lineage
The two you’ll
compare it to.
- Requirements-driven development. RCF’s ancestor, not its rival. Requirements-first is decades old, with a lifecycle and tooling RCF can’t match. What RCF adds is a tighter chain that lives inside the build, not in a separate tool beside it.
- Spec-driven development. This year’s framing for AI-assisted work, and a good one: it makes code correct against the spec. It slots into a single stage of the build cycle, the Build step, generating code against a precise target. What it can’t judge is whether the spec was the right thing to build; the AC-derived test, not the spec, stays the authority. It can’t validate the chain, because it doesn’t know the chain exists.
RCF doesn’t replace these. It holds them together, and holds them against an agent that won’t.
Section 4 · In a regulated context
The audit story.
Six months after ship, compliance asks: why did this customer get a Tier-2 KYC verdict?
In RCF, the answer is in the AC that scoped the verdict logic, the test suite that asserted it, the FBS that built it, and the human who signed the criterion. The chain holds.
Section 4 · In a regulated context
What regulators are
starting to ask.
- DORA (in force): operational resilience, traceable change management.
- EU AI Act (high-risk systems): show your working when an AI helped make a decision.
- BCBS 239 (banks): data lineage and aggregation under audit.
- Model risk (SR 11-7, SS1/23): increasingly applied to AI-augmented code paths.
‘The AI did it’ is not a defence any regulator will accept.
The chain is the defence.
Section 4 · In a regulated context
What changes for your juniors.
They ship more, faster, under a structure that makes their work auditable for the first time. The ladder gets clearer: writing crisp ACs is the new “can they spec well?” interview question.
They will like seeing a clearer career path.
Section 4 · In a regulated context
This isn’t theory.
It’s running in production.
One product delivered end-to-end on the RCF methodology, with the open-source rcf-lite tooling alongside, published and still early. A second product on a different stack is in flight. Team adoption is widening.
This documentation site was built using RCF and my Digital Operator, Dave. Our own tooling is being built using RCF.
Section 5 · Three phases
Three phases of adoption.
- Phase 1: automate the engineer. RCF. Where most teams are trying to be. Working in production today.
- Phase 2: automate the operating engineer. The Digital Operator. Where I am now. The first instance is running.
- Phase 3: automate the roles upstream. PO, architect, compliance, design. Where this is heading.
Section 5 · The Digital Operator
A counterpart,
not an assistant.
An assistant helps you do your job. A counterpart does the job, and journals how you would have done it while doing it.
The mechanism is closer to a biographer than to a chatbot: a writer who shadows the subject, captures every observation about how they think, and over time becomes able to write in their voice. The Digital Operator does the same, except it also performs the work itself, and the work is how it learns.
The first instance is running. Dave is my engineering Operator. He runs my tech estate, handles my routine work, tightens my drafts, and learns my judgement as he goes.
An assistant helps you. A counterpart replaces your role or function: in your voice, at your standards, with your trail.
Section 5 · The Digital Operator
Capturing the hard-to-formalise.
Most institutional knowledge isn’t the decisions themselves. It’s the why. Intuition. Decision paths. Justifications. The reason you ranked one option above another.
This kind of knowledge doesn’t get written down because the cost of writing it down has always been higher than the cost of carrying it in your head. The Operator inverts that. Every decision, every justification, every priority call is captured in context, as it happens, by the thing that was already in the loop.
The hardest knowledge to write down, the why,
is what gets captured by default.
Section 5 · The Librarian
The Librarian.
A journal that nobody reads is a log file. The pattern that makes the Digital Operator more than clever logging is the second role: the Librarian.
The Librarian collates incoming journals across every Operator running across every role. Distills what is repeated. Organises what is distinct. Synthesises across journals into a single institutional store that feeds the next round of work.
What vendors are selling as agent memory is plumbing. The Librarian is a role.
Agents journal. The Librarian remembers, for the whole company, across every role, forever.
Section 5 · The honest read
Where we are.
Phase 1 (RCF): one product delivered end-to-end on the methodology, with the published rcf-lite tooling, open-source and early. A second product on a different stack is in flight.
Phase 2 (Digital Operator): Dave is running. He built the methodology rewrite. He builds and maintains this site. He builds my own tooling. The Librarian function exists; it’s currently small.
Phase 3 (upstream roles): in design.
Early days. The shape is real, the scale is small, what’s possible is being worked out.
Resources
Resources, and questions.
- The methodology, full read.
- The Digital Operator page, the broader operating model.
- This deck, share-link in case anyone wants to revisit.
Speaker notes load here when the deck advances.
Keyboard shortcuts
- ← →
- Previous / next slide
- ↑ ↓
- Previous / next slide
- Space
- Next slide (with Shift: previous)
- PgUp PgDn
- Previous / next slide
- Home End
- First / last slide
- f
- Toggle fullscreen
- n
- Toggle inline speaker notes
- s
- Open private speaker view in a new window (notes + timer, syncs with this deck)
- t
- Reset timer (speaker view only)
- p
- Toggle present mode (activates click-to-nav)
- ?
- Show / hide this help
- Esc
- Exit fullscreen / close help
Click right half of viewport to advance, left half to go back.
URL hash deep-links to a slide (e.g. #7).