Researching Intent Driven Development Revealed the Gap Sprouted Fills

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 previous 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 previous 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

graph TD
    subgraph "IDD's WHY/WHAT/HOW"
        I_WHY["WHY: Background (settled)"]
        I_WHAT["WHAT: Functional requirements"]
        I_HOW["HOW: Task list"]
        I_WHY --> I_WHAT --> I_HOW
    end

    subgraph "Sprouted's Why/What/How"
        S_W1["Why: Motivation + constraints (hypothesis, with confidence)"]
        S_What1["What: Goal (multiple candidates)"]
        S_How1["How: Choice of means (rejection reasons preserved)"]
        S_W1 --> S_What1 --> S_How1

        S_W2["Why: Parent's What → motivation / How → constraints"]
        S_What2["What: ..."]
        S_How2["How: ..."]
        S_How1 -.->|"Constraint chaining"| S_W2
        S_What1 -.->|"Motivation chaining"| S_W2
        S_W2 --> S_What2 --> S_How2
    end

    style I_WHY fill:#8B4513,color:#fff
    style I_WHAT fill:#3a7bd5,color:#fff
    style I_HOW fill:#e67e22,color:#fff
    style S_W1 fill:#4a9e4a,color:#fff
    style S_What1 fill:#3a7bd5,color:#fff
    style S_How1 fill:#e67e22,color:#fff
    style S_W2 fill:#4a9e4a,color:#fff
    style S_What2 fill:#3a7bd5,color:#fff
    style S_How2 fill:#e67e22,color:#fff

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 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.

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.

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 previous article. The repository is published on GitLab.

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