Agile in the age of AI: the values hold, the rituals change

Agile has changed a lot since its initial conception. The word stuck, but the practices built around it kept shifting, and a lot of the original ceremonies no longer look the way they did when the Manifesto was written in 2001. It is tempting to read that drift as a verdict: agile got old, AI changed the work, move on. We don’t buy it. We build custom software with small teams, and the parts of agile that survive contact with AI are exactly the parts that were never about the rituals.

The frameworks aged. The values didn’t.

“Agile” as a word is probably too broad to fully go obsolete. What went stale are the recipes: the rigid frameworks, the ceremonies performed for their own sake, the daily standup that became a status reading instead of a conversation, the planning blocks that swallowed a day and produced a plan nobody trusted by Wednesday.

Strip those away and the Agile Manifesto still holds. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. None of those four lines depend on a whiteboard full of sticky notes. “Working software over comprehensive documentation” doesn’t read any differently than it did in 2001. If anything, it reads truer.

Execution got cheap, so documentation moved into the code

The single biggest shift is that execution is now cheap. You can build a working proof of concept in an afternoon, before the planning meeting instead of after it. That quietly inverts the old order of operations. For years the instinct was to document everything first: specs, diagrams, sign-offs, then build. When a POC took weeks, that caution made sense. It makes less sense now. You learn far more from a rough POC you put together in a short window than from a document trying to predict a whole system before anyone writes a line.

That is why “working software over comprehensive documentation” reads differently in 2026. The running system is the documentation. It encodes the business rules, and it is the fastest way to find out whether a solution is worth building at all. When we inherit a legacy codebase, we point AI at it to reconstruct the flows and rebuild the map. The code was always the source of truth. Now we have tools that can read it at that level, and the POC became a planning tool instead of the thing you do after the plan is signed.

Which ceremonies still earn their slot

Standups, planning marathons, retros. Plenty of teams ran them because the book said to, long after they stopped helping: attendance out of obligation, status updates nobody read. Running a ceremony to prove you’re agile is about as far from agile as you can get.

So the useful question is which ceremonies still earn their slot now that a board can stay transparent on its own, updates can go async, and a tool can generate a working slice before the planning meeting even starts. Some survive in a lighter form. Some get replaced by something a machine keeps current. Some can go. We are working through that ourselves, one project at a time, and we don’t pretend to have the final answer yet. That is the interesting part of the job right now, and none of it contradicts agile. It is agile doing what it was for: keep what delivers value, question the rest.

QA stops being a phase and becomes the safety net

Cheap execution has a cost, and the cost is volume. When a lot of code gets generated fast, the odds of subtle breakage go up and scope drifts more easily. The answer is not to slow the generation down. It is to raise the floor of quality assurance underneath it.

That means automated validation as a first-class citizen: tests that run constantly, checks that catch regressions before they land, and enough coverage that you can move fast without flying blind. In an AI workflow, QA is not the gate at the end. It is the harness that lets you go quickly and still trust the result. Senior review does not disappear either. It moves to naming the failure modes automated checks would otherwise miss. Fast generation without QA is just fast breakage.

The human job is writing the contract

If you are not typing every line, what are you doing? Writing precise requirements. Defining the context, the data schemas, and the technical contracts a tool needs to produce the right thing. Treat a user story as a strict technical contract, not a loose wish. The precision that used to be optional is now load bearing, because a tool will do exactly what the context tells it to and nothing more.

So the skill in demand is requirement engineering: defining context, constraints, data schemas, and acceptance criteria tightly enough that the work comes back right the first time. This is the same discipline we apply when we augment a client’s team. That is engineering. It is the harder, more valuable part of the work, and it is very much a human job.

AI is a tool, not a teammate

One thing we want to be clear about: AI is a tool. A good one, but a tool. It generates and transforms code. It does not own the outcome, and it does not have a stake in whether the customer succeeds. People do that.

We build custom software with small teams, and we pick the mix of people and tools that fits the problem in front of us. New patterns are forming around this, like the one some are calling “AI Scrum”: heavier automation, machine-readable state instead of manual status updates, and asynchronous execution. They are worth watching, and they are variations on the same values, tuned for tools that can now do more of the mechanical work. We wrote about what that looks like for us in practice in our post on agentic delivery.

What’s actually changing, and what isn’t

The ceremonies change. The tools change. Teams get smaller and faster because one engineer with the right tools covers ground that used to need several. But the center holds. People and interactions, working software, customer collaboration, responding to change. They still describe how good small teams ship.

What needs work is everything built on top: the cadences and habits that grew up around a slower kind of execution. We think we understand the value underneath that work, and we are spending real time figuring out how to adapt the practices around it. That part isn’t finished, and it probably won’t be for a while. The tooling underneath got faster, cheaper, and stranger. The job is keeping our way of working in step with it, without throwing away the reasons it worked in the first place. If you are trying to work this way and want a team that already does, let’s talk.