No, AI Did Not Kill Agile

Andrea Laforgia · email · 2026-04-00 source ↗ Reader 🖥️

Agile & XP Code Was Never the Bottleneck Product Discovery & Experimentation Spec-Driven Development

AI accelerates building software but does not reduce the epistemic uncertainty about what to build, so the iterative learning loop at the core of Agile becomes more important, not less, when coding is nearly free.

practical · argumentative — The text argues that practitioners and decision-makers should continue (and intensify) iterative, learning-driven development rather than adopt spec-first AI workflows. It is practical because the ultimate claim is 'you should keep iterating' — a prescription for action.

Structure

Part	Role
Section 1 — The Argument (and Why It Feels Right)	Steel-mans the opposing position: AI has made Agile obsolete because speed renders sprint ceremonies pointless
Section 2 — The Confusion: Speed vs. Knowledge	Core reframing: distinguishes the speed problem (how fast to code) from the knowledge problem (what to build), and shows Agile was always about the latter
Section 3 — The Inversion: Faster Means More, Not Fewer	Draws the logical consequence: if building is cheap, you can iterate more, not less; cites Lean Startup and Kent Beck
Section 4 — 'But I Can Iterate on the Spec'	Engages the strongest counter-argument (rapid spec iteration with AI) and distinguishes disposable-hypothesis specs from sedimentary specification documents
Section 5 — The Real Threat	Identifies the political/organisational danger: AI gives management a fresh excuse to skip learning and reimpose top-down specification
Conclusions	Synthesises the argument into a memorable formulation: 'AI killed the excuse for not iterating'

Key terms

knowledge problem Code Was Never the Bottleneck
The irreducible uncertainty about what software to build — requirements that cannot be known in advance and must be discovered through user interaction with working software
speed problem Code Was Never the Bottleneck
The constraint of how fast code can be turned from idea into working software — the problem AI actually solves
semantic diffusion Agile & XP
Fowler's concept: how Agile's original meaning was diluted as it spread, leading to 'faux-agile' — ceremonies without the adaptive principles
sedimentary spec Spec-Driven Development
A specification document that accumulates layers of decisions over time, burying wrong assumptions under refinements so they are never re-examined
validated learning Agile & XP
Ries's concept: a rigorous method for demonstrating progress under extreme uncertainty by building, measuring, and learning from real user behavior

Propositions

explicitestablishedThe 'AI killed Agile' argument confuses two distinct problems: how fast we can build software (speed) and how we discover what to build (knowledge).conf: high
supports ←Podcast: How Will We Train Developers If AI Does the Routine Work: A Conversation with Scott Hanselman · p13 — Both conclude AI has not literally killed agile, though Hanselman frames the distortion as agile pushed to an unstable speed extreme rather than a speed/knowledge conflation.
supports ←Erik van der Pluijm's Post · p5 — Both independently separate the speed question (how fast you build) from the knowledge/empiricism question (how you learn what to build), concluding AI changes the former without eliminating the need for the latter.
explicitAgile was created to address the knowledge problem, not the speed problem.conf: high
explicitRequirements are not merely vague — they are unknown and emergent; they can only be discovered through building, delivering, and observing.conf: high
explicit⚡ disputed & corroboratedIf AI makes building cheap, the rational response is to iterate more frequently, not to stop iterating.conf: high
contradicts ←Is Agile Dead? How AI and Extreme Agile Redefine Work · p3 — The sibling piece argues the rational response to cheaper building (via AI) is to iterate MORE frequently within the same iterative-learning discipline; this article instead argues the rational response is workforce replacement and role elimination by 2030 — a different inference from a similar starting premise.
supports ←LIVE: Uncle Bob on Software Fundamentals in the Age of AI · p14 — Martin's house-building parable (cheaper change favors iteration over upfront planning) and the separately-extracted claim that the rational response to cheap building is to iterate more, not less, make the same argument from different angles.
supports ←Erik van der Pluijm's Post · p2 — Van der Pluijm's concrete 2-day cycle is a direct practical instance of the claim that the rational response to cheaper building is to iterate more frequently, not to stop iterating.
explicitestablishedSpec-driven AI development is waterfall with faster computers, unless the spec is treated as a disposable hypothesis.conf: high
supports ←TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier · p9 — Cutler's vibe-coded prototypes and vibe-written PRDs as higher-velocity premature convergence is Kerievsky's 'waterfall with faster computers' observed in practice.
supports ←LIVE: Uncle Bob on Software Fundamentals in the Age of AI · p15 — Martin's skepticism of spec-driven development as a durable-artifact practice ('my experiments did not work particularly well') matches the independent claim that spec-driven AI development is waterfall with faster computers unless the spec is treated as disposable.
explicitThe Measure and Learn phases of the Build-Measure-Learn loop remain expensive, slow, and irreducibly human even when Build is nearly free.conf: high
explicitcontestedThe real threat of the 'AI killed Agile' narrative is political: it gives management a fresh justification for top-down, spec-first control that avoids the discomfort of incremental learning.conf: high
contradicts ←Is Agile Dead? How AI and Extreme Agile Redefine Work · p3 — Sutherland frames AI + Scrum@Scale headcount reduction as Agile's successful evolution, which is close to the kind of 'AI killed Agile, so impose top-down change' narrative the sibling piece identifies as politically motivated rather than evidence-driven.
implicitMost practitioners frustrated with Agile are actually frustrated with faux-agile (ceremonies without adaptive principles), not with the iterative learning that Agile was designed to enable.conf: high
implicitThe quality of learning from working software in users' hands is categorically different from (and superior to) the quality of learning from iterating on a specification document.conf: high
explicitGood engineers already understand the need for iteration; the danger is that non-technical decision-makers will use AI as justification to skip it.conf: high

