If you spend any time reading developer social media, you have seen "spec-driven development" mentioned like everyone already knows what it means. Most people using the term are gesturing at something real, but rarely explain the actual mechanics. Here they are, in plain words.
What problem it solves
Tell an AI coding agent "add a discount system" and you will get something. It might even run. Whether it matches what you actually needed is a separate question, because "add a discount system" was never a specification, it was a wish. The agent had to guess at percentage versus fixed amount, whether discounts stack, what happens at zero, and a dozen other decisions you did not make, and it made all of them for you, silently.
Spec-driven development is a way of forcing those decisions into the open before any code gets written, so you are approving decisions instead of discovering them after the fact.
The pipeline, step by step
The name makes it sound like one step. It is actually four, with a human checking the work between each one.
- Requirements. You write down, in plain language, what you actually want and why. Not implementation detail, just the goal and the constraints that matter to you. "Customers with a loyalty code get 10% off, discounts do not stack, the code must expire" is a requirement. "Add a discount system" is not.
- Specification. The agent turns your requirements into a precise, structured spec: what inputs exist, what the exact behaviour should be for each case, including the edge cases you did not think to mention. You read this and either approve it or correct it. This is the step most people skip when working with an agent informally, and it is the one that prevents the most rework later.
- Implementation. Only once the spec is approved does the agent write the actual code against it: functions, files, tests, the whole change.
- Verification. The code gets checked against the spec through tests, and you review the result against what you actually approved two steps earlier, not against what feels right in the moment.
The point of doing it in four steps instead of one is that a wrong decision caught at the requirements stage costs you a sentence to fix. The same wrong decision caught after implementation costs a rewrite.
Why this is worth learning now, not later
Here is the part that matters if you are a student rather than someone shipping production code today: an agent can turn a rough idea into a structured spec, and it can turn an approved spec into working code, but it genuinely cannot write your requirements for you. It does not know what you actually need, what trade-offs you are willing to accept, or which edge case matters to your specific situation. That decision is yours, every time, and no amount of agent capability removes it.
Writing a requirement precisely enough that someone (or something) else can build the right thing from it is an old skill with a new name attached to it. It used to live under "requirements gathering" or "writing a good ticket", and plenty of experienced engineers never got properly good at it because the cost of a vague requirement was hidden inside a slow, human-paced development cycle. Now that an agent can act on your requirement in minutes, a vague one gets you a wrong answer in minutes too, and the gap between a precise requirement and a vague one shows up immediately instead of three weeks later. That makes it a skill worth deliberately practising, and one you can start practising before you have a job that requires it.
IBM's coding agent, IBM Bob, is one tool built around this approach, using something close to this requirements-to-spec-to-implementation-to-verification pipeline. It is one option among several agentic coding tools that support a spec-driven workflow, so the habit is worth building regardless of which one you end up using day to day. Bob offers a 30-day free trial at bob.ibm.com/trial if you want to see the pipeline in action.
Where to actually practise writing a spec
The Legacy Fix puts you through exactly this discipline on a repository that already exists, with existing behaviour you have to understand before you can specify a change to it correctly. That is closer to a real job than writing a spec for code that does not exist yet.
Next time you catch yourself about to type a one-line prompt for something that actually matters, stop and write the requirement properly first. That sentence is the part of the job an agent still cannot do for you.
