A few weeks ago, I wrote about different but same waves of transformation I have lived through. Today, I am going to extend the story with a familiar character which everyone talks about but no one likes to create and confront it, it is the elephant in the room no one wants to address.That character is the Spec.
Every wave of software engineering quietly dropped something the previous one believed in. The spec was the casualty we never quite admitted to.
In the SDLC era — waterfall, V-model, the first decade of my career — the spec was the contract and it was sacred. BRDs,FRDs and design documents that ran a hundred pages. Sign-offs and then Change requests.
The “why” lived somewhere. The “what” was decided before anyone wrote a line of code. A new engineer could read the spec and understand what the system was trying to be.
It was slow. It was rigid. It was often wrong. The market would shift while we were still arguing about page 47 of the FRD. So we did what every industry does when the old way breaks. We swung hard the other way.
Then came the Agile Era, When we threw the spec out.
Agile arrived and we celebrated. “Working software over comprehensive documentation.” That single line in the manifesto was not wrong. But it slowly became the excuse we used for the next fifteen years to write almost no documentation at all. We replaced the spec with the user story. Three sentences in a JIRA ticket. We told ourselves the standups would carry the rest. We told ourselves the code would be the documentation. We told ourselves velocity mattered more than memory.
For a while, it worked.
But something quiet was happening underneath, and I watched it happen everywhere I led teams. The “why” stopped living anywhere and new engineers inherited tribal knowledge instead of intent. Architectural decisions got buried in pull request descriptions nobody would read again except there is an incident post hot fix ! Specs did not become unnecessary, apparently just became invisible. This invisible specs are the most expensive kind, because they live only in the heads of people who eventually leave.
Now we are entering into the Skynet (Think of The Terminators) era with the agents demanded the spec back.
Like every engineer I know, I went looking for the trick, the framework, the prompt pattern, the agentic workflow that would unlock real productivity.
The answer, when it surfaced, was almost insulting.
Specs !
As if SDLC had not spent two decades on specs ?? As if Agile had not spent fifteen years repackaging them as user stories and acceptance criteria… As if every engineer I had ever managed had not heard the word a thousand times. So how was this supposed to be different now?
Two reasons. And they both took time to land.
The first reason is brutal and economic. You are burning expensive tokens with max effort behind every agent run. Bad specs no longer just slow a team down. They burn money in real time. A vague prompt does not just cost you the next sprint. It costs you the next API bill. The discipline that was always virtuous is now also literal currency.
The second reason is deeper, and it is the one I find most interesting.
Specs in the SDLC era were always half-burnt. The human imagination cannot fully render a future it has not yet built. We wrote what we could see. The other half ?? The edge cases, the NFRs, the integrations we did not anticipate, the user behaviour we could not predict — only revealed itself once the system existed.
That gap, between what we could imagine and what we needed to build, is what killed waterfall. It is what Agile was created to absorb.
But here is what changes now. AI lets you write faster and fail faster than was ever possible before. You write a spec for the part of the future you can imagine. The agent builds it in hours, not months. You see what you missed. You see the half you could not imagine until something concrete was in front of you. You revise the spec. You run again. When you hear the big companies are creating leaderboards for token burners, this is exactly they are trying to achieve.
The spec is no longer a document you finalize before you start. It is a living artifact you converge on, as quickly and cheaply as the agents will let you. The first version is always wrong. That is the point. You find out it is wrong on Tuesday afternoon, not in production six months later.
I felt this in my own hands when I sat down with agentic tools to imagine my own workflows. I started by asking the agent to “build a screener” — the way I might brief a senior engineer who had been on my team for three years and could read between every line.
The agent could not read between the lines. It could only read the lines.
So I rewrote and I forced myself to spell out what the workflow does, what rules it must respect, what edge cases must be handled, what done means. The agent produced something useful — and I immediately saw three things I had not specified at all. I revised and I ran again. Three iterations later, I had a working artifact and a spec sharper than anything I could have written upfront. Now, I could finally afford to be wrong fast, and learn faster.
The spec became the source code.
The code became the output.
The discovery became the iteration.
A word on vibe coding.
Somewhere along the way, the opposite of spec-driven development quietly emerged. People call it vibe coding. You sit down with an agent, describe what you want in casual prose, accept what it produces, ask for a tweak, accept again, and three hours later you have something that runs.
It does feel productive and feels modern, satisfy your FOMO ! It is mostly dopamine.
Vibe coding is to engineering what scrolling reels is to learning. You finish the session feeling like you absorbed a lot. You did not. You consumed motion. The feeling of progress is real. The progress is not. I have done it and every engineer I know has done it. You build a thing, it runs, you feel clever and then you try to extend it three weeks later and discover that nothing inside it was decided. It was just generated with no intent. No constraint. No definition of done. Only momentum, and a vague hope that the agent would carry the weight of the decisions you never made.
Spec-driven coding is the opposite of that. It is slower in the first hour you need to read and understand a lot and dramatically faster in the next month. You write down what you want before you ask for it. You make the agent serve a decision instead of invent one. You can come back six months later, read the spec, and know what the system was trying to be — exactly the thing we lost in the Agile Era.
Vibe coding builds demos that feel like products. Spec-driven coding builds products that survive production.
The dopamine is in the first.The leverage is in the second.
The first principles that survive every wave.
If I had to compress what I have learned across the eras and four waves into a few first principles, it would be these.
1) The “why” must live somewhere durable. If it does not live in a versioned artifact, it does not live at all.
2) Specs should be precise, not exhaustive. The SDLC era confused length with rigor. They are not the same thing.
3) Specs should be executable, not aspirational. If a human or an agent cannot use the spec to make a decision, the spec is decoration.
Specs should be alive, not frozen. Write the part you can imagine. Let the agent show you the part you could not. Revise and Run again. And the team that writes specs well will out-ship the team that writes code well. That sentence would have been heresy in 2015. In 2026, it is becoming obvious.
AI assisted coding is the wave that quietly reverses the small thing we got wrong in the waves before.
We told ourselves Agile killed specs because specs were slow. Specs were never the problem. Bad specs were. Long specs were. Frozen specs were. Specs we tried to finalize before we could imagine the future.
Now the work returns. Write the spec > Make it precise > Make it executable ! Let the agent build, fail, and show you the half you missed. Then write again.
So next time when your team comes to you with a sprint demo, then ask where is the Spec ?
> pip install ankurverma 