Contents
For several months now, a recurring theme has been cropping up more and more often in discussions about software development: Agile is dead. As is often the case in our industry, the statement is deliberately provocative. It works well in a headline, sparks debates, and above all, highlights a real discomfort. Because while Agile may not be dead, part of how we organize software development—something we’ve been practicing for twenty years—is starting to show its limits in the face of AI agents.
The issue doesn’t necessarily lie with Agile principles themselves. Rather, it stems from the fact that we’ve built methods, ceremonies, and habits around a very specific constraint: the human capacity to produce software. A team has a limited number of developers, each developer has limited time, and so we must organize this scarce capacity. We break down work, estimate, prioritize, plan, and try to measure what the team can handle in a given period.
For a long time, this logic made sense. But in 2026, a new variable is profoundly changing the equation: development agents.
The Bottleneck Is Shifting
We’re no longer just talking about autocompletion or an assistant capable of generating a PHP function from a comment. Today’s tools are starting to explore entire codebases, analyze architecture, modify multiple files, write tests, fix errors, and execute relatively long tasks with increasing autonomy.
GitHub now publicly uses the term "Agent-Driven Development" to describe some of these new practices. OpenAI is pushing multi-agent workflows around Codex, while Anthropic is already studying how developers use Claude Code in real-world situations. We’re still far from a fully stabilized model, but the direction is clear: the developer is no longer systematically the sole execution unit in the software production process.
For a long time, code was one of the main bottlenecks. A feature could be perfectly defined, validated, and prioritized, but it still had to wait for a developer to have the time to implement it. With agents, this constraint is gradually shifting.
The problem is no longer "Who will write the code?" but rather "Have we properly defined what needs to be built, with what constraints, and how will we validate the result?"
This nuance is important because it directly changes how we should think about organizing work.
Yes, a Certain Form of Agile Is Probably Dying
Let’s take the most radical thesis. A feature is identified on Monday. It needs to be described in a ticket, go through refinement, be estimated, prioritized, and then integrated into a sprint based on the team’s available capacity. In some organizations, several days—or even weeks—can pass before work even begins.
Meanwhile, a properly equipped developer can now ask an agent to explore the project, identify the relevant components, propose several implementation strategies, and prepare a first version of the change. Depending on the complexity, all of this can sometimes happen before the next refinement meeting.
It would obviously be dishonest to claim that all features can now be developed in a few minutes. That’s not the case, and agents still face many limitations. But the gap between the potential speed of execution and the speed of some organizational processes is becoming hard to ignore.
We’ve gradually built significant bureaucracy around software production. This bureaucracy was often justified by the need to protect limited development capacity. When a resource is scarce, it makes sense to try to optimize it as much as possible.
But what happens when this execution capacity becomes partially elastic?
In this context, a two-week sprint can sometimes become less of an acceleration tool and more of a simple queue. The process then starts moving slower than the tools it’s supposed to organize.
No, Agile Is Probably Not Dead
Now, let’s do the exact opposite exercise and return to principles rather than implementations.
Delivering working software quickly, collaborating with users, reducing feedback loops, and embracing change are ideas that remain extremely relevant. One could even argue that AI agents make some Agile principles even more compelling.
If the cost of a change decreases, it becomes possible to test a hypothesis faster, get feedback, correct, and repeat. The loop between building, feedback, and adaptation can become much shorter. On this point, agents are not in opposition to Agile. They can, in fact, reinforce its original philosophy.
The problem may lie elsewhere. Over the years, we’ve sometimes confused Agile with the set of ceremonies and management mechanisms that have built up around it. Meetings have become automatic, story points have sometimes been turned into productivity metrics, and some tickets are now so detailed that they almost tell the developer which line of code to modify.
So Agile may not be dead. However, the bureaucracy built around Agile could soon face a much less comfortable reality.
Our tools are changing faster than our work methods.
From Tickets to Intent
One of the evolutions that interests me most is the level of abstraction at which we define work.
In a traditional workflow, we tend to break down features into extremely precise tasks: Add a CSV export button. Create an API route. Add a column to a table. Modify a page’s display.
This approach still responds to a human constraint. A person must pick up the task, understand what’s expected, and then execute it. The more precise the task, the more we reduce the risk of misinterpretation.
With agentic systems, we could gradually move up a level and define the intent rather than the task itself.
Instead of simply asking to add a CSV export button, we could explain that the goal is to allow a merchant to use their order data outside the software. We would then specify the constraints: respect the existing architecture, avoid exposing sensitive data, support large volumes, and prevent adding external dependencies.
Finally, we would define success conditions: the export must be usable, performance validated, tests present, and security checked.
The difference may seem subtle, but it’s fundamental. In the first case, we describe a task to execute. In the second, we define a decision space in which a system can explore multiple solutions.
This model doesn’t eliminate the developer. It even increases their level of responsibility, because someone must properly define the boundaries of this decision space.
The Real Problem Will Be Validation
This is usually where I start to be wary of overly enthusiastic discourse about AI agents.
Producing more code isn’t necessarily good news. DORA’s work describes AI as an amplifier. It can enhance an organization’s strengths but also accelerate its dysfunctions.
A bad architecture doesn’t become better just because an agent can produce code faster. Insufficient test coverage becomes even more worrying when the volume of changes increases. And a fragile deployment process won’t be fixed by adding five agents capable of generating pull requests in parallel.
We could very quickly discover that code production was only part of the problem.
The new bottleneck may shift toward decision-making, context understanding, security, review, and especially validation. The more execution capacity increases, the more critical our ability to control that execution becomes.
In a world where a developer produces ten changes per week, an imperfect review already represents a risk. In a world where multiple agents can produce dozens of changes in parallel, validation becomes a central discipline.
This is probably where agentic development will truly become an engineering topic rather than just an impressive demo feature.
The Developer Won’t Become a "Prompt Engineer"
I’ve never really believed the idea that developers would become prompt engineers, spending their days searching for the magic formulation to get good code.
The profession is probably moving up a level of abstraction.
An experienced developer will still need to understand architecture, identify dependencies, anticipate side effects, and evaluate the quality of a solution. However, they will also need to learn how to properly define intent, provide usable context, set clear constraints, and determine the acceptable level of autonomy for an agent.
They will also need to know how to organize multiple execution capacities and, above all, retain the ability to look at a technically functional result and say no.
The developer of tomorrow may no longer be the one who writes the most code. They could become the one who knows how to properly govern a massive capacity to produce it.
This skill is very different from simply mastering a language or framework. It requires a broader system vision, the ability to reason about constraints, and a much finer understanding of risk.
Welcome to the Era of Agent-Driven Development
I don’t think Agile will disappear overnight in 2026. However, I do believe our work methods will need to catch up with our tools much faster than expected.
Agents are starting to explore, code, test, and work in parallel. Meanwhile, many organizations continue to measure their development capacity using models built at a time when code production depended almost exclusively on the number of hours available in a human team.
This gap will become increasingly visible.
Perhaps tomorrow we’ll talk less about sprint capacity and more about validation capacity. Maybe concepts like agentic budget, autonomy level, context quality, or governance will become as important as velocity has been over the past twenty years.
I’m still very wary of those who claim to have already invented the universal method for agentic development. We’re at the beginning of this transformation, and it would probably be dangerous to replace Agile bureaucracy with a new AI bureaucracy before even understanding what really works.
But after fifteen years in software development, I’ve rarely seen our execution capacity evolve so quickly.
So no, Agile is probably not dead.
Software development has simply changed engines. And continuing to drive exactly the same way might be our biggest mistake.
