Why Agile Is Failing the AI Era — And What We Built Instead

Software development methodologies are built for a specific era. Waterfall made sense when requirements were stable and computers were expensive. Agile emerged when business needs shifted constantly and teams needed to respond faster. Both were genuine innovations for their time.

We are in a new era. And Agile, as widely practiced, is not the right tool for it.

I want to be careful here: I am not arguing against collaboration, communication, or iterating based on feedback. Those are timeless. What I am arguing against is the ceremony — the rituals, the artifacts, the coordination machinery — that Agile has accumulated over two decades and that now imposes serious cost on small, high-skill teams operating with AI assistance.

The Problem With Sprints

A sprint is a coordination mechanism. It answers the question: given that we have a large team with many competing priorities and uncertain estimates, how do we align on what to do next? The sprint cadence — plan, execute, review, retrospect — creates a forcing function for teams that otherwise have no natural synchronization point.

But what happens when your team is small and expert, when everyone knows the priorities, and when your estimates are increasingly irrelevant because AI assistance has compressed execution timelines dramatically? You end up spending a significant fraction of your time in planning ceremonies that exist to solve a coordination problem you do not actually have.

Our team ran two-week sprints for two years. When we finally sat down and counted the hours spent in sprint planning, backlog refinement, daily standups, sprint reviews, and retrospectives, we arrived at an uncomfortable number: roughly 15% of total working hours. That is one day per engineer per week, every week, spent not building anything.

The Accountability Problem

Agile distributes accountability in ways that sound healthy but often are not. The Product Owner owns the backlog. The Scrum Master owns the process. The team owns the sprint. In practice, this diffusion means that when something goes wrong, the responsible party is always "the system" rather than a person.

This would be acceptable if the system were actually good at producing outcomes. It often is not. It is good at producing activity — story points, velocity charts, release notes — which can be convincingly presented in a planning session even when the underlying product is stagnating.

The AI era makes this worse, not better. As AI tools allow individual engineers to move faster, the natural direction of high-performing teams is toward fewer people with clearer ownership. Agile's coordination scaffolding — built for teams of eight to twelve — starts to look absurd on a team of three.

What We Built Instead

APEX — Accountable, Precise, Expert-led, eXpedient — is our answer. It is not a rejection of Agile's values. It is an honest assessment that most Agile implementations have drifted far from those values, and that the AI era demands a reset.

The four principles are deliberately chosen:

Accountable means every piece of work has a single owner. Not a team. One person. They make the call, they carry the outcome. This is uncomfortable in cultures that prefer consensus, but it is what produces fast, clear decisions.

Precise means you understand the problem deeply before writing code. In an AI-assisted workflow, the cost of precision has collapsed — writing a thorough spec takes an hour — while the cost of imprecision has increased, because AI can confidently and rapidly build exactly the wrong thing.

Expert-led means you use AI as leverage, not as a replacement for judgment. The engineer must understand what is being built and why, must be able to evaluate the output, and must own the result regardless of how much of it was generated versus written.

eXpedient means process exists only in service of delivery. We do not hold meetings because we scheduled them. We do not fill in templates because the process requires it. Every action either serves the work or is eliminated.

This Is Not for Everyone

APEX is designed for small, expert teams — typically two to six engineers — who are building software with AI assistance and who want to operate with maximum autonomy and minimum overhead. It is explicitly not designed for large organizations that require coordination across dozens of teams. For that context, scaled Agile frameworks, for all their faults, at least solve a real problem.

If you are leading or part of a small technical team and you have the persistent sense that your process is working against you rather than for you, APEX may be worth your attention.

The full manifesto, guides, and templates are available on GitHub: github.com/evuori/apex-manifesto