AI Didn't Kill Agile. It Moved the Bottleneck.

Why AI Doesn’t Make Agile Obsolete (And Where the Bottleneck Moved)

There is a popular narrative that AI coding tools and agents are making Agile obsolete. This gets the story exactly backwards: AI isn’t killing agility; it is moving the bottleneck. When engineering capacity goes from a scarce, expensive constraint to an abundant commodity, the machinery we built to ration it—backlogs, prioritization queues, and heavy governance gates—turns from protection into a cage. The bottleneck has shifted downstream to organizational absorption capacity: from “can we build it?” to “can anyone actually put it to work and prove its value?”

This shift inverts the job of agility. Instead of protecting engineering from the organization, our new task is to unleash engineering into the organization at the front lines, close to the actual human workflows. When the cost of building falls toward zero, we unlock “unreasonable agility”—the ability to experiment, throw away, and iterate at a tempo that used to be irresponsible. But speed without steering is just waste, accelerated. To scale this new speed without chaos, we must replace external scarcity brakes with internal ones: organizing around goals rather than specs, managing opportunity backlogs instead of feature lists, and building a thin platform spine so edge learning compounds.

Did AI make Agile obsolete?

There is a popular narrative right now that AI is making Agile obsolete. I think it gets the story exactly backwards: AI is not killing agility, it is moving the bottleneck. And whenever the bottleneck moves, the operating model has to move with it.

The argument for “AI killed Agile” usually goes like this: if AI can generate code, specs, tests, designs, and documentation—maybe whole applications—then all the process we built around software development is dead weight. Why bother with Scrum, planning, refinement, estimation, or product management when the machine just produces the thing? The mistake is to confuse a particular implementation of agility—the one built for a world where engineering was the scarce resource—with the purpose of agility. The implementation is aging out, but the purpose is about to matter more than it ever has.

For most of the software era, the bottleneck was production. Could we build the thing? Could engineering keep up with demand? Could we point scarce engineering capacity at the highest-value work instead of spraying it everywhere? That world produced Agile, Scrum, Kanban, Lean Product Development, and DevOps. Underneath every framework and ritual was one economic fact: engineering capability was scarce and expensive.

So we built machinery to ration it. Backlogs, prioritization, sprint commitments, intake processes, architecture review boards, and governance layers. Be honest about what most of that machinery was for: it existed to protect a scarce, expensive resource from waste and thrash. A lot of what we call Agile became, in practice, a system for managing constrained engineering throughput—a careful queue in front of the one team everyone wanted more of. That was the right design for that constraint, but AI changes the constraint entirely.

Where did the bottleneck move?

Code generation is getting dramatically cheaper. So is prototyping, specification, and experimentation. Small teams now produce what used to require a department, meaning the ability to create software is no longer the thing standing in the way. When production stops being the bottleneck, a different one shows up underneath it: adoption, consumption, and operationalization. The question is no longer “can we build it?” but “can anyone actually put it to work?”

This is why so many organizations are drowning in AI activity while starving for AI impact. They have copilots, agents, internal tools, LLM integrations, pilots, and a graveyard of prototypes. And yet the workflows barely change, people drift back to old habits, customers don’t adopt, and no one can connect the token bill to a business outcome. The AI “transformation” is mostly theater because the limiter isn’t technical capability anymore. It’s organizational absorption capacity. Humans, workflows, incentives, trust, governance, and habits do not evolve at the speed a model ships. That gap—between how fast we can now create capability and how slowly organizations absorb it—is the defining management problem of this decade, and it is exactly the gap Forward Deployed Engineering exists to close.

Why is Forward Deployed Engineering suddenly relevant again?

Forward Deployed Engineering is suddenly fashionable, presented as if someone just invented it. They didn’t. It is simply the newest label for a pattern as old as engineering itself: customer-facing engineering, field engineering, delivery organizations, solution engineering, professional services, and embedded consulting. I’ve spent close to two decades inside this exact tension—working with Amdocs, HP, NEC, Idemia, Aras, and others—navigating the same core questions every time. How much do you invest in a central platform, and how much do you bend it to the reality of a specific customer? How close should engineering sit to the operational mess, and how much autonomy belongs at the edge?

I’ve watched the same fight play out inside enterprise IT. On one side, a central group protecting standards, architecture, and platforms. On the other, business units routing around them because central delivery feels slow and disconnected. Neither side is wrong, but the topology is just hard. So while FDE itself is old news, what is new is the size of the gap it now has to span. AI has widened the distance between capability creation and capability adoption faster than any technology shift I’ve seen. Closing that distance is no longer a side function you bolt on after the “real” engineering. It is the work.

