Change is hapening

I’ve been noticing something on my own team lately: we’re writing more up front than we used to. Not big design documents in the old Waterfall sense, but detailed, structured tickets — closer to specs than the “just enough” user stories Agile trained us all to write. And it nagged at me, because “minimum up-front design” is basically Agile 101. So I went down a rabbit hole to see whether this is just us, or whether AI is genuinely reshaping how teams plan and build software. Turns out it’s not just us — it’s one of the liveliest debates in software engineering right now.

Yes, people really are arguing about whether Agile is dead

This isn’t some fringe hot take. Back in February, a full-blown debate broke out in the Agile community over whether autonomous AI agents make the Agile Manifesto obsolete. AWS put out guidance suggesting sprint planning needs to evolve into something they’re calling “intent design.” Kent Beck — yes, that Kent Beck, one of the Manifesto’s original authors — floated the term “augmented coding.” Capgemini went further and argued the Manifesto’s whole human-centric framing doesn’t really fit agentic delivery anymore.

The “Agile is dying” camp makes a simple argument: sprints exist to manage the slowness of building software by hand. Take away the slowness, and the rationale for sprints goes with it. Scrum.org — of all places — put out a pretty blunt piece essentially saying that if your version of Agile mostly means running meetings, updating tickets, and moving cards across a board, that job is getting automated, full stop.

But plenty of equally credible voices are pushing back hard. SD Times made the point that treating Scrum’s ceremonies as pure overhead misses what they were actually for — Scrum was never about typing speed, it’s about coordination and keeping stakeholders aligned, and AI doesn’t touch either of those. One veteran practitioner (twenty years in the trenches) put it well: AI didn’t kill Agile, but it did expose how shallow a lot of “Agile” already was. His point was that “working software” can’t be the only measure of progress anymore — you’ve also got to weigh maintainability, security, and whether anyone can explain why the code does what it does.

My read after wading through all this: Agile the philosophy is fine. Scrum the ceremony set is the part actually under pressure — especially the bits that quietly assumed a human pace of work (two-week boxes, story points as a stand-in for human effort, velocity as a team metric).

The real story: “spec-driven development”

Here’s the bit that actually explains what I was noticing on my own team. There’s a name for it now: spec-driven development, or SDD. And once you understand why it’s happening, it stops feeling like a betrayal of Agile values and starts feeling like common sense.

The reason is dead simple: AI can’t read minds. If you tell a human developer “add photo sharing,” they’ll fill in a hundred unstated assumptions using judgement, a Slack thread, and general knowledge of how your app works. Ask an AI agent the same thing and it has to guess — file format, permissions, size limits, storage, compression — and it’ll guess plausibly and confidently, which is somehow worse than guessing badly. This is basically what people mean by “vibe coding” (a term Andrej Karpathy coined back in early 2025): coding by feel, throwing loose prompts at an LLM and hoping for the best.

There’s a genuinely useful cautionary tale from Pluralsight that I keep coming back to: a fintech team adopts AI coding agents, velocity triples, features that used to take a week now ship in two days. Great, right? Then the cracks show. One developer’s agent implements auth one way, another’s does it completely differently, a third ships a payments endpoint with no input validation. Everything compiles, all the tests pass — and then someone in security asks “who decided to skip validation here?” and the answer is: nobody, really. An LLM made that call in a chat window that no longer exists. That’s the whole argument for SDD in one story: without a spec, you lose auditability, reproducibility, and any real governance over what got built and why.

Worth saying though — some sharp people are pushing back on the idea that any of this is new. One practitioner is quoted calling SDD “just BDD with branding,” and honestly, fair point. Writing specs before code has been solid agile practice for decades via TDD and BDD. What’s actually changed is the tooling (specs can now be genuinely executable) and the fact that an AI is the one consuming the spec, which makes spec quality matter in a much more direct way than it used to.

And there’s a real trap here worth calling out: the danger isn’t writing specs, it’s writing specs and then letting them rot. There’s a term for this too — “spec drift” — where the agent changes the code, nobody bothers updating the spec, the tests still pass, and six months later the spec is a fossil that’s actively lying to whoever (or whatever) reads it next. One blogger even called badly-done SDD “the new Waterfall,” which is exactly the failure mode you’d expect if a spec gets treated as a frozen contract instead of a living document.

How other teams are handling it

Nobody sensible is throwing out process entirely. What most teams seem to be converging on is a layered flow: spec → design → tasks → implementation, with a human checking in at each handoff. Amazon’s Kiro bakes this in directly — you can work in a structured “spec mode” or a looser “prompt mode,” your call. GitHub’s Spec Kit is the lighter-weight, tool-agnostic version of the same idea: a version-controlled spec file plus some project-wide ground rules, working through the same rough stages, and it’ll plug into more than a dozen different coding assistants rather than locking you into one IDE.

