# 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.

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.

## 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:

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. **Specification** — Intent structured into something an agent can consume: user stories, acceptance criteria, data models. Persistent, versioned, referenceable.
3. **Plan** — The build order. What depends on what, what ships first, and which release each story belongs to.
4. **Implementation** — The coding agent builds against the specification — not against whatever survived the context window.
5. **Verification** — What was built is checked against what was specified. Acceptance criteria become checks; the diff between planned and shipped becomes visible.
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 GitHub describes Spec Kit itself as an "intent-driven harness" that keeps intent at the center of development.

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).

## How IntentDocs implements the loop

IntentDocs (https://www.intentdocs.com) 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**; and editing the living spec is **updated intent**. In the repository, the spec materialises as [INTENT.md — an open format](https://www.intentdocs.com/intent-md) any agent can read, with or without IntentDocs.

## Frequently asked questions

### Is intent-driven development the same as spec-driven development?

They're closely related but not identical. Spec-driven development describes the mechanism: write structured specifications before code, and have AI agents build against them. Intent-driven development describes the purpose: the specification exists to capture and preserve developer intent through implementation and verification. Every intent-driven workflow uses specs; spec-driven development is how intent-driven development gets done.

### Do I need a tool to practice intent-driven development?

No. Markdown specs in your repo — the GitHub Spec Kit approach — are a legitimate way to practice it. Tools like IntentDocs add structure on top: an interview that extracts intent, a visual story map, MCP delivery into Claude Code or Cursor, and an audit trail of built-versus-planned. The principle matters more than the tooling.

### Where does the term intent-driven development come from?

It's emerging vocabulary across the AI coding ecosystem. GitHub describes its Spec Kit as an intent-driven harness that keeps intent at the center of development. The term is gaining ground because AI agents made the problem obvious: code generation became cheap, while capturing what you actually meant became the bottleneck.

### How is this different from writing requirements up front?

It isn't waterfall. Requirements documents were written once, signed off, and abandoned. In intent-driven development the specification is living context: agents read it during implementation, verification compares output against it, and what you learn feeds back into it. The loop runs continuously — intent gets updated, not archived.

---

More: [Compare spec-driven development tools](https://www.intentdocs.com/compare) · [Using IntentDocs with Claude Code](https://www.intentdocs.com/integrations/claude-code) · [Using IntentDocs with Cursor](https://www.intentdocs.com/integrations/cursor) · [Pricing](https://www.intentdocs.com/pricing)