Is Agile Dead? What AI Actually Changes About How Teams Build

The Agile Manifesto turned 25 in 2026, and people are using the anniversary to declare it finished.

SD Times ran “Is Agile Dead in the Age of AI.” InfoQ published “Does AI Make the Agile Manifesto Obsolete.” Jeff Gothelf wrote about Agile in the AI era. The question is everywhere right now, and for once it is not a bad one. A lot of what looks like an agile problem is really a definition problem, which is why redefining done around outcomes matters more than the ceremony you pick. If you want the benefits angle, I broke down which agile development methodology benefits survive the AI era in a separate piece.

My answer: Agile is not dead. But the people asking the question are onto something real.

I am Matt Watson, CEO of Full Scale and a 4x tech founder. I co-founded VinSolutions and sold it for $147 million. I built Stackify. I have run engineering teams for more than 20 years, and I have watched Agile get practiced well and practiced badly across a long enough timeline to have an opinion worth sharing. Read Product Driven if you want the longer version. I run the company now, and here is the leadership change at Full Scale that put me in the chair.

Here is the short version: the ceremony matters less as AI takes over the mechanical parts of the job. The mindset matters more, because context is now the bottleneck.

Quick Answer: Agile is not dead. The bureaucratic version, stacked roles, ceremonies nobody remembers the purpose of, deserves to die, and AI is what's exposing that. But Agile as a mindset (talk to customers, ship in small increments, adjust based on what you learn) matters more now, not less, because AI made writing code cheap and made context the scarce resource. A team that runs good Agile gets better with AI. A team that was cargo-culting the ceremonies without product thinking just ships the wrong thing faster. Full Scale builds engineering teams around that mindset, not the ceremony.

Why people are declaring Agile dead (steelmanning it)

People declare Agile dead for two reasons: it turned into bureaucracy, and AI removes the bottleneck it was built to solve. Both complaints deserve a fair hearing.

The first complaint is that Agile in practice became a bureaucracy. We ended up with Scrum Masters, product owners, product managers, QA gates, and layers of ceremony that did not make the software better. They made the org chart look cleaner. Along the way, developers got stripped down to engineers who execute tickets at their assigned station on the assembly line, rather than people who own the full problem from user to production. What matters more than the ceremonies is how you run the software development life cycle underneath them.

The second complaint is that AI is removing the bottleneck Agile was designed to solve. The original case for Agile was that requirements change, so you should work in short cycles rather than plan everything up front. But if AI can generate a working prototype in an afternoon, the planning-versus-iteration tradeoff looks different. Why spend two weeks planning when you can build and test in hours?

The Agile-as-assembly-line problem is genuine. And yes, AI does change the iteration calculus.

What the “Agile is dead” camp gets wrong is assuming the problem was Agile, not the way organizations used it.

What AI actually changed

AI moved the constraint from writing code to context. In April 2026, Google CEO Sundar Pichai said 75% of Google’s new code is AI-generated, with every line still reviewed and approved by a human engineer. When three quarters of the code at one of the world’s best-run engineering organizations comes from a model, the mechanical work of writing code is clearly no longer the constraint.

The bottleneck is now context: understanding what the customer actually needs, judging whether the AI’s output solves it, and deciding what to build next. That bottleneck is exactly what Agile was designed to attack.

The 2025 DORA report found that AI amplifies whatever is already there. Strong teams get faster and better with AI. Weak teams just ship their problems quicker. A team that runs good Agile, staying close to customers and adjusting fast, gets better with AI. A team that was cargo-culting Agile ceremonies without product thinking gets worse, because they now produce the wrong thing faster.

AI did not kill the case for Agile. AI made the case for Agile stronger by making speed cheap and context expensive.

If you can build in hours what used to take weeks, the value of talking to your customer before you build has never been higher. One conversation that redirects your effort costs almost nothing. One sprint of building in the wrong direction now costs more than ever, because you could have built the right thing in the time you wasted.

Why the Agile mindset matters more with AI

