Intent-Driven Development with Claude Code and Fable 5

What intent-driven development actually means

For most of software history the unit of work was the instruction. You told the machine what to do, step by step, and the code was the record of those steps. Intent-driven development moves the unit of work up a level. You state what should be true when the task is done, and a coding agent figures out the steps that make it true.

The shift sounds small but it changes who does what. You become responsible for the intent: a clear statement of the outcome and the conditions that prove it. The agent becomes responsible for the implementation and, crucially, for checking that the implementation satisfies the intent. You are no longer writing the how. You are defining the what and the done.

This is why people also call it spec-driven development. The spec is not documentation you write after the fact. It is the input. Claude Code running Fable 5 reads the spec, produces the change, and comes back with evidence that the change meets it. Your review shifts from reading every line to checking whether the stated intent was the right intent.

An intent is not a prompt

A prompt is a one-shot request: do this thing now. It lives for a single turn and then it is gone. An intent is durable. It says what the system should do, what counts as correct, and what must not break in the process. It survives the task and can be re-verified later.

The practical difference is acceptance criteria. A prompt says add rate limiting to the API. An intent says requests over one hundred per minute per key return a 429 with a Retry-After header, existing endpoints keep their current behavior, and the limit is configurable without a redeploy. The first is a wish. The second is testable, and a testable statement is one an agent can verify itself against.

Writing intent well is the actual skill of this workflow. Vague intent produces confident, wrong code, because the agent will resolve every ambiguity with a guess. Precise intent, with the edges named, is what lets Fable 5 build something you can accept without rereading it line by line.

The loop: express, implement, verify

Intent-driven development runs as a loop with three moves, and the agent owns two of them.

You express the intent. Claude Code implements it: Fable 5 plans the change, edits the files, and wires up whatever the spec implies. Then the agent verifies, and this is the part that makes the workflow trustworthy. It runs the tests, exercises the new behavior against the acceptance criteria you stated, and reports either a pass or a specific gap. When a criterion fails, it does not hand you a diff and hope; it iterates until the criterion is met or it tells you exactly which one it cannot satisfy and why.

The missing half: intent is underspecified without grounding

Here is where naive intent-driven development breaks. You write a clean, testable spec and the agent still builds something your team quietly rejects. It used a fetch pattern you abandoned two quarters ago. It invented an error format when you already have a house one. It solved the stated problem in a way that ignores a decision recorded in a design doc it never saw.

The reason is that intent is always underspecified relative to a real codebase. Your spec names the outcome, but the acceptable implementation also depends on a mass of context you never restate: the conventions your repo follows, the architectural decisions you already made, the patterns your team considers house style, and the reasons behind them. A new engineer learns this by reading the code and asking around for weeks. An agent starting cold has none of it.

So it guesses. And a guess that compiles is the most dangerous output an agent can produce, because it passes review by looking plausible. The fix is not a longer prompt. It is grounding: giving the agent access to the same accumulated context a senior teammate would carry into the task.

Where RDK fits: retrieval supplies the grounding

RDK is the retrieval layer that turns a bare intent into a grounded one. You index the material that defines how your team builds, specs, architecture decision records, prior pull request discussions, style guides, and the code itself, as encrypted private chunks on the RDK network. Before Fable 5 implements an intent, Claude Code retrieves the chunks that bear on it and places them in context. The agent plans against your actual decisions instead of a generic prior.

This is what makes build the right thing the first time more than a slogan. The intent says what you want. The retrieved grounding says how this codebase does that kind of thing and what has already been settled. Together they collapse the space of plausible implementations down to the one your team would accept, before a single line is written.

What a grounded intent looks like in practice

Put the pieces together and the workflow is concrete. You write the intent as a spec with acceptance criteria. Claude Code retrieves the relevant grounding from RDK: the design decision that governs this module, the error-handling pattern your repo standardized on, the prior discussion where the team rejected the obvious approach. Fable 5 implements against both the intent and that grounding, then verifies the result against your criteria and reports what passed.

Your job is the two ends that only a human can own: deciding what should be true, and confirming the intent was the right one. Everything between, the implementation and the proof, belongs to the agent. That is the whole promise of intent-driven development, and grounding through retrieval is what keeps the promise honest. Without it the agent builds a plausible thing. With it the agent builds your thing, the first time, and shows you why it is correct.