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

There’s a popular story that AI coding tools and agents are making Agile obsolete, and I think it has things backwards. AI didn’t kill agility. It moved the bottleneck. For most of the software era the hard part was building the thing, so we built a lot of machinery to ration scarce, expensive engineering: backlogs, intake queues, governance gates. Now that building is getting cheap and fast, that same machinery stops protecting anything and starts getting in the way. The question that actually limits you is no longer “can we build it?” It’s “can anyone put it to work and show it mattered?”

That flips the job of agility. It used to be about protecting a scarce engineering team from the rest of the organization. Now it’s about pushing engineering out into the organization, right up against the work people actually do. When building costs almost nothing, you can stand up three versions, drop the ones that don’t land, and keep only what people actually adopt — a tempo that used to be irresponsible, and that I’ve started calling unreasonable agility. The catch is that speed without steering just lets you go wrong faster. So the brake that scarcity used to apply from the outside now has to come from inside: goals instead of specs, real adoption instead of feature counts, and a thin shared spine so what one team figures out is reusable by the next instead of getting lost.

Whenever the bottleneck moves, the operating model has to move with it. That’s the part the “AI killed Agile” crowd misses, so their argument is worth taking seriously before taking it apart.

The argument 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, sprint commitments, architecture review boards. 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.

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 how fast the organization can actually absorb the capability. People don’t change how they work just because a better tool showed up. Workflows, incentives, and habits move far slower than the models do, so the capability piles up faster than anyone puts it to use. That lag, between how fast we can now create capability and how slowly organizations take it up, is the management problem this shift creates, and it’s exactly the gap Forward Deployed Engineering exists to close.

Forward Deployed Engineering is suddenly fashionable, presented as if someone just invented it. They didn’t. It is the newest label for a pattern as old as engineering itself: field engineering, professional services, embedded delivery teams. 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.

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.

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. That is just empiricism — inspect and adapt — applied where the uncertainty actually lives, instead of planned around from a safe distance.

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, treating the deployment itself as the product and re-tuning it against what people actually do. The moves that used to be too wasteful to consider become the default, and learning moves 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.

The cost of building was never only a tax. It was a brake. It forced you to prioritize whether you cared about prioritizing or not, and it made you think before you built, because building was the expensive part. Take the brake away and motion gets cheap, but direction doesn’t; direction was never priced by the cost of code. So you get speed without steering. AI gives you more speed; it doesn’t tell you where to point it. Aim that speed at the wrong thing and you don’t get transformation. You just build the wrong thing faster.

Unreasonable agility without a replacement brake degrades in predictable ways. The first is bespoke sprawl: every customer becomes a snowflake, nothing compounds, and you are maintaining forty one-offs by spring. Then comes activity theater, all dashboards and tokens consumed with nothing tied to an outcome anyone adopted. And underneath both is fragmented learning, where ten teams discover the same lesson ten times and none of it makes it back to the center. It all runs on heroics that don’t scale, until it 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.

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.

The internal brake isn’t one thing; it’s a handful of habits. Here’s what 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’s just the handful of things that keep all that cheap speed aimed at something real.

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.

The headline narrative has it backwards on every count. AI didn’t kill agility; it relocated where agility matters most. It didn’t make engineering discipline obsolete, but it did change discipline’s job from rationing a scarce resource to deploying an abundant one. And it didn’t remove the need for a brake. It moved the brake inside, where it now has to be made of goals, feedback, and judgment rather than gates and queues.

The organizations that win the AI era won’t be the ones with the best models. Everyone will have good models. They’ll be the ones where new capability actually changes how people work, and stays changed, faster than anyone else. That’s an agility problem, and increasingly a Forward Deployed Engineering one. Creating capability is the part that just got cheap. The scarce, valuable, unglamorous work now is helping organizations absorb it.

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

If your AI program is throwing off a lot of activity and not much adopted impact, that’s the gap I spend my time on. Get in touch or find me on LinkedIn — happy to think it through with you.