Agility got many teams out of never-ending projects. Short deliveries, conversations with the business and working software before the plan goes stale. Nobody sensible wants to go back.
But in many teams something else happened along the way. "Iterating" gradually took the place of functional analysis and technical design. The work did not disappear: it moved. Less thinking before, more fixing after delivery.
The thesis of this piece: with agents that read the specification, analysis and design pay off again, and delivery can stay short. The rigour of before with the cadence of now. It is a thesis, not a measured result, and at the end we say where it can fail.
What the Manifesto says (and what it does not)
It is worth starting with the original text, from 2001. The Agile Manifesto values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.
Then comes the sentence people forget most: while there is value in the items on the right, we value the items on the left more. "More" does not mean "instead of". Documentation and plans have value; they just weigh less.
The twelve principles make it even clearer. One asks for working software to be delivered frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. Another, that business people and developers work together daily. And the ninth says that continuous attention to technical excellence and good design enhances agility.
Where the analysis got lost
That thinking ahead is not wasted has been said, from the inside, by two of the Manifesto's signatories.
Martin Fowler wrote "Is Design Dead?" for a 2000 conference and revised it in 2004. His answer was no: Extreme Programming involves a lot of design, done in a different way. He also acknowledged the risk. In its common usage, he wrote, the design that grows as the system is built is a disaster, and its detractors saw it as a return to "code and fix". And he closed with a balance: planned design does not go away completely, and there is room for designing before coding.
Dave Thomas, another of the seventeen signatories, went further in 2014 with "Agile is Dead (Long Live Agility)". For him, the word "agile" had been emptied of meaning by becoming a marketing term. He proposed keeping agility as a way of working: find out where you are, take a small step towards your goal, adjust your understanding based on what you learned, and repeat.
Neither of them asks for more documents. Both ask for thinking. The problem was not the Manifesto; it was that, day to day, thinking before building became hard to justify. With a two-week sprint ahead, three days of analysis looks like a luxury.
Why the specification pays off again
Here is the underlying change. Until now, whoever read the analysis was a person about to write code. If the analysis was weak, that person asked, assumed, or found out halfway through the work. The cost of poor analysis was spread across conversations and rework.
With an agent that builds, the specification is the input to the work. The spec-kit specification, GitHub's kit for Spec-Driven Development (SDD), building software from a written specification, puts it this way: requirements documents were the scaffolding that was built and then discarded once the "real work" of coding began. In SDD, the specification becomes the primary artifact and the code becomes its expression in a particular language and framework.
In practical terms: whatever is not written down, the agent assumes. Good functional analysis, with cases and criteria, and a technical design that says where each thing goes are no longer a luxury. They are what the builder needs. If you want the definition of SDD at a calmer pace, it is in SDD: the methodology that turns AI into controlled code.
Why it is not a return to waterfall
The objection is obvious: if we go back to writing before building, are we not going back to waterfall? The difference lies in size and rhythm.
Waterfall wrote the analysis for the whole project before building anything and delivered at the end. With SDD you specify the next piece of work, the agent builds it and delivery arrives early. The analysis comes back; the months of waiting do not.
Birgitta Böckeler, of Thoughtworks, keeps watch from the other side. After trying three SDD tools, she writes that the past has shown that the best way for us to stay in control of what we build is small, iterative steps. She doubts that a lot of up-front spec design is a good idea. And she warns that an effective SDD tool would have to cater to an iterative approach, even though small work packages almost seem counter to the idea of SDD. In some of her cases, the process felt like overkill for the size of the problem.
| Question | Waterfall | Iterating without analysis (the drift) | Specification and agent (the thesis) |
|---|---|---|---|
| When do you think about what to build? | All at the start | During and after delivery | Before each piece, sized to it |
| Who reads the analysis? | People, sometimes months later | Almost nobody: a one-line story | The agent that builds and the person who reviews it |
| How often do you deliver? | At the end | Every few weeks | Every few weeks or sooner |
| Where does disagreement with the business show up? | At the final delivery | At the sprint review, as rework | When the specification is reviewed, before the code |
| What is the main risk? | A huge document that goes stale | Delivering a lot and aligning little | A heavy specification, or one without checkable criteria |
onext's own analysis. The last column is a thesis, not a measured result.
The row that matters most is the fourth. In the drift, disagreement with the business is discovered once there is already software: you demo it, it was not that, you redo it. With the specification in front of you, the disagreement can surface while reading it, when fixing it costs a conversation. That is why it makes sense for a person to sign off the specification before the agent generates anything, as we explain in the specification is where you sign off.
What the specification needs so it is not just a long document
Going back to analysis does not mean going back to hundred-page documents. A specification the agent reads and nobody can check is just prose. What turns it into useful analysis is acceptance criteria: concrete sentences that say what must happen and that a machine can verify. How to turn a criterion into a merge gate is in your spec is already an eval, and how tests fit in, in SDD, TDD and BDD: what each one adds.
Technical design works the same way. You do not need a design of the whole system before you start. You need each piece's specification to say where it goes, what it touches and what it must not break. It is Fowler's balance applied to each task: some planned design, a lot of design that evolves.
Risk A specification without checkable criteria does not bring analysis back: it imitates it. If the specification grows and nobody can tell whether the code meets it, you are back to the document that goes stale, now with an agent that interprets it its own way.
Alignment with the business, with its limits
The underlying promise is alignment between IT and the business at a reasonable speed: the analysis of before to understand what is being asked, and the cadence of now to check it early. It is the most attractive part of the thesis and also the easiest to overstate.
DORA's 2025 report on AI-assisted software development sums it up in one sentence: AI's primary role is as an amplifier, magnifying an organisation's existing strengths and weaknesses. If the business and development do not talk, a fast agent does not fix it; it delivers faster what nobody had agreed on. We looked at this from another angle in the 70% gap: AI adoption in development is an organisational problem.
What we do not know yet
Three limits worth saying out loud.
- It is a thesis. We have no study that measures alignment with the business before and after working with specifications and agents. What there is are arguments and sources pointing in that direction.
- The balance point is not written down. How much to specify before each piece depends on the risk, the team and the change. Böckeler saw it in her trials: the same process was too much for a small problem. And Böckeler raises a deeper doubt: small work packages almost seem counter to the idea of SDD.
- Discipline does not come with the tool. Writing good criteria is a habit. If the team does not have it, the specification will be as weak as the one-line story, only longer.
And a question for your next planning session: for the last feature that had to be redone, could the disagreement have been spotted by reading a one-page specification? If the answer is yes, the analysis you are missing is not a document. It is a conversation with a date, before the code. If you are interested in the uncomfortable side of that conversation, the pressure to show something as soon as possible, we cover it in MVP versus specification.
Frequently asked questions
Is Spec-Driven Development a return to waterfall?
Not if it is done well. Waterfall wrote all the analysis and design before building and delivered at the end. With Spec-Driven Development (SDD), building software from a written specification, you write the specification for the next piece of work, the agent that builds it reads it, and delivery stays short. The risk of drifting into waterfall is real when the specification grows without limit: Birgitta Böckeler, of Thoughtworks, points out that small, iterative steps are still the best way to stay in control.
Is the Agile Manifesto against documentation and design?
No. The Manifesto says that, while there is value in the items on the right (processes, documentation, contracts and plans), it values the items on the left more. And one of its twelve principles says that continuous attention to technical excellence and good design enhances agility. What many teams lost was a practice, not a rule of the Manifesto.
Why does AI make functional analysis worth doing again?
Because the agent builds with what it reads. For years, requirements documents were, in the words of the spec-kit specification (GitHub's kit for SDD), the scaffolding that was built and then discarded once the real work began. With an agent, the specification is the input to the work: whatever is not written down, the agent assumes.
How much should you specify before the agent starts?
Just enough for the next piece of work, with criteria that can be checked. There is no universal number. Böckeler tried several SDD tools and in some cases found the process overkill for the size of the problem. A person sets the measure, piece by piece.
Does AI fix the misalignment between IT and the business?
Not on its own. DORA's 2025 report on AI-assisted software development concludes that AI acts primarily as an amplifier: it magnifies the strengths and weaknesses an organisation already has. Writing down more clearly what gets built is a condition for alignment; it is not a guarantee.
What is evolutionary design and how does it relate to SDD?
It is the idea that a system's design grows as the system is built. Martin Fowler, in "Is Design Dead?", explains that Extreme Programming (XP) involves a lot of design, done in a different way, and that planned design does not go away completely: there is room for designing before coding. SDD fits that balance: you design before each piece, not before the whole project.
Sources
- Kent Beck, Martin Fowler, Dave Thomas and others, "Manifesto for Agile Software Development", 2001, and its twelve principles (accessed on 11 October 2026).
- Martin Fowler, "Is Design Dead?", martinfowler.com, presented at XP 2000 and revised in May 2004.
- Dave Thomas, "Agile is Dead (Long Live Agility)", pragdave.me, 4 March 2014.
- Birgitta Böckeler (Thoughtworks), "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl", martinfowler.com, 15 October 2025.
- GitHub spec-kit, "Specification-Driven Development (SDD)" (no date shown; accessed on 11 October 2026).
- DORA (Google Cloud), "State of AI-assisted Software Development 2025".
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →