The goal of IDD is not to prescribe what developers do. It is to give them enough context to decide for themselves.
Most discussions about AI-assisted development focus on speed — how fast can we generate code? But speed was never the real problem. The real problem is decision bottlenecks.
In a typical agile team, developers constantly wait:
- "Is this what the PO meant?" → Wait for clarification
- "Should I handle this edge case or is it out of scope?" → Wait for refinement
- "Can I use this library or does it conflict with something?" → Wait for the tech lead
- "Does this need to match the existing pattern or can I try something better?" → Wait for architecture review
- "The story says 'handle errors gracefully' — what does that mean here?" → Wait for the PO again
Each of these waits is a decision that the developer could have made if they had sufficient context. The sprint model tries to front-load this context in planning meetings, but a 2-hour planning session can't transfer enough context for 2 weeks of decisions. So developers either guess (and risk rework) or wait (and lose momentum).
AI agents make this problem worse, not better. An AI agent that encounters ambiguity doesn't wait — it guesses. And it guesses at machine speed, producing wrong output faster than anyone can catch it.
IDD's hierarchy is not a management structure. It is a context delivery system.
Product → "Here's why this exists and who it's for."
Intention → "Here's what we're trying to accomplish and why it matters."
Expectation → "Here's how we'll know it's right, including the edge cases."
Spec → "Here's everything you need to build it — stack, patterns,
conventions, boundaries, and what done looks like."
When a developer (or an AI agent) has all four layers, they can answer most questions themselves:
| Question | Where the Answer Lives |
|---|---|
| "Is this in scope?" | Boundaries — explicit list of what's in and out |
| "How should I handle this edge case?" | Expectations — enumerated with expected behavior |
| "What patterns should I follow?" | Context — stack, patterns, conventions declared |
| "Does this align with what the product needs?" | Intentions — the outcome we're trying to achieve |
| "Why are we building this at all?" | Product — the problem statement and value proposition |
| "Can I make this architectural decision?" | Context + Boundaries — conventions define the norm, Boundaries define the limits |
The developer doesn't need to ask the PO because the PO's intent is already embedded in the artifacts. The developer doesn't need to wait for the tech lead because the architectural constraints are declared in Context. The developer doesn't need to guess about scope because Boundaries make it explicit.
Within the boundaries of a Spec, developers (and AI agents) have full autonomy over implementation decisions:
- How to implement an Expectation (algorithm choice, component structure, data flow)
- How to organize code within the declared patterns
- How to write tests that verify the validation criteria
- When to split work into smaller commits or PRs
- Whether to push back on a Spec — flagging Expectations that are contradictory, Boundaries that are too restrictive, or Context that's outdated
Only these require going back to a PO or Spec Author:
- A new Expectation is needed that wasn't anticipated (new scope)
- An Intention seems wrong based on what was learned during implementation
- Boundaries conflict with each other or make the Spec impossible
- The Product vision doesn't match what stakeholders actually need
Notice the pattern: developers escalate strategic questions (are we building the right thing?) and resolve tactical questions (how do we build it?) independently. This is the inversion that IDD enables.
User stories are deliberately thin: "As a user, I want X so that Y." The theory is that conversation fills in the gaps. In practice:
- The conversation happens once (in planning) and is partially forgotten
- Context lives in people's heads, not in artifacts
- New team members or AI agents have no access to the conversational context
- Developers with questions either interrupt someone or make assumptions
The result is a team where knowledge is centralized in the PO's head and decisions flow through a single person. This doesn't scale. It especially doesn't scale when AI agents are generating code and need unambiguous context to do it well.
IDD externalizes context into artifacts. The PO's knowledge about why the product exists becomes the Product definition. Their understanding of what it should do becomes Intentions. Their criteria for how we'll know it's right becomes Expectations. The tech lead's architectural knowledge becomes the Context block. The scope decisions become Boundaries.
Once this context is externalized, anyone — developer, AI agent, new team member — can pick up a Spec and make good decisions without waiting for the person who originally held the knowledge.
The Spec Author is not a bottleneck — they're a context translator. Their job is to ensure that the Product Owner's intent and the Tech Lead's architectural knowledge are captured in a format that enables autonomous execution.
A good Spec Author asks: "If a developer picked this up with no other context, could they make every implementation decision without asking anyone?" If the answer is no, the Spec isn't done.
This is why the completeness checklist exists. It's not bureaucracy — it's a quality gate for context sufficiency. Every checklist item represents a category of decision that would otherwise require someone to wait for an answer:
| Checklist Item | Decision It Enables |
|---|---|
| Context: stack populated | Developer knows what technologies to use |
| Context: patterns populated | Developer knows what architectural patterns to follow |
| Context: conventions populated | Developer knows the team's coding standards |
| Context: auth populated | Developer knows the security model without asking |
| Expectations with validation criteria | Developer knows what "done" means without asking the PO |
| Expectations with edge cases | Developer knows how to handle boundary conditions |
| Boundaries populated | Developer knows what's out of scope without guessing |
| Deliverables populated | Developer knows exactly what to produce |
You can observe whether IDD is delivering autonomy by watching for:
- Fewer interruptions during execution. Developers ask fewer questions of POs and tech leads during the Execute phase.
- Faster first-pass rate. When developers have enough context, their output matches expectations on the first try more often.
- Shorter review cycles. When boundaries are explicit, reviewers spend less time debating scope.
- New team member ramp-up. A new developer should be able to pick up a Spec and execute it without a lengthy onboarding conversation.
If your team adopts IDD and developers are still constantly asking the PO for clarification, the problem is spec quality, not the developers. The completeness checklist should catch this, and the First-Pass Rate metric will reveal it over time.
IDD is not about control. It's about context.
The hierarchy doesn't tell developers what to do — it tells them enough that they can decide for themselves. The Spec isn't a set of orders — it's a context package that enables autonomous, high-quality execution.
The best indicator that IDD is working: a developer picks up a Spec, builds it, and the PO's reaction is "yes, that's exactly what I meant" — without a single clarification conversation in between.