Spec driven development isn’t a new paradigm - it’s waterfall, repurposed for the agentic age. The discipline that agile tried to escape is the discipline our agents now demand.
There is an interesting “new” term doing the rounds: spec driven development - a practical alternative to vibe coding. Tools that facilitate this SDD process are being talked about as the next paradigm in AI assisted engineering. The idea is straightforward enough - write a structured specification, hand it to an agent, and let the agent implement it. The framing suggests this is a novel discipline born of the agentic moment.
It seems an awful lot like the Waterfall methodology to me, something the tech industry has spent years pretending it had moved past.
How we got here
Agile won the methodology wars for good reasons. Vague specs are fast, easy to write, and easy to dive into - you can get a product moving in days instead of months. The spec evolves alongside the work, the customer learns what they actually want by seeing it on screen, and the team adjusts. For human teams with shared context and a shared client, this works exceptionally well. The gaps in the spec get filled by conversation, by the developer’s judgement, and by the lead’s instinct for what the client really meant.
Waterfall, by contrast, demanded that requirements be fully understood, documented, and measurable before a line of code was written. It was slow, it was rigid, and when the spec was wrong - which it always was, somewhere - the cost of correction was enormous.
Where strict adherence to a plan was less important than being first, agile was the antidote to this pattern, speeding up software development dramatically.
Then we started handing the work to agents, and we discovered that the antidote had a shelf life.
Why agents break agile
Take a real example from our CourierHub app - our client says: “add a second address to shipment records.” To a human developer who has worked on the system for a year, this is a five minute conversation away from a clear plan. They know the shipment table already has billing and delivery addresses. They know the UI has a single address form that gets reused. They know there is a half-finished refactor in a branch somewhere that was meant to extract addresses into their own table.
Hand that same sentence directly to an agent and you might get any one of three differing implementations; new columns bolted onto the shipments table, a new second_addresses table joined on shipment_id, or a full refactor that lifts every address into a polymorphic addresses table and migrates the existing data. Each approach is defensible, and each has different consequences for the UI, for reporting, for the API contract, for the next developer who touches the code. The agent makes the decision quickly without any external context, relying on your instructional metadata to tell it everything it needs to know.
Vibe coding often deprioritises the planning stage of the traditional product lifecycle, and this is now the failure mode that spec driven development is responding to. The fix isn’t yet another AI powered tool; it is the discipline that waterfall always demanded: agree the shape of the work before any work begins.
Brainstorming as the new requirements phase
What is genuinely new - and worth crediting - is that the agents themselves are good at helping you write the spec. At Elysium, almost every piece of substantive new work now starts with a brainstorming phase. A developer and analyst will work together with Claude or other agents to pull the requirement apart. What does “second address” mean? Is it for split shipments, returns, or compliance? Does it need to be queryable independently? What happens to historical records? The agent asks questions a junior developer might not think to ask. The developer provides technical answers, the analyst fills in the business cases.
By the time we are done, we have a specification that is detailed enough to be implemented without further interpretation. It looks remarkably like the requirements documents I used to be handed by Lloyds Register in the early 2000s. The difference is that producing it took less than an hour of collaboration rather than three weeks of meetings, and the developer who will guide the implementation already understands every decision that has been made.
This is what separates consistency from “vibes”. We are using an agile, conversational process to produce a waterfall artefact. The spec is the deliverable of phase one, the implementation is phase two, and the agent will not start phase two until phase one is signed off.
The craft that does not change
None of this is news to anyone who has spent time in bespoke software. The discipline of extracting real intent from a client - the thing they need versus the thing they asked for - has always been the senior part of the job. It is the difference between a delivery that lands and one that needs a second pass.
The tools have changed. The shape of the artefacts has changed. The discipline has not. Working out what to build, in enough detail that someone (or something) else can build it correctly the first time, is the same skill it has always been. It just has a new audience.
Watching the industry rediscover waterfall through the back door of agentic tooling is, I will admit, a little funny. But it is also a useful clarifying moment; the teams that will get the most out of agents in the next two years are not the ones with the best tooling. They are the ones who already knew how to write a specification.
Tools change. The discipline does not.
See the original post on Matt's website: tiltedsky.net(opens in new tab)