Arguments

AI does not make Agile obsolete because Agile addresses a problem (knowledge/requirements uncertainty) that AI does not solve. strength: high

Explicit premises:

The 'AI killed Agile' claim is based on AI's coding speed advantage
Agile was created to address requirements uncertainty, not coding speed
40-60% of software failures originate in requirements, not implementation speed
Only about 20% of features deliver their intended positive impact

Implicit premises:

A methodology should be judged by its relevance to the problem it was designed to solve, not by how it interacts with tools for a different problem
Requirements uncertainty is a permanent feature of software development, not a temporary limitation of current technology

Inferences:

If requirements uncertainty is permanent and irreducible, then no amount of technological acceleration will ever make iterative discovery obsolete
The proportion of failures attributable to requirements (vs. implementation) will likely increase as AI makes implementation cheaper and faster

Cheaper building should lead to more iteration, not less. strength: high

Explicit premises:

AI collapses the Build phase from weeks to hours
The Build-Measure-Learn loop is the mechanism for reducing uncertainty
Kent Beck recommends experimenting with approaches previously deemed too expensive

Implicit premises:

When a constraint is relaxed, rational actors exploit the freed capacity rather than abandoning the activity
The Build-Measure-Learn loop's value was always limited primarily by the cost of the Build phase

Inferences:

Teams that use AI to eliminate iteration rather than increase it are making a choice driven by organizational preference, not by logic

Spec-driven AI development recreates waterfall's failure mode. strength: high

Explicit premises:

Comprehensive specs accumulate assumptions that go unexamined ('sedimentary')
Winston Royce himself warned the waterfall pattern he described was 'risky and invites failure'
The FBI Virtual Case File failed due to specs that couldn't keep up with organizational learning
Healthcare.gov failed despite massive investment because of frozen requirements

Implicit premises:

The medium of the specification (natural language prompt vs. formal document) does not change the fundamental dynamic of prediction vs. discovery
Historical patterns of failure from specification-first approaches will repeat in AI-assisted contexts because the root cause (epistemic, not technological) is unchanged

Inferences:

AI-generated code from wrong specs will fail faster and more expensively because the speed of generation removes the natural brake that gave teams time to notice they were building the wrong thing

The 'AI killed Agile' narrative is politically motivated — it serves management's desire for control over an uncertain process. strength: medium

Explicit premises:

Agile became bureaucratic partly because management wanted predictability
The spec-first pitch appeals to stakeholders who want to define requirements and hand off execution
Cockburn's four imperatives (Collaborate, Deliver, Reflect, Improve) each check the tendency to plan in isolation

Implicit premises:

Organizational power structures reliably favor approaches that centralize decision-making, regardless of whether those approaches work
Technology narratives are often adopted or rejected based on political convenience rather than technical merit

Inferences:

The debate about AI and Agile may be irresolvable on technical grounds because the real disagreement is about organizational power, not methodology

Narratives

