OpenSpec put the term “spec-driven development” back in front of me this week, and it’s worth explaining properly instead of treating it as just that one tool’s tagline.
Spec-driven development, plainly, means writing down what you’re building and agreeing on it before any code gets written — not a formal, multi-week requirements document, just a short, concrete description of the change: what’s being added, what the actual requirements are, what counts as done. The code comes after, built against that agreement rather than against whatever picture formed in someone’s head from a conversation.
This isn’t a new idea — it’s closer to a return. Formal spec-first processes were common in traditional software engineering for decades, then fell out of favor for a lot of ordinary product work because writing a full spec for every small change was genuinely more overhead than it was worth. A quick chat with a teammate, a rough ticket description, a few lines in Slack — those covered the gap well enough when the person actually building the thing could ask a clarifying question mid-task if something was ambiguous.
Coding agents reopened the gap that made specs worth the overhead again, for a specific reason: an agent doesn’t ask a clarifying question the way a person does. Left with an ambiguous instruction, it picks an interpretation and runs with it, confidently, all the way to a finished diff — the exact failure mode I described in the OpenSpec post. A human collaborator with the same ambiguous brief usually pauses and asks. An agent’s default is to proceed, which means the cost of an unclear brief moved from “a quick question mid-task” to “read the whole diff afterward to find out it built the wrong thing.”
What makes today’s version of this lightweight enough to actually stick, where older formal processes weren’t: the spec is short — a paragraph or two plus a task list, not a requirements document — and it’s reviewed at exactly the point where catching a mistake is cheap: before code exists, not after. OpenSpec’s delta-spec approach pushes this further by only describing what’s changing in a given update rather than restating an entire feature every time, which is what keeps the overhead from creeping back up as a codebase and its spec history both grow.
The honest caveat: writing even a short spec is still more upfront effort than typing a one-line prompt and hoping for the best, and for a genuinely trivial change, that overhead can legitimately not be worth paying. The trade being made is a small, consistent cost on every change against an occasional, much larger one when an agent builds confidently in the wrong direction — which is a bet that gets better the more autonomous and further-reaching your agent’s actual work gets.