What are the two ways engineering moves to the front lines?

There isn’t one FDE model. There are two, and they lead to different operating models. The first is familiar: keep the product stable as a platform, and stand up downstream forward-deployed teams to get it adopted in each customer’s reality. In this model, the platform protects scale while the FDE layer absorbs context.

The second model is more interesting, and AI is what makes it possible: the product organization itself becomes forward-deployed. When a 10x increase in engineering leverage means your R&D no longer has to sit behind a wall of intake and protection, you can send it on offense—closer to customers and closer to the actual workflows—without giving up the integrity of the product. You stop running R&D as a defended fortress and start running it as a front-line force. You can see both models straining at the companies furthest ahead. OpenAI and Anthropic did the thing everyone is racing toward: they 10x’d what a product organization can create. The result is enormous capability sitting in front of a consumption-and-adoption wall. More and more SaaS companies are about to land in the same place. They’ll win the build and then discover the build was never the hard part.

How did agility’s job change when engineering stopped being scarce?

Here is the line I would defend out loud: for thirty years, agility’s practical job was to protect engineering—to ration a scarce resource, defend it from thrash, and aim it at the highest-value work. The gates, the queues, the prioritization rituals: all of it was a fence around something precious. When the precious thing stops being scarce, the fence stops being protection and becomes a cage. If engineering is no longer the bottleneck, every gate you built to ration it is now just drag. This is the real reason so many smart people feel like Agile has gone irrelevant. They’re not wrong about the cage; they are just wrong about the conclusion.

Because agility’s job doesn’t disappear when engineering becomes abundant. It inverts. The job is no longer to protect engineering from the organization. It’s to unleash engineering into the organization—push it to the front lines, point it at the highest-value adoption problems, and keep it learning fast enough to matter. It is the same purpose underneath, but with the opposite posture: from defending capacity to deploying it.

Forward Deployed Engineering is what that inversion looks like in an org chart. Done well, it’s a more honest expression of what agility was always about than most of what carries the Agile label today. FDE teams live where uncertainty is highest. They can’t lean on central planning because the learning only exists in the field. They can’t treat deployment as something that happens after delivery, because delivery isn’t done until someone adopts it. It is build, try, learn, and adapt—at the boundary between the plan and the reality. It is empirical process control with the training wheels off.

What does AI make newly possible?

When engineering was scarce, agility was reasonable. It was bounded by the cost of building. You couldn’t stand up five variants to see which one customers adopted—you’d burn the quarter. The cost of production quietly did your prioritizing for you. It forced restraint, and restraint looked like discipline. Take that cost toward zero and you unlock something I’d call unreasonable agility—adaptiveness at a tempo and scale that used to be irresponsible.

You can build three real versions for three customers instead of arguing about one roadmap. You can throw away last week’s implementation without grief because rebuilding is cheap. You can put a working thing in front of a frontline team in the morning and have a better one by the afternoon. You can treat the deployment itself as the product and re-tune it continuously against what people actually do. The moves that used to be too wasteful to consider become the default. Learning can now move almost as fast as the uncertainty it’s chasing. That’s the upside everyone is excited about. It’s real, but it has a catch almost no one is pricing in.

What happens when speed loses its brake?

The cost of building was never only a tax; it was a brake. It forced prioritization whether you valued prioritization or not. It made you think before you built, because building was the expensive part. Remove the brake and motion gets cheap, but direction doesn’t. Direction was never priced by the cost of code. So you get speed without steering—and AI does not create new value, it creates new speed. Point new speed at the wrong thing and you don’t get transformation; you get waste, accelerated.

Unreasonable agility without a replacement brake degrades in predictable ways. First, bespoke sprawl: every customer becomes a snowflake, nothing compounds, and you find yourself maintaining forty one-offs by spring. Second, activity theater: dashboards full of prototypes and tokens consumed, none of it tied to an adopted outcome. Third, fragmented learning: ten teams discover the same lesson ten times and none of it makes it back to the center. It leads to heroics that don’t scale, and then burns out the heroes.

The danger in this era is no longer moving too slowly. It is accelerating in the wrong direction with the confidence of someone who is “shipping.” And weak feedback loops, merely costly when production was slow, become genuinely dangerous when a bad signal propagates at the speed of generation. So “just remove all the process” is half right and half catastrophic. The old gates do need to go, but remove the brake and put nothing in its place, and unreasonable agility eats itself. You don’t get a forward-deployed organization; you get expensive chaos with a modern logo.