The Snowbird meeting (February 2001): seventeen practitioners from different methodologies united against heavyweight processes
→ Establishes Agile's original purpose as addressing uncertainty, not speed — grounding the author's reframing in historical fact
The FBI Virtual Case File: $170 million project killed by specifications that couldn't keep up with organizational learning
→ Demonstrates that spec-first failure is not hypothetical — it has destroyed major projects, and the root cause (specification rigidity) is exactly what AI-spec workflows would reproduce
Healthcare.gov: $2.1 billion spent, six users on launch day, months building against frozen wrong requirements
→ The most dramatic failure case — shows that even massive resources cannot compensate for refusing to learn incrementally
Winston Royce's 1970 paper: the 'inventor' of waterfall actually warned it would fail and recommended iterating at least twice
→ Rhetorical judo — uses the authority of waterfall's originator against those advocating spec-first AI development
The performative sprint planning meeting, the status-report standup, the retrospective that changed nothing
→ Concedes the legitimate frustration behind the 'AI killed Agile' argument, building credibility before dismantling the conclusion

Questions addressed

✅ Has AI made Agile obsolete?
No — AI solves the speed problem but Agile addresses the knowledge problem, which AI does not touch. Agile's iterative learning loop is more relevant, not less, when building is nearly free.
✅ Can rapid spec iteration with AI serve as a substitute for Agile iteration?
Only if the spec is treated as a disposable hypothesis. When the spec becomes a comprehensive, version-controlled artifact, it recreates waterfall's failure mode regardless of iteration speed.
✅ Why are so many people receptive to the 'AI killed Agile' narrative?
Two reasons: legitimate frustration with faux-agile (ceremonies without principles), and the political appeal of returning to top-down specification for management.
⭕ How should Agile practices change in light of AI capabilities?
The author says Agile practices 'should evolve' and quotes the Manifesto's commitment to uncovering better ways, but offers no specific prescriptions for what evolved practices look like.
⭕ What happens to the role of software engineers when building becomes nearly free?
The author implies the bottleneck shifts to Measure and Learn, but does not explore what this means for engineering roles, skills, or team structures.

Gaps

incompleteThe author argues that Measure and Learn remain expensive and irreducibly human, but does not explore whether AI might also transform these phases — e.g., AI-driven user behavior analysis, automated A/B testing at scale, or AI-assisted synthesis of qualitative feedback. The claim that learning is irreducibly human is asserted, not defended.
Read next: Literature on AI-augmented product discovery, automated experimentation platforms (e.g., Eppo, Statsig), and whether AI can reduce the cost of the Measure/Learn phases
incompleteThe article never engages with domains where requirements genuinely are well-understood upfront (e.g., regulatory compliance, protocol implementations, mathematical computations). The knowledge-problem framing may be less applicable in these contexts, where spec-first AI development might be entirely appropriate.
Read next: Cynefin framework (Dave Snowden) for distinguishing simple/complicated/complex/chaotic domains; literature on when waterfall-like approaches are actually appropriate
incompleteThe author prescribes more iteration but does not address what 'iteration' looks like when AI can generate full applications in minutes. Traditional sprint-based iteration may indeed be too slow as a container — the article dismisses the ceremony but doesn't propose what replaces it.
Read next: Kent Beck's recent work on AI-era development practices; continuous deployment and feature flagging literature; vibe coding workflows
closed byReinventing team flow within AI uncertainty — That piece dismisses sprint-based ceremony as too slow for AI-accelerated work but doesn't propose a replacement container. This piece gives a concrete answer: don't repurpose the existing ritual, deliberately reset cadence and hold a dedicated checkpoint tied to experiment outcomes and learning, separate from the standard retrospective format.
incompleteThe political analysis of Section 5 identifies management's desire for control but does not explore whether AI might enable new forms of collaboration that transcend the old management-vs-engineering power dynamic (e.g., non-technical stakeholders directly prototyping with AI, collapsing the specification-to-implementation gap).
Read next: Literature on no-code/low-code democratization; end-user development; how AI changes the relationship between domain experts and software creation
closed byLawyers are quietly becoming builders — Provides a concrete profession-level instance of exactly the collaboration mode that gap says its source left unexplored: non-technical stakeholders (lawyers) prototyping directly with AI, bypassing the 'convince IT or an engineer' gatekeeping and collapsing the idea-to-implementation gap. It illustrates the phenomenon rather than fully resolving the open question of whether this transcends the management-vs-engineering power dynamic.

No, AI Did Not Kill Agile

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents