Is Agile Still Relevant When AI Writes the Code?
Agile was not a fashion. It was a correct answer to a specific problem, and the honest way to ask whether it is still relevant is to ask whether the problem is still the same.
Why Agile was right
Dave Snowden’s Cynefin framework sorts problems by the kind of causality they have. In the Complicated domain, cause and effect exist but take expertise to see, so you sense, analyze, respond, and good practice is repeatable. In the Complex domain, cause and effect are clear only in hindsight, so you probe, sense, respond, and practice is emergent.
From the moment software stopped being a solo craft, it sat squarely in the Complex domain. Outcomes depended on how the work was organized and on the skill of every person in the chain, interacting in ways nobody could fully predict. Iterative, empirical, probe-sense-respond delivery is exactly the right response to that. Scrum did not win because it was fashionable; it won because it matched the domain.
Everything Agile prescribes follows from that match. Short iterations, because you cannot forecast far in a Complex domain. Estimation, because slow human coding had to be rationed. Standups, because people grinding on separate slow parts drift out of sync.
What actually changed
Not “AI types faster.” Two things changed, and only the second is structural.
The first is speed. Mid-to-senior-level code now arrives in seconds rather than days. That alone moves the bottleneck: writing code stops being the constraint, and what remains is the coordination overhead Agile itself introduced. Ceremonies built to synchronize human coders now consume the capacity AI freed.
The second is subtler and matters more. A new kind of teammate joined the team, the Silicon Software Engineer, and part of the team is now far more stable in skill than any human contributor. You can rely on it, with a known correction for hallucination, in a way you never could with a variable roster of people. That reliability pulls the work out of Complex and toward Complicated. And a shift in domain demands a shift in the management cycle: room opens for sense-analyze-respond, for analysis, planning, and repeatable practice, where before only probe-sense-respond was defensible.
So the question is not whether Agile is still good. It is whether a purely emergent process is still the only correct answer when the problem is no longer purely emergent.
What stops earning its keep
Sprint planning allocated a fixed human capacity across two weeks. When a well-specified story costs the agent minutes, the planning session spends more human hours than the work it plans.
Story points measured human coding effort. They cannot measure AI output, and the thing that actually varies now is specification quality, which points do not capture.
Velocity has the same flaw, sharper: once the agent writes the code, counting human output measures the wrong actor. Teams tracking a rollout by velocity or commits usually conclude nothing changed, because they are watching the wrong number.
The standup resynchronized people grinding on separate slow parts. With a two or three person team and specifications precise enough to execute without reinterpretation, most of what it surfaces is already visible in the work.
None of these were bad ideas. They were correct answers to a constraint that no longer dominates.
What survives
Three of Scrum’s contributions hold, and any serious successor keeps them.
Iterative delivery. Ship working software at a defined cadence, not big-bang releases. RACE Programming keeps it as the Stint: a one-week cycle by default, prototype-first.
Cross-functional teams. One team owns delivery end to end, without hand-off silos. In RACE that is the Pit Wall and Pit Crew as a single accountable unit.
Visible backlog. Work stays explicit and prioritized. RACE extends it: every item must be a fully specified Executable User Story before it reaches the Pit Crew.
Agile’s four values also hold, but they were calibrated for a constraint that no longer dominates, which is why the useful move is to rewrite them rather than defend or discard them. That rewrite is Agentic Agile: AI-fluent people over processes and tools; working product with necessary documentation over comprehensive documentation; continuous customer validation over contract negotiation; living roadmaps over fixed-iteration plans.
What replaces the machinery
If the ceremonies priced scarce human coding capacity, their replacements should price what is scarce now: specification and validation.
The specification becomes the artifact. The unit of work is an Executable User Story, precise enough that an agent can build it and a machine can check the result, with acceptance criteria written as tests. Ambiguity is resolved before implementation, not discovered during it. Anything beyond the minimum sufficient spec is waste; anything below it is ambiguity the AI will ship as a bug.
Prototypes replace debate. When a working version costs an afternoon, the way to settle a question with a stakeholder is to put two or three real versions in front of them. The client validates intent before production code exists.
The cycle compresses. A one-week Stint ending in a production deployment replaces the two-week sprint; a twice-daily Inner Cycle of spec, build, align replaces the standup.
Quality moves to gates. Agentic output needs a stricter bar, not a looser one, so a change clears four automated gates, unit coverage, integration, end-to-end, and automated acceptance against the specification, before it reaches production. A failed gate returns the work to build.
The practical test
Do not argue about Agile in the abstract. Take each ceremony you run and ask what constraint it was compensating for, and whether that constraint is still expensive. Whatever answers yes is worth keeping. Whatever answers no is overhead you pay out of habit.
Then ask the harder version about the work that is expensive now, specifying and validating, and see how much of your process is organized around it. For most teams the answer is almost none, and that gap, not the ceremony debate, is the actual problem.
Agile was right that the plan is not the point and feedback is. That does not expire. What expires is a set of rituals built for a world where the typing was the hard part, and a management cycle built for a domain the work is leaving.
Written by Pavel Khodalev, author of RACE Programming and CTO of First Line Software. Follow new essays via RSS.