What is the difference between intent-driven and spec-driven development?

What does intent express?

Intent names the change the work is meant to produce, the people affected and the reason to pursue it. It includes the assumptions behind the proposed result. A solution can meet its specification while failing that intent.

For example, “add a renewal dashboard” names a deliverable. “Account owners identify renewals needing intervention before the renewal window closes” names a behavior the dashboard might support. Whether that behavior improves retention is a further hypothesis, not something the dashboard's acceptance tests can prove. This is an illustrative example, not a customer result.

What does the specification add?

The specification defines the agreed behavior and constraints of a chosen increment. For the renewal example, it could define which accounts appear, who may see them, how freshness is displayed and what happens when source data is missing. Examples and checks make those expectations inspectable.

Intent helps choose and revise the solution. A specification makes an agreed change precise enough to build and verify. Treating either as a replacement for the other leaves a gap: a broad goal can leave implementation decisions unbounded, while a detailed contract can reliably produce an unwanted product.

The labels “intent-driven” and “spec-driven” are used differently across tools and practitioners. Compare the actual artifacts and decision rights rather than assuming each name describes a standard method.

How should they stay connected?

Record the outcome owner, affected user, baseline if known, target or proposed direction, assumptions and relevant constraints. Keep solution options separate until the next decision requires a choice. Hand the agreed intent into the specification with links to its sources.

When implementation reveals a conflict, distinguish a delivery error from a change of intent. A delivery error needs correction against the agreed contract. A change of intent needs an explicit decision and updates to the affected artifacts. Do not let an agent quietly rewrite the goal to make its implementation appear correct.

After release, name the owner and trigger for reviewing adoption and outcome evidence. That closes the connection the acceptance tests cannot close.

Sources and next actions

• Frame Intent: desired outcomes, assumptions, leading indicators and handoffs.
• Outcome Framing Coach: improves wording once the intended result is established.
• How these skills fit together.
• Outcome framing for agentic harnesses.