The mindset matters more than the ceremonies. Sprint planning meetings, story points, and velocity charts are the assembly-line version of Agile, and I do not miss them. What matters is the part the Manifesto was about: talk to customers, deliver value fast, and adjust based on what you learn.

That loop is the engine for acquiring context at AI speed. The more context you have about what the customer needs and why, the better you can prompt AI, the better you can evaluate its output, and the faster you can decide what to build next. The teams winning right now are the ones where engineers understand the customer well enough to judge whether the AI-generated code actually solves the problem. Sophisticated AI tooling is not what separates them.

At VinSolutions in the early days, I could talk to a dealer in the morning and ship a solution by that afternoon. No tickets, no approvals, no handoffs. That was extreme Agile in the literal sense: zero lag between customer feedback and product response. That does not scale as a company grows. But the spirit of it, the insistence on staying close to the problem and acting fast on what you learn, is exactly the right model for an AI-assisted team.

The part that was never Agile’s job

Agile covers how you build, and the “Agile is dead” arguments blame it for the other job, deciding what to build. For the deciding part, a scoring tool like RICE prioritization at least forces the team to compare value against effort out loud. If your team does not understand the customer, does not have a clear vision, and does not know how to say no to bad ideas, Agile will not fix that. Neither will SAFe, OKRs, or any other framework. As I wrote in Product Driven, the problem in most engineering organizations is the product thinking, not the process. Teams do not know what to build or why it matters.

I tell the engineers at Full Scale that three things will determine their success in an AI-augmented world: communication, curiosity, and courage. Communication, because the bottleneck has moved to understanding the problem, not writing the code. Curiosity, because the tools change every few months and the engineers who stay curious are the ones who keep up. Courage, because someone has to be willing to say the thing on the board is wrong before the team builds it. None of that lives in a methodology.

The people loudest about Agile being dead are usually the ones who only ever ran cargo-cult Agile. You cannot kill something you never really did.

What this means for how you run your team Monday morning

If you lead an engineering team, keep the sprint cadence, get closer to your customers, and cut any ceremony that produces no insight.

Practice	Verdict	Why
Sprint cadence	Keep, and shorten if needed	A regular delivery heartbeat is worth more when you can ship faster
Customer feedback loop	Tighten	AI makes building fast, but it does not tell you what to build
Standups that are status updates	Cut or refocus on blockers	Status belongs in a tool, and the meeting should surface what is stuck
Sprint reviews with no customers in the room	Fix first	Without customers there is no feedback to review

Do not abandon your sprint cadence. The regular delivery heartbeat is more valuable now that you can ship faster, not less. Shortening the cycle is reasonable. Eliminating the feedback loop is not.

Get closer to your customers, not further. AI makes building fast. It does not tell you what to build. The teams that will win are the ones where the customer feedback loop is tightest. Every shortcut on that loop will show up in your product.

Drop the ceremony that does not produce insight. If your standups are status updates rather than blockers, cut them. If your sprint reviews have no customers in the room, fix that before you fix anything else. Keep the practices that connect the team to the problem. Eliminate the ones that do not.

Look at how the modern software development process is changing more broadly, including how Agile offshore development is adapting to the same shift across distributed teams, and how AI is shifting what the job actually is. The methodology discussion is one layer of it.

The broader software development methodologies question, covering Agile, Waterfall, Scrum, and Kanban, is worth getting right, but it is secondary to the product thinking underneath it. If you are still figuring out the Agile vs process trade-offs, start with Agile vs Waterfall and then the more tactical Scrum vs Kanban question.

Agile is not the problem

The Agile Manifesto was right. Talk to the customer. Ship something real. Adjust based on what you learn. Keep doing that, faster than before, using every tool available.

Whether Agile is dead matters less than whether your team is doing what Agile was always pointing at: staying connected to the customer and building accordingly. If it is not, building a team that does is worth the conversation. Full Scale builds offshore teams that run that way, and our post on software engineering principles covers what that looks like once AI is writing the code.