The software development lifecycle is a cost model wearing a process costume. Every phase in it exists because one specific thing was expensive: turning a decision into working code. Estimation exists because implementation took long enough to need forecasting. Sprints exist because implementation took long enough that you wanted feedback before finishing. Code review exists because implementation was slow enough that a second pair of eyes was cheap by comparison. Remove that cost and none of those practices are wrong exactly — they are simply solving a problem that has moved.
This essay is the wide view. I have written about the gate at the end, about the craft of a single engineer's day, and about the machinery underneath; this is the argument those sit inside, which is that the shape of a project has changed and most of our process still assumes the old shape.
The bet Agile made, and why it is being reconsidered
Start with what the last twenty years were actually arguing about, because it is easy to misremember it as a temperamental dispute between planners and hackers. It was not. It was a claim about relative cost.
The waterfall model assumed you could specify a system accurately in advance, and that doing so was worth it because implementation was so expensive that discovering a mistake late was catastrophic. Agile made the opposite bet: specification is unreliable — people do not know what they want until they see it — and detailed upfront specification is therefore mostly waste. Better to build a small real thing, show it to someone, and let reality correct you. Working software over comprehensive documentation.
That bet was correct, and it was correct because implementation was expensive. When building takes six weeks, being wrong about the specification is survivable, because the six weeks of building double as six weeks of learning. The cost of a bad spec is amortised across the effort of implementing it. You discover the flaw in week two, while your hands are in the machine.
Now compress implementation toward nothing. The amortisation disappears. You do not discover the flaw in week two, because there is no week two — you discover it when a complete, coherent, well-structured implementation of the wrong thing is sitting in front of you, having been produced faithfully and fast. The feedback loop that Agile relied on to correct specification error was made of implementation time, and implementation time is what got removed.
So the calculus inverts. Not back to waterfall — nobody is proposing a signed-off requirements document and a nine-month gap — but toward specification mattering more than it has since the argument was settled.
The evidence that this is happening
You can watch this play out in the tooling, and more tellingly, in who is doing the writing.
Spec-driven development is the name that stuck: workflows where a structured, versioned specification is the primary artefact, broken down through defined steps into solutions and tasks, with code generated against it. Every significant coding tool now ships a version — GitHub's Spec Kit, Amazon's Kiro, Tessl and others.1 The interesting part is not the tooling. It is that Thoughtworks, a consultancy whose people helped write the Agile Manifesto, now tracks specification-first workflows as a technique worth assessing on its Technology Radar. The organisation that spent two decades arguing you should write less specification is now cataloguing how to write more of it.
I want to be careful here, because that is a satisfying observation and satisfying observations are the ones that make you sloppy. Thoughtworks places spec-driven development in Assess — its "worth looking at," not its "do this" — and its criticisms are pointed. The workflows are elaborate and opinionated. Tools behave inconsistently depending on the size and type of the task. Some generate spec files so long that reviewing them is its own problem, with no clear sense of who the intended reader is. And the deepest objection: handcrafting detailed rules for AI may simply not scale, in the way that hand-engineered approaches have repeatedly lost to more general ones.1
That last caution is the honest counterweight to this whole essay, and I hold it seriously. The direction — specification carries more weight than it did — looks solid to me. The current generation of specification tooling may well turn out to be a transitional artefact that we look back on the way we look back on UML diagrams.
What inflates, what collapses
If you accept the direction, the phase-by-phase consequences are fairly mechanical.
Implementation collapses — not to zero, but to the point where it stops being what a project is made of. This is the change everybody has noticed and it is the least interesting one, because it is the input rather than the consequence.
Specification inflates, and changes character. The valuable artefact is no longer a document describing intent for humans to interpret charitably; it is a precise statement of intent that something will execute against literally. Ambiguity used to be absorbed by an engineer who knew the domain and quietly made a sensible call. That absorption layer is thinner now. What you failed to say gets decided by something with no stake in the outcome and no ability to find you and ask.
Verification inflates, and this is where the cost actually lands. I have written at length about the review end of it — reviewers approving more and inspecting less as volume grows — and the same pressure applies to testing, evaluation and everything else that answers "is this right." When you can generate ten plausible implementations, the constraint is no longer producing one. It is establishing which of them is correct, and that is verification work.
Integration does not move much, which is worth saying because it is the phase everyone forgets. Getting a working thing into a real environment, with real data, real permissions and real people, was never bottlenecked on typing speed. It is bottlenecked on the messiness of institutions, and agents have not made institutions less messy.
Put together, you get an hourglass. Wide at specification, narrow in the middle, wide again at verification. Almost every process artefact we have — the sprint, the estimate, the story point, the standup — was designed for a barrel.
[ OPTIONAL PLACEHOLDER: one Gigabit project where you watched the shape change — the build that took an afternoon and then three weeks of establishing it was right, or the spec argument that turned out to be the whole engagement. Not required, since this is a Lens and the argument stands without it, but a single concrete case is what would make a prospective client recognise their own situation in it. ]
Estimation is the clearest casualty
Take story points, which are a proxy for implementation effort dressed up as a proxy for complexity. If implementation is a tenth of the cost of a piece of work, then estimating it carefully is precision applied to the wrong term. A team can get faster at the estimated part and slower overall, and the board will look excellent throughout.
This is also why I distrust most reported productivity gains from AI-assisted development, including favourable ones. If your measurement instrument was built to track the phase that collapsed, it will report an enormous improvement no matter what happens to the phases that grew. The number is not lying. It is answering a question that stopped being the important one.
The new debt
Every lifecycle produces its own characteristic debt, and this one has a new kind.
Thoughtworks calls it cognitive debt: the accumulation that occurs as AI generates ever larger amounts of code and, in doing so, opens a widening gap between the humans and the systems they are nominally responsible for.2 I think the naming is right and the distinction from technical debt matters.
Technical debt lives in the artefact. It is visible, it is greppable, someone can point at it, and you can in principle refactor your way out of it. Cognitive debt lives in the space between the artefact and the people accountable for it. It does not show up in any scan, it produces no warning, and it is not fixable by changing the code — the code may be excellent. It surfaces exactly once, at the worst possible time, when something breaks and the honest answer to "why does it do that" is that nobody currently employed here knows.
What makes it structurally nastier than technical debt is that the thing which would pay it down — a person sitting with the system until they understand it — is precisely the activity the new lifecycle is optimised to skip.
What it means if you are buying this work
One practical translation, because I think this is where the shift becomes commercially concrete.
If you are commissioning software, you are no longer principally buying implementation capacity. Implementation is the part that got cheap, and any supplier who is still pricing and pitching on it is selling you the wrong thing confidently. What remains scarce, and what you are actually buying, is the ability to specify precisely enough that a fast generator produces the right system, and the ability to verify rigorously enough that you find out before your customers do.
Which suggests different questions to ask a supplier. Not how fast they ship, or what their velocity looks like, or how much of their code is AI-generated. Instead: how do you establish what is correct before you build it, how do you verify it afterwards, and who on your side will still understand this system in a year. The last one is the cognitive-debt question, and in my experience almost nobody asks it.
Rachel Laycock, Thoughtworks' CTO, framed the broader point in a way I keep returning to: rather than displacing humans, the recent evidence shows a significant need for humans to proactively put appropriate practices and technical harnesses in place so these capabilities are used effectively and securely.2 I would only add that this is the paradox worth sitting with. The easier creation becomes, the more the unglamorous disciplines around it decide the outcome.
The honest caveat: this is a Lens piece — a reading of where things are going, argued from public evidence and my own experience of running projects, not a claim backed by a study I can point at. The strongest counter-argument is the one Thoughtworks itself raises, and I have put it in the body rather than the footnotes: the specification-heavy workflows now being built may not survive contact with more capable general models, in which case the shape I have drawn is a snapshot of an awkward middle period rather than a destination. My confidence is highest on the diagnosis — implementation stopped being the expensive step, and our process has not caught up — and lowest on the specifics of what replaces it. I will revisit this here as the answer firms up, including if it firms up against me.