Intent Engineering: the product layer before AI writes code.
Intent engineering turns user evidence into product judgment that AI coding agents can act on: the discipline upstream of the prompt, the context, and the code.
Intent is judgment under evidence, not a contract you compile.
87.7% of product teams use AI coding assistants. Only 36.1% say it strengthened how they actually work. The tools changed. The work didn’t.
Product Circle, State of AI in Product 2026 (309 product leaders)
From user evidence to an agent-ready IntentSpec
A worked example. Raw friction on the left becomes an agent-ready spec on the right: every requirement explicit, measurable, and verifiable.
Evidence
“I gave up making an account. It asked for my address line by line and I bailed.”
35% of users abandon onboarding at step 3 (address entry). ~200 signups/week lost.
In 6 of 8 usability tests, users paused or sighed at the six-field address form.
IntentSpec
# Objective
Users abandon onboarding at the address step because the form needs 6 fields. ~200 signups/week lost.
# Outcomes
Address entry collapses to one type-ahead field. Step-3 drop-off falls ≥40%. Selecting a suggestion completes the step in <90s.
# Constraints
Do not touch the OAuth provider. Keep PCI scope unchanged.
# Edge cases
Geocoder down → fall back to the manual form. Unsupported region → clear message. PO boxes still enterable.
# Health metrics
Steps 1–2 completion does not drop. Address-validation accuracy holds.
# Verification
Integration test: geocode 5 sample addresses. Fallback test on API 500. p95 < 300ms.
Two definitions of intent engineering
Search the term today and you find two. They point teams in opposite directions.
The prevailing view
Intent as a contract.
Write a precise, machine-readable spec: an INTENT.md, a contract the agent compiles into code. The goal is fidelity: the agent builds exactly what the spec says.
The product-layer view
Intent as judgment under evidence.
A contract tells an agent what to do. It says nothing about whether you should be doing it. Intent engineering captures the judgment (which problem, on what evidence, with which trade-offs), then compiles it.
Precision without judgment just lets you build the wrong thing faster.
Prompt vs context vs spec-driven vs intent engineering
| Prompt engineering | Context engineering | Spec-driven dev | Intent engineering | |
|---|---|---|---|---|
| Operates on | A single model turn | The agent’s inputs | The spec’s precision | The product decision |
| Answers | How to ask | What the agent sees | How exact is the spec | What is worth building, and why |
| Grounded in evidence | ✗ | ~ | ~ | ✓ Always |
| Defines success | ✗ | ✗ | ~ Implicitly | ✓ Measurable outcomes |
| Mental model | Better question | Better inputs | Tighter contract | Better problem definition |
You need all four. But prompt, context, and spec-driven work all assume someone already decided what to build and how you’ll know it worked. Context isn’t judgment. Intent engineering is where that decision is made, and made explicit enough to delegate.
Going deeper on the prompt/context split? Read Intent Engineering vs Context Engineering →
The eight parts of an IntentSpec
If an agent would still need to ask a clarifying question, the spec isn’t done yet.
Objective
The user problem and why it matters, grounded in evidence, not opinion.
Outcomes
Observable, measurable state changes. Each verifiable by a test or metric.
Evidence
Linked real user signals proving the problem exists. No evidence, no build.
Constraints
Hard boundaries the implementation must respect. What the agent must not do.
Scope
What to touch, and what to leave alone. The fence against stray refactors.
Edge cases
Boundary conditions and failure modes. Empty states, outages, scale.
Health metrics
What must not regress. Outcomes say what changes; this says what stays true.
Verification
How you confirm it works, and the observable signal once it ships.
Evidence → judgment → implementation → verification
- 1
Capture friction
Collect signals: tickets, interviews, drop-offs, NPS comments, session recordings. The raw inputs to judgment.
- 2
Structure into intent
Turn the strongest signals into an IntentSpec. Every spec traces back to evidence, not assumptions.
- 3
Execute with agents
Hand the spec to Claude Code, Cursor, or Codex. A good spec produces working code on the first pass, or surfaces exactly where it was ambiguous.
- 4
Verify and close the loop
Check the verification criteria, then check whether the outcomes actually materialised. That evidence feeds the next round.
Questions
- Do I need a tool to do intent engineering?
- No. You can hand-author an INTENT.md file in any editor and validate it in CI. The template above is a starting point. A tool like Pathmode helps you go from scattered user evidence to a structured spec faster, but the discipline is tool-agnostic.
- What does an IntentSpec include?
- Eight parts an agent needs to act without guessing: objective, outcomes, evidence, constraints, scope, edge cases, health metrics, and verification. It follows the open IntentSpec standard (v1.2), so any agent or validator can read it.
- Who owns intent engineering, product or engineering?
- Whoever holds the evidence and makes the call. Intent engineering sits deliberately above the PM-vs-engineer line. It is for builders making products with AI. The person closest to the user problem authors the intent; the agent, and the engineer reviewing it, act against it.
Turn evidence into intent. Turn intent into shipped software.
Pathmode is the platform built for intent engineering: capture evidence, compile IntentSpecs with AI, and export to any agent.