Kai Stalmann · February 2026
This is the first in a two-part series. This article examines why agile's assumptions break down in AI-driven development. The follow-up will present a concrete methodology — built around goals, decisions, and sessions — along with tooling that puts it into practice.
Software development is undergoing a fundamental change. AI coding assistants can implement features, write tests, refactor code, and generate documentation — not as a future promise, but today. This changes who does what, how fast things move, and what actually matters for project success.
Agile was designed for a world where humans write all the code. That world is shifting. The practices that made agile revolutionary in 2001 now create friction in a workflow where AI handles much of the implementation and humans handle direction and review.
This isn't about agile being wrong. It's about the assumptions underneath it no longer holding.
Agile's measurement system — story points, velocity, burndown charts — exists because implementation is slow and unpredictable. A developer might estimate a feature at 5 points, take 3 days, hit an unexpected issue, and need 5 days. Sprint planning exists to manage this uncertainty.
When AI implements a feature in minutes, these measurements lose their meaning. The estimation game collapses because the thing being estimated — human coding time — is no longer the dominant constraint. If you want to measure progress, measure decisions made and goals completed. Those are the outputs that actually advance a project.
Example: A team estimates a REST API endpoint at 3 story points, roughly a day's work. With AI, the implementation takes one prompt. The actual time is spent deciding the API contract, authentication scheme, and error handling strategy. The decisions took two hours. The coding took two minutes. Story points measured the wrong thing.
The NoEstimates movement has made a similar observation — that story points and velocity often create overhead without improving predictability. AI-driven development makes this critique unavoidable: when implementation cost approaches zero, estimating it is pure waste.
Standups, sprint planning, and retrospectives exist because multiple humans need to stay aligned while building different parts of a system. "I'm working on the payment module, so don't touch the order service until I'm done" — this coordination prevents conflicts and ensures coherent architecture.
In AI-driven development, the implementer is increasingly the AI itself. The humans aren't coordinating implementation; they're coordinating decisions. "We need to decide on the payment provider before either of us can define the integration interface" is a fundamentally different coordination problem than "don't edit the same files I'm editing."
Daily standups asking "what did you code yesterday?" lose their purpose when the answer is always "I told the AI what to build." The useful question becomes "what decisions did you make yesterday, and what decisions are blocking you?"
Agile's iterative approach — build a little, show it, get feedback, adjust — assumes that building is the expensive part and that seeing working software reveals hidden requirements. Sprint demos exist because stakeholders need to see the software to react to it.