AI coding tools are changing how software teams work — and not always in the ways you’d expect. Instead of speeding up ad-hoc development, they’re pushing teams toward more structured, upfront planning. In this blog, Madalin Stefirca explains why this shift doesn’t signal a return to Waterfall, but rather marks the emergence of a genuinely new approach to software delivery. For tech decision-makers, understanding this distinction matters: the teams that adapt fastest won’t be the ones who resist the change, but the ones who learn to write exactly the right specs, at exactly the right level of detail, at exactly the right point in the sprint.
Something interesting is happening in engineering teams right now. Teams using AI are writing significantly more detailed design docs and specs than before, in some cases spending three times longer on upfront design. Product requirement documents are starting to read like legal contracts. Architecture decisions are being locked down before a single line of code is written.
Tools like GitHub’s SpecKit, Amazon’s Kiro, and Tessl explicitly promote a requirements → design → tasks pipeline, which generates multi-file Markdown specs to drive code generation. Sounds familiar? It should. It echoes the Waterfall model, repackaged with a modern coat of paint. Some are even calling it “Agile planning, Waterfall execution”.
I agree that the observation — that AI is driving teams toward heavier upfront planning — is legitimate. But the conclusion? That’s where I’d push back.
The core flaw in the argument
Waterfall’s failure wasn’t upfront thinking, it was upfront commitment. You wrote a spec, then waited months or years to find out if it was right. By the time you got feedback, the cost of change was catastrophic.
With AI agents, that dynamic inverts completely. You write a detailed spec, the agent builds it in 20 minutes, you discover what the spec missed, update it, and the agent rebuilds – in another 20 minutes. The iteration that used to take six months now takes an afternoon. In specification-driven development, the specification itself is what’s being iterated on.
The cycle is the same. The speed is not. That’s not Waterfall. That’s Agile with a faster executor.
The risks worth taking seriously
That said, I’m keen to take a critical view of what AI-driven specification workflows actually mean in practice. As a mindful practitioner, I think the real risks of using AI agents to generate code deserve honest attention:
⚠ Spec rot: Agents don’t always follow specs. Specs go stale. Maintaining parity between spec and code recreates exactly the kind of role gatekeeping teams hoped to leave behind.
⚠ Brownfield failure: Current spec-driven toolchains are largely unusable in brownfield codebases, which is where most real-world teams actually live. Adoption is slow and the maintenance questions are serious.
⚠ False confidence: Agents have been documented marking “verify implementation” as done without writing a single unit test. A confident output is not the same as a correct one.
⚠ Double review cost: Technical specs require review before running. Then the implementation requires review again when bugs surface. So the review time effectively doubles—a hidden cost few teams have budgeted for.
The emerging hybrid
The engineering community is converging on a third position – neither pure Waterfall nor pure Agile, but something genuinely new. And this is the one that makes sense to me as someone who cares deeply about both craft and collaboration.
Influential software architect and author Martin Fowler’s team has identified three emerging patterns that capture where teams are landing:
Spec-first: The spec guides AI, but code remains the primary artifact. Lightweight, pragmatic.
Spec-anchored: The spec persists as a governing contract throughout the project lifecycle.
Spec-as-source: The spec is the source of truth. Code becomes a disposable, regenerable byproduct.
These three patterns together define the emerging hybrid: a spectrum of how tightly the spec is coupled to the code. Teams choose their position on that spectrum based on codebase maturity, team size, and risk tolerance — but all three represent a deliberate break from both pure Waterfall and pure Agile.
What changes inside the sprint
From actually working this spec-first way (and not just reading about it), I can say that the sprint doesn’t change: one or two weeks, a defined scope, a shippable increment at the end – none of that moves. What does change is what happens in the hours before a developer opens their IDE (Integrated Development Environment — the coding tool developers use to write and run code).
In classical Agile, the unit of work is a user story: lightweight by design, just enough to start a conversation. That worked when a human was doing the implementing. A human can hold ambiguity in their head, make judgment calls mid-build, and course-correct naturally. The cost of under-specification was absorbed by developer cognition.
AI agents cannot do that. They are extraordinarily capable executors, but extraordinarily poor ambiguity resolvers. Hand an agent a classical Agile user story and you will get code that is technically plausible yet frequently wrong, despite being confidently delivered. The agent will fill every gap in your spec with an assumption – without telling you.
The right moment for this upfront specification thinking is not refinement; that’s too early. It’s not planning either; that’s too high-level. The right moment is the thin slice of time between planning and execution.
This specification step currently has no name in most Agile frameworks, because it was never needed before. Some teams are calling it the ‘spec handoff’. Others are folding it into the definition of ‘ready’: a story isn’t ready to pick up unless its AI-execution spec is written and reviewed. That’s a pragmatic anchor; it integrates it into the existing workflow without inventing new ceremony.
What this hybrid model means for senior engineers
The role implications are significant, yet underappreciated. This hybrid model shifts what senior engineers actually do: less time writing boilerplate implementation, more time writing the specifications that constrain what the agent builds.
Cognitive work moves upstream – from execution to design, from coding to thinking. That’s not a loss. It’s a recovery of what senior engineering talent should have been doing all along, rather than being pulled into implementation because the team needed the extra hands.
AI is not pushing us back to Waterfall. It’s exposing that Agile’s allergy to documentation was not a principle but a pragmatic compromise – and that compromise is now worth revisiting at the feature and sprint levels.
The teams that adapt to this new spec-driven, AI-assisted way of working fastest won’t be the ones who write the most documentation. They’ll be the ones who learn to write exactly the right documentation, at exactly the right level of detail, at exactly the right point in the sprint.
Want to talk about this?
At Maxcode, we’re actively navigating the AI evolution – as engineers, not just as observers. If you’re thinking about how to integrate AI tooling into your development workflow without losing the agility that makes your team effective, we’re here to talk.
