There. I said it, as someone building a literal software planning tool.
Tools that turn a beautifully written spec into working code, teams reorganizing their whole workflow around requirements documents, the promise that if you just describe the product well enough, delivery takes care of itself. It's all built on the same mistake. And the mistake is hiding in plain sight.
A spec describes the product. Then it stops.
Open any spec your team has written this year. You'll find the feature described in loving detail: the behaviors, the edge cases, the acceptance criteria, the invariants. What you won't find is a single word about how that feature actually lands in front of a customer.
How does it get tested against real traffic? How do you backfill the data it depends on? How do you dial it up from 1% to 10% to 50% without betting the whole user base on day one? How do you break the work down so four engineers can build it in parallel instead of one engineer building it in sequence?
The spec is silent on all of it. Because the spec was never about delivery. It was about definition. And definition is maybe 30% of the job.
The spec ends where the risk begins.
Nothing has ever failed in a document. Features fail in production: during the migration nobody scoped, the rollout nobody staged, the integration nobody tested until the week before launch. Spec-driven development pours all of its rigor into the part of the project that was never going to hurt you, and leaves the dangerous part to improvisation.
There's a second problem, and it's fatal on its own: a spec assumes you won't learn anything. Kent Beck made this point about the current wave of spec-driven tooling. Writing the whole spec up front encodes the assumption that implementation will teach you nothing that changes the spec. Every engineer knows that's false. It's waterfall with better tooling.
And when reality does change, the spec doesn't. Keeping a written artifact in sync with a living system is invisible work that humans reliably skip. So the spec drifts, and a stale spec is worse than no spec. It's misinformation with an approval stamp.
Replans are built in, because real software is dynamic.
Here's the part spec-driven development gets exactly backwards: a good plan is supposed to change.
A new feature request lands mid-build. An assumption turns out to be wrong. A dependency slips. None of that should blow up your whole plan. It should update it. A real plan has replanning natively built in: it absorbs the change, reshuffles the steps, and keeps moving from current reality. Nobody puts "we don't know this yet" in a spec, because it reads as incompleteness. In a plan, it's just a step: resolve X before starting Y.
If a single wrong assumption sends your team back to rewrite the document and re-litigate the project, you never had a plan. You had a spec with a schedule stapled to it.
Plans even die gracefully. Once a step is executed, it's done, and the next plan starts from current reality. Specs rot. Plans expire. One of those failure modes is survivable.
The alternative isn't "no rigor." It's rigor pointed at the right thing.
Here's the distinction that matters: a spec is a destination. A plan is a route.
A spec answers "what does done look like?" A plan answers "what do we do Monday?"
A real plan is delivery-driven end to end. It defines the product, yes, and then it keeps going. It says how you'll test it, and against what. It sequences the backfill before the feature that reads from it. It stages the dial-up and names the metric that decides whether you turn it further or turn it back. It breaks the work into tasks shaped for parallelism, so your team's throughput isn't capped by one critical path nobody noticed until the standup where everything is blocked.
The tell
If you want a simple test for whether an artifact is a spec or a plan, ask one question: does this get me all the way to prod without issues?
Read your spec and try to answer it. Where's the testing story? The backfill? The dial-up? The order of operations that keeps four engineers unblocked instead of queued behind one critical path? If the artifact can't answer, it's a spec: a detailed description of a destination with no route to get there. If it can, you're holding a plan, whatever your tooling calls it.
Spec-driven development optimizes the artifact nobody executes. Delivery-driven development optimizes the one everybody does.
So write down what you're building, briefly. Then spend your real effort on the route: the tests, the backfills, the dial-ups, the task breakdown that lets your team move in parallel instead of single file. The teams that ship aren't the ones with the best-specified products. They're the ones with the best-planned deliveries.
We don't do specs. We do plans.