Kapil Viren Ahuja's IDSD post lands a real punch on Spec-Driven Development and then steps directly into the same trap. IDSD (Intent-Driven Software Development) is SDD with a new acronym. Both should go.
This is a friendly critique. He gets the diagnosis right. The prescription is the wrong shape.
The short version
Spec-Driven Development is a 2025 consulting cycle that turned tools like spec-kit, Kiro, BMAD, Tessl, and Agent OS into a methodology. Kapil Viren Ahuja correctly names SDD as overfit and rigid. His proposed replacement, Intent-Driven Software Development (IDSD), is the same artifact stack with a different sticker. Intent documents are PRDs that do not admit they are PRDs. The actual fix is to remove the methodology layer entirely. The prototype is the spec. The eval is the acceptance test. There is no document between intent and ship.
For the broader argument, see Kill the PRD: The Prototype Is the Spec and The Five-Row Eval Template That Replaced My PRD. For the pillar this sits inside, see the handbook chapter The Eval Is the Spec.
What the IDSD post gets right
Two things, both worth crediting.
First, the diagnosis of SDD is correct. GitHub's spec-kit and the wave that followed it (AWS Kiro, Tessl, BMAD, Agent OS) all share a premise that is now visibly wrong. The premise was that LLMs need a complete up-front spec because they are "exceptional at pattern completion, but not at mind reading." That premise made sense for fifteen minutes in late 2024. By mid-2026, agents that read your repo, your evals, your usage telemetry, and your last six commits do not need a 30-page spec document. They need a prototype to extend and an eval to satisfy.
SDD is the 2025 version of the methodology consulting cycle. It was sellable, it produced training revenue, it generated certifications, and it is going to age the way every other consulting cycle aged.
Second, Ahuja is right that iterative development is not new. He correctly cites Larman and Basili's 2003 IEEE paper on the long history of iterative practice and notes that even Royce questioned the single-pass waterfall ideal from the start. This is the right intellectual move. The conversation about "what is new in software development" almost always recovers something older that was abandoned for organizational reasons, not technical ones.
These two points stand on their own. If the article had stopped there, I'd be sharing it.
Where IDSD goes wrong
The argument runs into the same wall it was supposed to dismantle.
SDD says: write a spec, the agent builds from the spec. IDSD says: write an intent document, the agent builds from the intent. The artifact's name changed. The shape of the methodology did not.
Both methods:
- Insert a document between intent and shipped code
- Require a vocabulary, a set of ceremonies, and an artifact template
- Produce a consulting engagement, a training program, and a tool vendor ecosystem
- Make the methodology itself the load-bearing thing
The intent document is just a PRD that does not admit it is a PRD. It has a why, a what, a scope boundary, a success criterion, and an open-questions section. That is the PRD. Calling it intent does not change the artifact. It changes the sales pitch.
The deeper tell is in the post's closing line. The reason to adopt IDSD, Ahuja writes, ends "on the client's invoice." That's a consulting frame. The audience for IDSD is the agency selling AI engagements to enterprises. The argument is that the agency can charge differently if the methodology changes. That may be true. It is not an argument about how to build software better.
What actually replaces SDD
The prototype is the spec. The eval is the acceptance test. There is no document in between.
A 2026 builder PM or AI-augmented engineer does this:
- Reads the existing code, evals, telemetry, and last six commits with an agent in the loop
- Ships a four-to-six-hour prototype that customers can actually touch
- Writes a five-row eval that defines "done" as falsifiable behavior, not a checklist
- Ships when the eval passes the threshold
There is no intent document. There is no spec document. There is no methodology training. The artifacts that exist (the prototype, the eval rubric, the short README) are working code, not prose. They are testable, not subject to interpretation. They are also small enough that a four-person pod can hold the whole thing in their heads.
This is not a new methodology. It is the absence of one.
The reason this works in 2026 and would not have worked in 2015 is that the cost of producing a working prototype collapsed. Claude Code, Cursor, the agent layer underneath them: these turned the spec-document era into the prototype era. The methodology vendors are still selling against a problem that no longer has the same shape.
Why the methodology layer keeps coming back
Look at the sequence. Waterfall. Rational Unified Process. Agile. SAFe. Design thinking. Lean. Spec-Driven Development. Intent-Driven Software Development. Whatever comes in Q3.
The shape is identical every time:
- A vocabulary that sounds like progress
- A set of artifacts that get templated
- A training program that gets certified
- A tool vendor that sells the templates
- A consulting engagement that sells the certification
The methodology is the product. It cannot be otherwise, because if the methodology were not the product, the people selling it would have to sell the underlying outcome, which is harder and harder to defend per billable hour.
Builders do not need this. Builders need: a prototype, an eval, telemetry, an outcome ledger, and a small team. None of those things have a certification track.
Consultants and tool vendors need this. They need a vocabulary to sell. SDD gave them one for a year. IDSD is the attempt to extend the cycle by another year.
What to do if your team is being pitched IDSD
Three things.
First, ask whether the team is currently shipping. If you have a backlog of unshipped work, the methodology is not your problem. The flow is your problem. No intent document will move that.
Second, ask what the eval looks like for the next thing you ship. Not the spec, not the intent, not the PRD. The eval. If your team cannot describe the eval rubric for the next feature in five rows, the team is missing the artifact that actually does the work. See The Five-Row Eval Template.
Third, run a parallel test. One pod ships its next feature with the IDSD intent-document workflow. One pod ships with prototype + eval. Compare in two weeks. The prototype + eval pod will ship first, have a smaller artifact, and have a tighter feedback loop. The intent-document pod will produce a beautiful document. Both pods will tell you which methodology layer is load-bearing for your org.
The friendly disagreement
Ahuja is a sharp writer and the IDSD article is the rare methodology piece that names a real failure mode. The disagreement is narrow.
If the argument were "SDD is wrong because methodology layers between intent and ship are the bottleneck," I would be a co-signer. If the argument were "intent matters more than the spec document," same.
The argument as written is "SDD is wrong, here is a new methodology layer with a different name." That is the consulting cycle's autonomic response to its own failure: rebrand and re-sell. The honest version of the same critique is shorter. Kill the document. Ship the prototype. Write the eval. The methodology layer is the cost, not the cure.
The five-row eval template, the prototype-as-spec walkthrough, and the README format that replaces both PRDs and intent docs are on the toolkit. For the broader argument about killing the methodology layer, see Agile Is a Coping Mechanism and Kill the OKR.
Sources: Kapil Viren Ahuja's IDSD post on Activated Thinker, GitHub spec-kit announcement, Larman and Basili on iterative history (IEEE 2003), Royce on waterfall, intent-driven.dev, Claude Code.
Further reading
Frequently asked
What is IDSD?+
Intent-Driven Software Development. A methodology proposed by Kapil Viren Ahuja in May 2026 as the replacement for Spec-Driven Development (SDD). The pitch is that you write an intent document up front instead of a spec, then let the agent build from intent. The shape is identical to SDD. The artifact name changed.
What is Spec-Driven Development (SDD)?+
A methodology that emerged in 2025 around tools like GitHub's spec-kit, AWS Kiro, Tessl, BMAD, and Agent OS. The premise is that LLMs are 'good at pattern completion but bad at mind reading,' so the fix is to write a detailed spec up front. The agent then builds from the spec. It's the PRD with a new file extension.
Why are IDSD and SDD the same shape?+
Both insert a document between intent and shipped code. Both require a methodology layer (steps, ceremonies, artifact templates). Both are marketed by consulting and tool vendors. The intent document is just a PRD that doesn't admit it's a PRD.
What's the alternative?+
The prototype is the spec. The eval is the acceptance test. There is no methodology between intent and ship. A builder PM (or AI-augmented engineer) ships a working prototype in four hours, the eval rubric defines done, and the artifact in the repo IS the documentation. No intent doc, no spec doc, no methodology.
Where does the IDSD post actually get it right?+
Two places. First, it correctly diagnoses that SDD is overfit, brittle, and dependent on the spec being right before anything moves. Second, it admits SDD is not new and that iterative development has been the better path since the 1950s (citing Larman and Basili's 2003 IEEE paper). Both points are right and worth saying.
Why does the methodology layer keep coming back?+
Because it is sellable. SDD and IDSD both come with templates, certifications, tools, and consulting hours. The methodology is the product. Every consulting cycle (waterfall, RUP, agile, SAFe, design thinking, SDD, IDSD) follows the same shape: a vocabulary, a set of artifacts, a training program, a billable engagement. Builders don't need this. Consultants do.
Is the answer 'just vibe code'?+
No. Vibe coding fails for the reason the SDD pitch correctly identifies: you get something that looks right and doesn't quite work. The answer is not 'vibe code with no spec,' and it is not 'spec or intent doc up front.' The answer is the prototype + the eval. Both are working code. Both are testable. Neither is a methodology.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn