What is intent engineering?
Intent engineering is the discipline of turning product judgment under evidence into specifications an AI agent can execute without guessing, then verify against the real user problem. It is the practice of deciding what to build, for whom, and on what evidence, then making that decision explicit enough to delegate to an autonomous coding agent.
Traditional product workflows rely on tickets, PRDs, and verbal handoffs, formats that assume a human will fill in the gaps. AI coding agents cannot fill those gaps. They need a specification that states exactly what should happen, what success looks like, where the boundaries are, and how to prove it worked.
Intent engineering closes that gap. Instead of a ticket that says "improve checkout speed," an intent-engineered spec names the user friction, the measurable outcome, the constraints, and the verification criteria, in a format an agent can execute without follow-up questions.
Intent is judgment under evidence, not a contract you compile. A spec without the evidence and trade-offs behind it is just a more detailed guess.
Pathmode lays out the full intent engineering framework, with a worked example, the eight-part IntentSpec, and a downloadable INTENT.md template.
Two definitions of intent engineering
Search for "intent engineering" today and you will find two competing definitions. The distinction matters, because they point teams in opposite directions.
The prevailing view: intent as a contract. Most current frameworks treat intent engineering as writing a precise, machine-interpretable specification: an INTENT.md, a spec-driven-development artifact, a "contract" the agent compiles into code. The goal is to remove ambiguity so the agent executes without deviation. This is the framing behind spec-driven development and the emerging "Intent Engineer" role.
The judgment 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, done well, captures the judgment behind the work (which user problem, on what evidence, with which trade-offs accepted and which outcomes must hold), and only then compiles that judgment into something executable.
The difference is not academic. A contract optimizes for fidelity: the agent builds exactly what the spec says. Judgment optimizes for correctness of the decision itself: it makes sure the spec is worth building before a single token is spent. Precision without judgment just lets you build the wrong thing faster. Intent engineering is the discipline that produces the judgment; the spec is its output, not its substitute.
The three layers: prompt, context, and intent
Modern AI work runs on three interdependent layers. Most explanations describe them; the distinction that matters is what each one is responsible for.
- Prompt layer. The instruction for a single model turn: wording, examples, format. Better question.
- Context layer. What the agent can see before it acts: retrieval, conversation history, tools, file structure. Better inputs.
- Intent layer. The judgment about what should be built and how you'll know it worked: the user problem, the evidence, the constraints, the outcomes, the verification. Better problem definition.
You need all three. But prompt and context engineering both assume someone has already decided what to build and what "done" means. Intent engineering is where that decision is made, and made explicit enough to hand off. Context isn't judgment. An agent can have a perfect context window and still build the wrong thing, confidently, because nobody supplied the intent.
Why it matters now
The rise of AI coding agents (Claude Code, Cursor, GitHub Copilot) has moved the bottleneck in software development. Writing code is no longer the hard part. Deciding what to build and specifying it precisely enough for an autonomous agent is.
Teams that write precise, evidence-backed intent get dramatically better output from AI agents. Teams that prompt with vague descriptions get hallucinated features, wasted tokens, and manual rework that erases the speed gains AI was supposed to deliver.
This is not a tooling problem. It is a specification problem, and underneath that, a judgment problem. Intent engineering treats specification as a first-class engineering discipline, not an administrative chore that happens in a ticket tracker five minutes before sprint planning.
A concrete example
Your analytics show that 35% of users abandon onboarding at step 3 of 5.
Without intent engineering, the ticket says: "Fix onboarding drop-off." An AI agent receiving this has to guess what "fix" means, which step to focus on, what success looks like, and what it's allowed to change. It might restructure the entire flow, remove required fields, or make cosmetic changes that don't address the underlying problem.
With intent engineering, the spec says:
- Objective: Users abandon onboarding at step 3 (address entry) because the form requires 6 fields when auto-complete could reduce it to 1. This costs ~200 signups/week.
- Outcomes: Address entry uses a type-ahead geocoding field. The 6 individual fields collapse to a single search input. Users who select a suggested address complete onboarding in under 90 seconds and proceed to step 4 in under 10 seconds. Drop-off at step 3 decreases by at least 40%.
- Edge Cases: If the geocoding API is unavailable, fall back to the existing manual form. Addresses outside supported regions show a clear "not yet available" message. PO Box addresses must still be enterable manually.
- Health Metrics: Completion rate for steps 1–2 does not drop; downstream address-validation accuracy stays the same.
- Verification: Integration test confirms geocoding lookup returns results for 5 sample addresses. Fallback test confirms the manual form renders when the API returns a 500. Load test confirms p95 response time under 300ms.
The agent now has everything it needs. No guessing, no hallucinated features, no follow-up questions, and a definition of "done" it can verify against.
Intent engineering vs prompt engineering vs context engineering
These three disciplines are often confused. They operate at different layers of the AI stack and solve different problems.
Prompt engineering is the craft of writing a single instruction to get a better response from a language model. It is tactical and conversational: choosing the right words, examples, and formatting to guide one AI turn.
Context engineering is the practice of curating what information an AI sees before it acts: system prompts, retrieved documents, prior messages, available tools, file structure. It focuses on the agent's working memory.
Intent engineering structures what should be built and how to verify it, independent of which model, prompt, or context window you use. It produces a durable, testable artifact (an IntentSpec) that any agent can execute, and a definition of success you can check afterward.
A useful mental model:
- Prompt engineering: better question
- Context engineering: better inputs
- Intent engineering: better problem definition
Prompt and context engineering both assume someone has already decided what to build and how to know if it worked. Intent engineering is what makes that decision explicit and machine-readable.
Is intent engineering the same as spec-driven development?
Related, but not the same. The difference is the whole point.
Spec-driven development is about the form of the artifact: write a detailed, machine-readable spec, hand it to the agent, get deterministic output. It is a discipline of precision.
Intent engineering is about the judgment upstream of the artifact: deciding which problem is worth solving, proving it with evidence, choosing the trade-offs, and defining how you'll verify the user problem actually moved. You can write a flawless spec for a feature nobody needs. Intent engineering exists to make sure the spec is worth compiling in the first place.
Spec-driven development asks, "Is this spec precise?" Intent engineering asks first, "Is this spec right, and how will we know?"
How it differs from traditional spec writing
| PRD | User Story | Prompt Engineering | Intent Engineering | |
|---|---|---|---|---|
| Focus | Feature description | User desire | Single AI interaction | Structured user problem |
| Defines success | Implicitly | Acceptance criteria | ✗ Not at all | ✓ Measurable outcomes |
| Handles edge cases | ✗ Rarely | ~ Sometimes | ✗ Never | ✓ Explicitly |
| Grounded in evidence | ~ Occasionally | ~ Varies | ✗ No | ✓ Always |
| Machine-executable | ✗ No | ✗ No | ~ Partially | ✓ Yes |
| Verifiable | By humans | By humans | ✗ No | ✓ By tests + agents |
| Durability | Document that drifts | Ticket that closes | Ephemeral conversation | ✓ Versioned artifact |
A PRD says "add a dashboard." An intent spec says "users can't find their weekly metrics: surface them in under 2 clicks with less than 500ms load time." A user story captures what someone wants. An intent spec adds why it matters (evidence), what "done" means (outcomes), and what must not break (health metrics and edge cases).
The eight parts of an IntentSpec
Every intent spec follows a consistent structure:
1. Objective. What user problem are you solving and why does it matter? Grounded in evidence: a support ticket, a metric, a user quote, a behavioral signal. Not "we think users want X" but "we observed users struggling with Y."
2. Outcomes. Observable, measurable state changes. Not "improve performance" but "p95 response time under 200ms." Every outcome should be verifiable by a test or a metric.
3. Evidence. Linked real user signals: friction points, quotes, observations, metrics, feature requests. If you can't link to actual user evidence, you shouldn't be building it.
4. Constraints. Hard boundaries the implementation must respect: security requirements, architectural limits, business rules. What the agent must NOT do.
5. Scope. What the implementation may touch, and what it must leave alone. The "out of scope" fence stops an agent from refactoring code you never asked it to change.
6. Edge Cases. Boundary conditions, failure modes, and scenarios that could break the implementation. What happens when the network is down? What about empty states? What if the user has 10,000 items instead of 10?
7. Health Metrics. What must NOT degrade once this ships. Outcomes say what should change; health metrics name what should stay true, so the agent doesn't quietly break one thing while improving another.
8. Verification. How do you confirm it works? Unit tests, integration tests, manual checks. This closes the loop: the agent knows exactly what "done" looks like and can verify its own work.
How teams practice intent engineering
Intent engineering is not a one-time documentation exercise. It is a workflow that connects user research to shipped software:
1. Capture friction. Collect signals from support tickets, user interviews, analytics drop-offs, NPS comments, and session recordings. These are the raw inputs.
2. Structure into specs. Take the strongest friction signals and write intent specs using the eight-part format. Each spec should trace back to real evidence, not assumptions.
3. Execute with agents. Hand the spec to an AI coding agent. A well-written spec should produce a working implementation on the first pass, or surface specific questions where the spec was ambiguous.
4. Verify and ship. Use the verification criteria in the spec to confirm the implementation works. If it doesn't, the problem is usually in the spec, not the agent.
5. Close the loop. After shipping, check whether the outcomes you specified actually materialized. Did the drop-off decrease? Did the response time improve? This evidence feeds back into the next round of specs, and back into the judgment behind them.
Who needs intent engineering
Intent engineering is most valuable for builders making products with AI coding agents. This includes:
- Product managers who write specs that AI agents will execute
- Engineering leads who want consistent, reviewable specifications across their team
- Founders and solo builders who use AI agents to move faster without sacrificing precision
- Design teams who need to translate user research into actionable development specs
If you are handing work to an AI agent and the output is unpredictable, the problem is almost certainly in the specification, and underneath it, the judgment the specification was supposed to carry. Intent engineering is the fix.