Here’s roughly how the main tools stack up if you’re shopping around:

Tool	Good for	Watch out for
GitHub Spec Kit	Teams juggling different AI coding tools who want one portable spec format	Free and flexible, but adds paperwork for tiny changes
Amazon Kiro	AWS-heavy shops wanting spec discipline built into the IDE	Locks you into AWS’s ecosystem and pricing
OpenSpec	Existing codebases, want the lightest possible layer	You’re managing spec drift yourself, manually
BMAD-METHOD	Big, high-stakes greenfield builds wanting a full simulated “team” of AI personas (PM, architect, QA, the works) and an audit trail	Steep learning curve, chews through tokens — overkill for anything small

Honestly, this is basically validation for what a lot of us are already doing informally. Writing a properly structured ticket for an AI agent to pick up and run with — the way I write Linear stories for our coding agents — already sits in the same category as Spec Kit or Kiro, just without the branded tooling around it. The two habits worth stealing from all this SDD chatter: a quick human look-over of the spec before the agent starts, and actually going back and updating the story when the implementation reveals the spec was wrong — instead of letting it quietly go stale.

What’s actually replacing the old ceremonies

A few concrete shifts keep coming up regardless of which tool or team you look at:

Sprint planning is turning into “intent design.” Instead of scripting out every task for a fixed two-week window, the job becomes setting guardrails and fallback plans for how humans and agents work together — deciding who’s allowed to decide things, more than deciding exactly what gets built.
Story points and velocity are wobbling. Both were built on the assumption that a human is doing the work. Once an agent’s doing a meaningful chunk of implementation, neither metric means quite what it used to.
The feedback loop is shrinking from weeks to minutes, and that changes what a retrospective is even for. If you can go from idea to working prototype in minutes instead of days, the smart move is running cheap, fast experiments instead of debating hypotheticals in a meeting room — and treating your pre-implementation docs as genuinely disposable, keeping the rigour for what actually ships.

What I’m actually going to do differently

Pulling this together into something practical for a small team:

Treat the spec as a draft until the agent’s actually built against it once. After that first pass, it graduates to “source of truth” status — and both the code and future agent runs need to stay honest to it.
Write down the stuff a human would’ve quietly inferred. The fintech horror story above is the lesson: the expensive gaps weren’t in the obvious business logic, they were in the unstated defaults — auth, validation, idempotency — that a decent human dev fills in without even thinking about it.
Don’t reach for a heavyweight framework you don’t need. A full BMAD-style simulated team is overkill for most day-to-day work on a small team. A lightweight, tool-agnostic approach fits better.
Add one real gate: a quick human read of the spec before implementation starts — and make updating the spec part of “done,” not an afterthought.
Make retros about the AI workflow too, not just team dynamics — model choice, prompt quality, and context management are all fair game now.
Stop conflating “Agile” with “Scrum.” The values don’t need defending. The specific mechanics — fixed sprints, story points, some of the ceremonies — are fair game to renegotiate, and doing so isn’t the same as abandoning Agile.

Bottom line

The pull toward writing specs before code isn’t us going soft on Agile — it’s the sane response to a very specific limitation: AI can’t infer what nobody said out loud. The teams doing this well aren’t ditching Agile’s principles, they’re just being more deliberate about which parts genuinely benefit from being nailed down up front (enough spec that an agent can’t invent the wrong thing) and which parts should stay loose and iterative (the ceremonies and cadence that were really built for humans). The tooling — Spec Kit, Kiro, BMAD, OpenSpec — is genuinely useful for structuring this. But the actual discipline that matters — keeping the spec honest, and not skipping the human check-in — is on us, not the tool.

Further reading, if you want to go down the same rabbit hole I did:

Agentic AI Is Rewriting the Sprint Lifecycle — Agile Insider
The Death of the Sprint? What AI Means for Agile Planning — Medium
Agile and Scrum in 2026: Do They Still Make Sense in the AI Era? — SD Times
Agile 2026: AI Did Not Make Agile Obsolete But Here’s What Really Happened — Medium
The End of “Good Enough Agile” — Scrum.org
AI Is Rewiring Scrum Teams, But Not Scrum — Scrum.org
Spec-driven development (SDD) with AI: Making agents enterprise ready — Pluralsight
Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants — arXiv
The Spec Growth Engine (spec drift research) — arXiv
Agentic Agile-V: From Vibe Coding to Verified Engineering — arXiv
GitHub Spec Kit vs BMAD-Method: A Comprehensive Comparison — Medium
6 Best Spec-Driven Development Tools for AI Coding in 2026 — Augment Code
spec-compare: Interactive comparison of SDD tools — GitHub
Spec-Driven Development: The New Waterfall — Medium
How to Integrate AI Coding Tools in Agile (2026 Data & Tactics) — DEV Community