Disclaimer: This article was written with the assistance of generative AI for idea refinement and writing, reviewed by aka.
Hey, it's aka.
In my article, I published a framework called Sprouted — a framework that manages decision-making through hypothesis trees.
Shortly after publishing, I noticed that Intent Driven Development (IDD) was gaining momentum. "Intent-driven development." The name alone suggested it was covering territory close to Sprouted, so I had to investigate.
As far as I could find, none of the existing IDD approaches cover the same territory as Sprouted. Even though they use the same words — "WHY/WHAT/HOW" — the substance turned out to be quite different.
In this article, I'll share the investigation process and what I found.
About IDD
Let's start by laying the groundwork.
IDD (Intent Driven Development) has no established definition. Multiple proponents independently use the same name, each with different concerns and approaches. The only common thread is the direction: "Before having AI implement something, clarify your intent."
What the Proponents Are Saying
Interestingly, IDD wasn't coined by a single person. Multiple people independently arrived at the same direction.
John Ferguson Smart
John Ferguson Smart was the first to use the term "Intent-Driven Development" in 2017, in the context of BDD (Behavior-Driven Development). He articulated a hidden principle of BDD: "declare your intent before acting." However, this was before the AI coding era and is a different conversation from today's IDD. No concrete implementation or tooling exists.
Scott Molinari
Scott Molinari frames IDD in three phases: Definition, Generation, and Verification. He also proposed the concept of an "Immutable Skeleton" — an unchangeable skeleton composed of contracts, constraints, and policies, within which AI implements. His core argument is captured in the metaphor: "AI drives the car, humans build the road." The philosophy is clear — humans should maintain architectural authority — but there are no concrete tools or implementations.
Paulo Renato (Exadra37)
Paulo Renato (Exadra37) has published a more practical approach on GitHub. Intent documents have WHY/WHAT/HOW sections, AI agents are instructed to behave as a "Staff SE (10+ years of experience)," user approval is required after each subtask, and TDD is enforced. Currently Elixir/Phoenix-specific, but in terms of having concrete development conventions and templates, this is the most implementation-mature IDD out there.
Binoy Ayyagari
Binoy Ayyagari proposes "Adaptive Intent-Driven Development (AIDD)." It combines Agile's iteration and adaptation with IDD's intent definition, envisioning autonomous agents running iterations based on Intents. However, there's no concrete methodology or tooling — it remains a conceptual proposal.
copyleftdev
copyleftdev has written about applying IDD to an actual project. The concrete pipeline: define 122 event types with AsyncAPI, write 8 RFCs, convert to JSON schemas, and auto-generate GitHub Issues. The problem being solved is automating the decomposition of high-level designs into tasks — structuring decisions or managing hypotheses is out of scope.
KodeNerds
KodeNerds brings a unique perspective: "treat specifications as verifiable hypotheses." Their approach combines Lean Startup's build-measure-learn cycle with IDD. However, no concrete tools or mechanisms exist.
Patrick Debois
Patrick Debois (the person who coined "DevOps") has apparently discussed IDD on a podcast. I haven't listened to it yet, so I'll skip the details.
These proponents — despite differences in specifics — are all facing the same direction: "Structure your intent before handing it to AI." When multiple independent thinkers converge, there's a fundamental problem worth solving.
Workflows Are All Over the Place
So how do you actually develop with IDD? This varies wildly by proponent.
- Scott Molinari proposes Definition → Generation → Verification in 3 phases
- Exadra37 follows WHY/WHAT/HOW Intent document → Task decomposition → TDD implementation
- copyleftdev uses Intent definition → RFC → JSON conversion → GitHub Issues generation → Implementation → Verification in 5 stages
- KodeNerds goes with Intent mapping → Validate as hypothesis → Build-measure-learn, closer to Lean Startup
The only common thread is the big picture: "First articulate your intent, then have AI implement it." The concrete processes are not unified. Honestly, IDD is still a "way of thinking" rather than an established methodology.
That said, I think the idea of "clarify intent first" is right. Defining intent before handing things to AI produces better quality than vague prompts like "make it work nicely." I affirmed this same direction in my Sprouted article.
That covers the IDD overview. So where does Sprouted differ?
Exadra37's IDD and Sprouted — Same WHY/WHAT/HOW, Different Substance
The most interesting find in my research was Exadra37 (Paulo Renato)'s IDD project. It has the highest completeness among IDD approaches, with Intent document templates, development conventions, and AI agent instruction documents all published on GitHub.
Sprouted also uses Why/What/How. Same words. But when you compare the contents, they're completely different things.
Exadra37's WHY/WHAT/HOW
In IDD, WHY/WHAT/HOW are sections within a single Intent document.
- WHY: Background explanation for this Intent. No mechanism for managing confidence levels or hypothetical nature
- WHAT: What you want to achieve. Functional requirements description
- HOW: Implementation task checklist. Work management
In other words, for a single feature you write "background → requirements → tasks." You can create multiple Intent documents, but each Intent is a "self-contained document" that stands independently — there are no parent-child relationships or hierarchical structures between Intents. They're managed flat, kanban-style (todo/work-in-progress/completed).
Sprouted's Why/What/How
In Sprouted, Why/What/How form a recursively chaining structure.
- Why: Motivation and constraints inherited from the parent node. With confidence scores
- What: What you want to achieve. Multiple candidates possible
- How: Choice of means. Select from multiple candidates, with rejection reasons preserved
And then, a node's How becomes the constraints for the next level's Why, and its What becomes the motivation. This chain continues as deep as needed.
Side by Side
┌─────────────────────────────────┐ ┌─────────────────────────────────────────┐
│ IDD's WHY/WHAT/HOW │ │ Sprouted's Why/What/How │
│ │ │ │
│ WHY: Background (settled) │ │ Why: Motivation + constraints │
│ │ │ │ (hypothesis, with confidence) │
│ ▼ │ │ │ │
│ WHAT: Functional requirements │ │ ▼ │
│ │ │ │ What: Goal (multiple candidates) │
│ ▼ │ │ │ │
│ HOW: Task list │ │ ▼ │
│ │ │ How: Choice of means │
│ (flat, self-contained doc) │ │ (rejection reasons preserved) │
│ │ │ │ │
│ │ │ ┌─────┴─────┐ │
│ │ │ │ chaining │ │
│ │ │ ▼ ▼ │
│ │ │ Why (constraints) Why (motivation) │
│ │ │ │ │
│ │ │ ▼ │
│ │ │ What → How → ... (recurses) │
└─────────────────────────────────┘ └─────────────────────────────────────────┘
Same words, fundamentally different structure.
IDD's WHY/WHAT/HOW is a flat 3-section layout. No mechanism for managing hypothetical nature. Sprouted is a recursive tree structure. Every level has the same structure, is treated as a hypothesis, and is managed with confidence scores.
The Treatment of Intent Also Differs
Beyond structure, how Intent is treated is also fundamentally different.
In Exadra37's IDD, there's no mechanism for managing whether an Intent is "hypothetical or not." Status changes from todo → work-in-progress → completed, but there's no feature for handling the "certainty" of the Intent itself. In other words, the structure implicitly operates on the assumption that "what's written is correct."
Sprouted takes an explicit stance here. Every node is a hypothesis. Requirements, specifications, designs — they all exist on a gradient of confidence. Nothing is settled.
| Exadra37's IDD | Sprouted | |
|---|---|---|
| Treatment of Intent | No mechanism for managing hypothetical nature | Everything is a hypothesis |
| Confidence management | None | confidence score |
| Responding to changes | Rewrite Intent | Update hypothesis + propagate impact |
Exadra37's Strengths
On the other hand, Exadra37's strength is in "translating to development process." Intent document templates, role definitions for AI agents, enforced TDD, approval flow after each subtask — mechanisms you can use immediately on the ground are well-organized. Sprouted focuses on structuring decisions and doesn't currently provide these kinds of development process conventions.
How Other IDD Proponents Differ from Sprouted
Let's compare with proponents beyond Exadra37.
| Proponent | Core concern | Overlap with Sprouted |
|---|---|---|
| John Ferguson Smart | Intent declaration as a BDD principle | None. Predates AI coding |
| Scott Molinari | Humans maintain architectural authority | Close philosophically, but no mechanisms |
| Binoy Ayyagari | Vision for Agile + IDD fusion | Direction is close, but conceptual-level proposal only |
| copyleftdev | Automation pipeline: Intent → RFC → Issues → Implementation | Task management efficiency. Decision structuring is out of scope |
| KodeNerds | Treat specifications as verifiable hypotheses | Closest. But no hypothesis management mechanisms (confidence score, etc.) |
KodeNerds' idea of "treating things as hypotheses" is close to Sprouted. However, "how to manage hypotheses" — confidence scores, validation/rejection lifecycle, impact propagation when assumptions break — these mechanisms aren't proposed. The thinking is close, but the concreteness as a framework differs. That said, Sprouted's confidence management is still in an immature stage too.
Summary
Here's a summary of the differences between Sprouted and other IDDs.
| IDD | Sprouted | |
|---|---|---|
| Clarify intent before implementation | Yes | Yes |
| WHY/WHAT/HOW structure | Yes | Yes |
| Intent document templates/formats | Yes | - |
| AI agent instruction documents/role definitions | Yes | - |
| Development process conventions like enforced TDD | Yes | - |
| Task decomposition and progress tracking | Yes | - |
| Hypothesis management (confidence score) | - | Yes |
| Recursive decision structure (tree structure) | - | Yes |
| Candidate management (preservation of rejection reasons) | - | Yes |
| Recursive Why → What → How chaining | - | Yes |
| Impact propagation when upstream assumptions break | - | Yes |
When I suddenly discovered IDD, I honestly considered taking down the Sprouted article entirely if an identical framework already existed. IDD's direction of "clarify intent before handing it to AI" is right, and Exadra37's translation into development processes has a lot to teach. On the other hand, the territory of "structuring decisions as hypotheses" that Sprouted covers — nobody had dug deeply into that yet, so I decided to keep it up.
For details on Sprouted, see my article.
See you.
References
IDD proponents and explanations:
- Intent-Driven Development - the hidden key to BDD — John Ferguson Smart, 2017
- Intent Driven Development (IDD) is our Current Future — Scott Molinari
- AI Intent Driven Development — Paulo Renato (Exadra37), GitHub
- From Agile to Adaptive Intent-Driven Development (AIDD) — Binoy Ayyagari
- Intent-Driven Development with Patrick Debois — The AI Native Dev Podcast
- Intent Driven Development: Define the System Before You Write the Code — copyleftdev
- Intent-driven development 2026 — KodeNerds
- Context Engineering & Spec-Driven Development — intent-driven.dev
Top comments (1)
note:
I published my blog(
blog.akapersonal.com) at the beginning of March, but it hasn't been indexed by Google yet, so I cross-posted it here. Therefore, I won't see any comments or anything posted here.