How do you scale unreasonable agility without killing it?

The whole game is replacing an external brake with an internal one. Scarcity used to do your prioritizing from the outside. Now it has to come from inside—goals, feedback, and judgment, not gates and queues. Reach for the old heavy governance and you re-cage the engineering you just freed. Reach for nothing and you drift.

A few things I’ve seen actually hold the line:

• Organize around goals, not specs. Spec-driven development made sense when implementation was the expensive part. When implementation is cheap and clarity of intent is scarce, you flip to goal-driven development. You don’t hand teams a specification to execute. You hand them a goal to seek—a customer transformation goal, an adoption goal, or an operational leverage goal—and let the implementation path stay fluid. Goals constrain exploration without scripting it. They are the steering that replaces the brake.
• Reframe the backlog around opportunity, not product. In a forward-deployed world, the unit of value isn’t a feature; it’s a realized outcome. This means maintaining an opportunity backlog instead of a product backlog, led by an opportunity owner instead of a product owner—someone accountable for an adoption or transformation outcome, not for shipping a list. The question stops being “how much did we build?” and becomes “how much real change did we enable?”
• Make the feedback loop measure value, not output. Velocity was the right metric when output was the constraint. It’s actively misleading now. Instead, measure adoption. Measure the ratio of token spend to operational value. Measure whether the workflow actually changed and stayed changed. If your dashboard can’t tell activity from impact, it will happily celebrate the wrong one.
• Keep a thin spine so the edge compounds. This is the old central-platform-versus-edge problem, and it gets sharper. Unreasonable agility at the edge only pays off if the learning and the reusable pieces flow back to a center light enough not to slow anyone down. Too much spine and you’ve rebuilt the cage; too little and every engagement starts from zero. Keep the spine thin and load-bearing at the same time.
• Empower teams to seek value, and hold them to the outcome. Empowerment without accountability is abdication, and the old accountability—“did you hit the plan?”—is the wrong question. The right one is closer to an investor’s: probability of win times impact, minus the cost of pursuit. Real autonomy over how, a hard line on what for.

None of this is a new framework to install by the book. It is a set of forces that keep unreasonable agility pointed at something.

What does the Agile industry need to admit?

Agile itself now needs Forward Deployed Engineering. The Agile industry productized the same way SaaS did. Frameworks became products, training became distribution, and certifications became recurring revenue. For a long stretch that made sense—it created real access and scale. But it landed where enterprise software is landing now: a yawning gap between the theoretical capability of the “product” and the impact it makes on the ground. Organizations don’t need another framework PDF, certification badge, or terminology debate run from an ivory tower. The capability to “do Agile” is no longer scarce; the ability to make it stick in a specific organization’s reality is.

So Agile has its own activity-to-impact bottleneck—and the same fix. What organizations need are forward-deployed agility practitioners: people who embed at the front lines, read the shifting bottleneck, adapt the practices to the actual context, and stand up operating systems that turn AI activity into outcomes. Doing the work, and helping others do it. Working, validated outcomes over comprehensive documentation. Customer collaboration over contract negotiation. I wonder where I’ve heard that before. The Manifesto was never an implementation manual; it was a set of directional principles. In the AI era they matter more, not less. We just stopped reading them as principles and started selling them as products.

Where does this leave leaders?

The headline narrative has it backwards on every count. AI didn’t kill agility; it relocated the place where agility matters most. It didn’t make engineering discipline obsolete; it inverted discipline’s job from protecting a scarce resource to unleashing an abundant one. And it didn’t remove the need for a brake; it moved the brake from the outside—the cost of building—to the inside, where it has to be made of goals, feedback, and judgment instead of gates.

The organizations that win the AI era won’t be the ones with the best models. Everyone will have good models. They will be the ones that learn, adapt, deploy, and absorb faster than everyone else—the ones that build a system for continuously integrating new capability into evolving human work. That is an agility problem. Increasingly, it is a Forward Deployed Engineering problem. Because it is no longer enough to create capability; creating it is the part that just got cheap. The work now—the scarce, valuable, unglamorous work—is helping organizations absorb it.

Agility isn’t dying. It’s finally leaving the software department.

If your AI program is generating a lot of activity and not enough adopted impact, that’s the gap I help leadership teams close. Get in touch or DM me on LinkedIn to discuss how we can align your operating system to this new speed.