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. This is a friendly critique: he gets the diagnosis right, the prescription is the wrong shape, and neither is worth adopting.
What the critique 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: 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 about fifteen minutes in late 2024. By mid-2026, agents that read your repo, your evals, your telemetry, and your last six commits do not need a 30-page spec. They need a prototype to extend and an eval to satisfy. Second, Ahuja is right that iterative development is not new. He cites Larman and Basili's 2003 IEEE paper on the long history of iterative practice, and notes Royce questioned single-pass waterfall from the start. Both points are correct.
Where it 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 methodology's shape did not. Both insert a document between intent and shipped code, both require a vocabulary and ceremonies and an artifact template, and both produce a consulting engagement, a training program, and a tool vendor ecosystem. The intent document has a why, a what, a scope boundary, a success criterion, and an open-questions section. That is a PRD. Calling it intent changes the sales pitch, not the artifact. The tell is in the post's own closing line, which puts the reason to adopt IDSD "on the client's invoice." That is a consulting frame, not an argument about how to build software better.
What actually replaces it
The prototype is the spec. The eval is the acceptance test. There is no document in between. A 2026 builder reads the existing code, evals, telemetry, and last six commits with an agent in the loop, ships a four-to-six-hour prototype a customer can touch, writes a five-row eval that defines done as falsifiable behavior, and ships when the eval passes. No intent doc, no spec doc, no methodology training. The artifacts that exist are working code, testable rather than open to interpretation, and small enough that a four-person pod holds the whole thing in their heads. This is not a new methodology. It is the absence of one.
The methodology layer keeps coming back because it is sellable. Waterfall, RUP, agile, SAFe, design thinking, lean, SDD, IDSD: same shape every time, a vocabulary, templated artifacts, a certification, a tool vendor, a consulting engagement. The methodology is the product.
If your team is being pitched IDSD, do three things. Ask whether the team is currently shipping, because if you have a backlog of unshipped work the flow is your problem, not the methodology. Ask what the eval looks like for the next feature. And run a parallel test: one pod ships with the intent-document workflow, one ships with prototype plus eval, compare in two weeks. The prototype pod ships first, with a smaller artifact and a tighter loop.