What is Intent-Driven Development?

Definition

Intent-Driven Development is a discipline that treats intent — the durable description of why a system exists and what it must achieve — as the primary artifact of software work.

Code is generated from intent via spec, prompts, or direct generation. The intent is curated by humans; the code is produced by humans, agents, or AI as the slice demands.

The bet behind IDD is that, with capable models, the right way to use AI is to give it direction — a map and a compass — rather than to restrain it. Intent is what you put on that map. Done well, the LLM stops asking permission for every step and starts shipping work the team wants to merge.

"The intent of the development team is expressed in natural language … and code is the last-mile approach."— GitHub Spec-Kit · spec-driven.md

How it stacks with SDD

IDD sits one layer above SDD. The intent is upstream; the spec is the bridge to implementation; code is the last mile.

What actually lives in the tree

An intent tree is a navigable folder of small markdown files. The three branches at the top — Purpose, User Context, Means — answer why, who, and how. Around them sit four operational siblings (rules, specs, execution, clarifications) that turn the tree into something agents can actually act on.

Under Means, two sides sit deliberately together. Product-experience intent — what the user actually has to feel, do, and achieve, all the way up to the larger goal the product exists for — and technical intent — architecture, contracts, verification — share the same tree because they constrain each other. Calling the user-facing side merely "frontend" understates it; this is where the value of the product is decided. Splitting the two across separate tools is what creates drift between "what we said we wanted" and "what we built."

Concrete directory layout, file format, and promotion states are documented on the Intent Tree page.

How intent grows: the clarification loop

IDD does not require a perfect spec on day one. In an Intent-System implementation, AI continuously reviews accumulated intent and surfaces "what about this?" questions in bulk, paired with recommended answers. Humans accept the recommendation where they have no strong opinion, and override it where they do — keeping their attention on the parts where their taste actually matters. The intent tree gets richer with every cycle, without an upfront spec marathon.

That richer tree pays off at the operational layer: each GitHub issue inherits the relevant slice of intent (architecture, contracts, UI patterns), so writing a clear issue — the highest-leverage skill in modern AI-assisted coding — becomes feasible. Implementation runs on context that is already there, and review compares the PR to intent rather than to personal taste.

Where do the first answers come from? In the early phase of a product we run a process called Intent Storming — structuring technology and intent as the product owner. Same posture as Brainstorming or Event Storming, except the artifact you walk away with is an intent tree. It works as a group workshop or solo, with the AI interviewing you.

The end-to-end loop, in five beats

Putting it together, IDD is one cycle that starts and ends at intent. Each beat below has its own dedicated page; this is the shape that ties them together.

1. Seed. Run an Intent Storming session — structuring technology and intent as the product owner, with the team or solo with the AI interviewing you. Answers go straight into the tree as Purpose / User Context / Means nodes — no "translate the meeting notes into intent later" step.
2. Sharpen. AI continuously reviews the tree and surfaces "what about this?" questions in batches with recommended answers. The team accepts recommendations where they have no strong opinion and writes their own where they do. Each accepted answer promotes an intent one level (inferred → clarified → canonical).
3. Compile an issue. A slice of the tree becomes a GitHub issue that already carries the relevant architecture, contracts, and UI patterns. Writing a clear issue stops being painful because the context is already structured.
4. Implement, AI-review, human-approve. An agent (or human) implements from what is embedded in the issue, on ai-develop. A separate AI reviewer that has loaded the entire intent tree reads across the implementation, the issue, and the tree at the same time, judging whether code and tests honor intent. A human gives the final approval before promotion to main.
5. Close the loop with reality. No build is assumed finished in one pass. The design thread and a human periodically run the merged product and check it against the intent it was meant to honor; closeout writes accepted diffs back into the tree as canonical. Anything off — caught proactively, or surfacing as a post-release defect — re-enters as an Intent-Bug issue and is triaged into either an implementation bug (the intent was right; fix the code) or an intent gap (the implementation reasonably guessed at something the intent never stated; state the intent in more detail first, then fix). Either way the fix exits via the same review and approval path. Because the original intent is preserved, telling these two cases apart — and checking whether the result matches intent at all — stays tractable; that is what makes the tree get stronger over time, not just bigger.

What is — and isn't — IDD