Intent-Driven Development

Category: Core Concepts Last updated: June 29, 2026

What Is Intent-Driven Development?

Intent-Driven Development (IDD) is the practice of building software with AI coding agents by making your intent explicit and structuring the context around it, so agents produce what you actually meant rather than what they infer from an ambiguous prompt. It is an umbrella approach: where individual techniques solve one slice of the problem, IDD names the shared goal that connects them — keeping human intent at the center as work moves from a rough idea to working, verified code.

The premise is simple. AI agents are extraordinary at generating code, but they have no privileged access to your goals, constraints, or domain. Left to infer intent from short prompts, they drift. IDD treats intent as a first-class artifact you deliberately capture, structure, and carry forward — so the agent has something durable to build against. The practices that make this work, such as context engineering, spec-driven development, harness engineering, and Ralph Loops, are all expressions of the same idea: structure intent before you generate.

Why Intent-Driven Development

In AI-assisted development, the quality of your output depends directly on the quality of your input. When intent is left implicit, the gap between what you wanted and what got built — intent-to-implementation deviation — widens with every prompt. This is a property of the workflow, not the model: in an unstructured loop, each correction focuses on the current concern, and earlier constraints get weakened or forgotten until the developer is stuck in a sustained negotiation, restating the same intent to keep the output on track.

IDD addresses this at the root. Instead of relying on the agent to remember and reconcile scattered instructions, you give it a structured, durable representation of intent to work from. Deviations become visible early — before they compound — and the agent spends its capability executing a clear target rather than guessing at one. The result is the shift this site is built around: moving beyond vibe coding to engineering the harness that takes you from idea to implementation in an agent-native way.

Core Principles

A few principles run through every IDD practice, regardless of which tool or technique you use.

Intent Is a First-Class Artifact

Intent is not a throwaway prompt — it is something you capture, structure, and keep. Whether it lives in a specification, a schema, or a harness, intent becomes a durable reference that both humans and agents can return to. This is what separates IDD from improvisation: the "why" and the "what" are written down before the "how" is generated.

Structure Over Improvisation

IDD favors deliberate structure over conversational drift. Structuring context, slicing work into reviewable units, and defining the artifacts an agent should produce all reduce ambiguity at the point where it is cheapest to fix. The goal is not heavyweight process for its own sake — it is just enough structure to keep intent intact as the system grows.

Agent-Native, Not Agent-Adjacent

IDD assumes AI agents are first-class participants in the development loop, not occasional helpers. Workflows are designed for how agents actually behave — their context limits, their tendency to optimize for the immediate prompt, their ability to run tasks in parallel — rather than retrofitting human-only processes around them.

Verifiable by Design

Because intent is explicit, you can check work against it. Validation — tests, reviews, spec-to-code comparison — closes the loop between intent and implementation, catching deviation while it is small. Intent that cannot be verified is just a wish; IDD insists on making it checkable.

The Practices Under IDD

Intent-Driven Development is best understood through the practices it brings together. Each tackles a different part of the journey from idea to implementation, and they compose: you rarely use just one.

Context Engineering

Context engineering is the foundational practice of deliberately structuring the information an agent sees, so it understands what you need. It is the groundwork beneath everything else in IDD — without well-engineered context, even a good specification underperforms. Context engineering spans a spectrum from tactical (a well-formed prompt) to strategic (a durable, structured source of truth).

Spec-Driven Development

Spec-driven development (SDD) is the strategic end of that spectrum: you write a specification first, implement against it, then validate alignment. The spec becomes the source of truth that keeps design intent and the actual code synchronized. SDD is the most mature, well-tooled IDD practice, supported by tools such as OpenSpec, GitHub Spec Kit, and Kiro.

Harness Engineering

Between a human idea and an agent's execution there is a gap. Harness engineering is the practice of building the layer that transforms raw ideas into structured, durable instructions an agent can act on independently — the "intent harness." Rather than hand-holding the agent through each step, you engineer the scaffolding that carries intent reliably into execution. See The Intent Harness for a deeper treatment.

Ralph Loops

Ralph Loops are structured, repeating agent loops that drive a task toward completion against a clear definition of done — the agent works, checks its output against intent, and iterates without a human in every cycle. They are an agent-native execution pattern: useful precisely because the intent and the checks are explicit enough that the loop can run on its own.

From Idea to Implementation

The IDD workflow can be read as three beats: idea → intent → implementation. A raw idea is fuzzy and underspecified. The work of IDD is to turn that idea into structured intent — context, specifications, and a harness an agent can act on — and then let the agent carry it to a verified implementation.

  1. Idea: Start from the thing you want, in plain terms. Keep it small enough to reason about; large, single-shot requests produce intent you cannot actually review.
  2. Intent: Structure it. Engineer the context, write the specification or schema, and define how the agent should produce its artifacts. This is where ambiguity is removed while it is still cheap.
  3. Implementation: Let the agent build against that structured intent, with validation closing the loop. Tests and reviews compare what was built to what was meant, so deviation surfaces early.

The same loop scales from a single feature to an enterprise rollout. For the workflow mechanics in depth, see the spec-driven development workflows guide; for choosing tooling, the tool selection guide.

IDD vs Vibe Coding

The clearest way to understand IDD is by contrast with vibe coding — the informal, conversational approach where you nudge an agent through prompts until the result "feels right." Vibe coding optimizes for speed and is genuinely useful for quick prototypes and exploration. But it manages deviation reactively: you only course-correct once you notice the output has drifted from what you meant.

Intent-Driven Development optimizes for intent alignment instead. By making intent explicit, structured, and verifiable up front, it prevents deviation rather than chasing it. The trade-off is real — IDD frontloads clarity, which costs more than starting to type immediately — so the guiding rule is pragmatic: if intent matters beyond the next prompt, structure wins. For the full comparison, see vibe coding vs spec-driven development.

Getting Started

You do not adopt all of IDD at once. Start where deviation hurts most and add structure incrementally.

Resources