Spec-driven development needs a plan you can argue with

Spec-driven development is the real correction to vibe coding: make the spec the source of truth and let the agent derive the code from it. The category has arrived — GitHub's Spec Kit, AWS's Kiro, a DeepLearning.AI course. But most of the tooling optimizes one half of it — generating the spec — and leaves the other half thin: the part where a human and an agent actually decide what the spec should say.

What SDD gets right

The premise is correct and we're all-in on it. A spec is a durable source of truth instead of a fading chat. You review focused changes derived from an agreed spec, not thousand-line dumps after the fact. And the spec becomes the codebase's long-term memory — six months later a new developer, or a new agent, reads the same document and understands what the system is for. This is the shift that makes agents dependable.

A spec is a pile of decisions

Look under the structure — requirements, design, tasks — and a spec is really a set of decisions: which datastore, which edge cases matter, what “done” means, which of two reasonable designs is right here. Generating a spec document is the easy part now. The hard part is resolving the decisions inside it — and many of them the agent genuinely can't make alone, because they need product context, taste, or a judgment call only you have.

The missing seam: a plan you can argue with

So where do those decisions get resolved? In most SDD flows the agent generates a spec and you edit the text or re-run a command. That's a monologue. What a decision actually needs is a conversation: the agent proposes, flags what it's unsure about, and you answer — then it revises. This is the seam inplan is built for. The plan is a live document you can argue with: the agent drafts it and raises its open questions as inline comments, you resolve each one where it lives, and you review every change like a pull request. The spec stops being a generated artifact and becomes a negotiated one.

A generated spec tells the agent what you typed. A negotiated plan tells it what you decided.

Specs rot — and the fix is that maintaining one is the work

Every spec drifts. A write-once spec goes stale the moment the product moves — criteria that no longer match, decisions nobody revisited — and the agent keeps confidently building against the wrong thing. The reason plans stay alive in inplan is that updating one is the interaction: the agent surfaces the new open question, you resolve it in place, the plan moves with the product. Maintenance isn't a chore bolted onto SDD; it's the same back-and-forth that produced the spec in the first place.

Where inplan fits your SDD workflow

You don't have to choose. Draft the structure however you like — Spec Kit, Kiro, Claude Code's plan mode — then bring the plan into inplan to resolve the open decisions with the agent, and hand the resolved plan back to implement. inplan isn't another generator; it's the human⇄agent decision layer of spec-driven development — the place the generating gets its answers. (More on how it compares to planning up front and to engineering the loop.)

The real work is deciding what's in the spec

SDD's whole premise is that the spec is the real work. Agreed — which means the real work is deciding what goes in it, and that deserves better than a text box you approve. Give the spec a place to be argued out, keep it alive as the product moves, and every other part of spec-driven development — the generation, the implementation, the review — gets easier because it's finally building against decisions you actually made.