What is Intent-Driven Development?

Intent-driven development is an approach to AI-assisted software development in which the developer's intent is captured as structured, persistent specifications that guide implementation and verification.

The idea is simple: when software is built by AI coding agents, the scarce thing is no longer code — it's a durable record of what you meant. Intent-driven development makes that record a first-class artifact. Instead of intent living in chat scrollback and vanishing with the context window, it's captured as a structured specification that the agent implements against and is verified against.

Why intent gets lost

Prompt-first workflows leak intent at every step. You explain what you want in a chat, the agent builds an approximation, you correct it, the session ends — and the only surviving record of a dozen product decisions is the code itself. Two weeks later, neither you nor the agent can say which behaviours were chosen and which were accidents.

That failure mode is the subject of why AI-built products fail: drift between what was intended and what shipped. AI-built products so often demo well and then collapse under real use because the intent was never written down — so nothing could be checked against it.

The Intent Loop

Intent-driven development runs as a cycle — IntentDocs calls it the Intent Loop. Each stage produces the input for the next, and verification feeds back into intent — which is what separates it from writing requirements once and filing them away:

1. 1

   Intent

   What you want to build, and why. Captured explicitly — in an interview, a brief, a conversation — instead of scattered across ephemeral prompts.

   ↓
2. 2

   Specification

   Intent structured into something an agent can consume: user stories, acceptance criteria, data models. Persistent, versioned, referenceable.

   ↓
3. 3

   Plan

   The build order. What depends on what, what ships first, and which release each story belongs to.

   ↓
4. 4

   Implementation

   The coding agent builds against the specification — not against whatever survived the context window.

   ↓
5. 5

   Verification

   What was built is checked against what was specified. Acceptance criteria become checks; the diff between planned and shipped becomes visible.

   ↓
6. 6

   Updated intent

   What you learned flows back into the specification. The loop closes — intent is living context, not a signed-off document.

…and updated intent feeds the next pass through the loop.

Intent-driven vs spec-driven development

Spec-driven development is the practice: write structured specifications before code, and have agents build from them. GitHub's Spec Kit made the term mainstream — and, tellingly, GitHub describes Spec Kit itself as an "intent-driven harness" that keeps intent at the center of development.

That framing is the right one. The spec is the medium; intent is the message. Spec-driven development tells you what to produce (specifications), intent-driven development tells you why they exist(so intent survives implementation and can be verified). If you're evaluating tools in this space — including how IntentDocs compares to GitHub Spec Kit — the question to ask isn't "does it generate documents?" but "does it close the loop from intent to verification?"

How IntentDocs implements the loop

IntentDocs is built around exactly this cycle. An AI interview captures intent and turns it into a specification — a visual story map with acceptance criteria and a data model. Releases give you the plan. Your coding agent — Claude Code, Cursor, or any MCP client — reads the spec over MCP during implementation and syncs progress back. The build-versus-plan audit trail is verification: what shipped, checked against what was specified. And because the spec is living, editing it is updated intent — the next agent session builds against the current truth, not a stale document. In the repository, the spec materialises as INTENT.md — an open format any agent can read, with or without IntentDocs.

Frequently asked questions