AI Didn't Kill Agile. It Exposed Orgs That Were Faking It.

The build phase was hiding a lot of bad decisions. AI just turned the lights on.

There's a take making the rounds right now that goes something like this: AI can generate working code in minutes, so the entire scaffolding of agile — sprints, iterations, retrospectives, the whole feedback-loop apparatus — is overhead from a slower era. Why iterate when you can just prompt? Why estimate when generation is free? Why have a backlog when you can describe what you want and have it built before lunch?

The take is wrong, but it's wrong in an interesting way. It correctly identifies that something fundamental has shifted in how software gets built. It draws exactly the wrong conclusion from that shift. And the conclusion it draws happens to be very convenient for organizations that never figured out how to do agility in the first place — which is most of them, as we've been arguing in this series.

Here's the actual situation. AI hasn't killed agility. It has compressed the part of the work that was hiding everything else. The teams that built real feedback loops are about to look very good. The teams that adopted ceremonies and called it transformation are about to look very bad, very fast, in public, with receipts.

What the build phase was hiding

For most of the history of commercial software, the act of writing code was expensive enough — in time, in salary, in coordination — that it dominated the cost structure of building products. A feature that took six weeks to implement got six weeks of insulation between the moment someone decided to build it and the moment anyone could tell whether it worked. Six weeks is a long time. A lot of bad decisions can hide inside six weeks.

Hiding inside the build phase: the half-formed PRD that nobody pushed back on because pushing back would have delayed the engineering kickoff. The strategic ambiguity at the top of the roadmap that got translated into specific features by middle managers who were guessing. The customer assumption that nobody had actually verified with a customer. The architectural decision that didn't make sense but got grandfathered because revisiting it would have cost a sprint. The metric that wasn't actually measuring what leadership thought it measured. The integration that everyone knew was fragile but nobody had time to fix.

Long build cycles absorbed all of this. By the time the feature shipped, the original decision was distant enough that nobody felt accountable for it specifically — it had become "what we're doing now," part of the inertia of the roadmap. The lag between deciding and seeing made it possible to never quite connect the two.

This is the environment in which fake agile thrived. When the build phase takes weeks, you can run terrible standups, hold pointless retrospectives, ignore your customers, and ship the wrong thing — and still appear, from a distance, to be functioning. The slowness of the work is generous to the badness of the process. You get many chances to course-correct before anyone notices the original course was wrong, and most of the corrections happen invisibly inside the build, attributed to "engineering complexity" rather than to bad upstream decisions.

AI changes this. Not by making engineering trivial — that framing is wrong and the engineers reading this know it — but by changing the ratio of build time to decide-and-validate time for a growing class of work. Where the build used to be 80% of the cycle and the deciding-and-validating was 20%, the ratio is inverting. And the parts of the work that are now most of the cycle are exactly the parts that fake agile rollouts skipped.

Where the bottleneck moved

Software delivery has always been three phases: deciding what to build, building it, and validating that it works. The phases overlap and iterate, but they're separable enough to talk about.

The deciding phase is where you figure out what problem you're actually trying to solve, who you're solving it for, what evidence you have that the solution will work, what tradeoffs you're making, and what success would look like. In healthy organizations this involves direct customer contact, real product authority, willingness to say no, and the ability to change direction based on what you learn.

The building phase is where you turn that decision into working software. Code, tests, deployment, integration, the rest.

The validating phase is where you find out whether the thing you built actually solved the problem. This requires getting it in front of users, measuring the right things, interpreting the results honestly, and being willing to undo or rework the parts that didn't land.

In the pre-AI world, the building phase was the long pole. So organizations optimized hard for it — story points, velocity, sprint commitments, engineering productivity metrics, the whole apparatus. The phases on either side got starved. Deciding got delegated to whoever was loudest in the room. Validating got cut for time, or replaced with output metrics ("we shipped 47 features this quarter") that didn't measure outcomes at all.

When the build phase compresses, the math changes. If generation is fast and you skipped the deciding phase, you now ship the wrong thing in three days instead of three months. If validation never happened in the first place, you have no way to tell that you shipped the wrong thing — you just ship more of it, faster, with growing confidence based on output metrics that were never measuring the right thing. The compression doesn't fix the upstream problems. It amplifies them.

This is why AI is a stress test for fake agile. The build phase was load-bearing for the disguise. With it removed, what's left is the deciding and validating, which is where real agility was always supposed to live and where fake agile rollouts had nothing.

The four ways teams are about to fail faster

In conversations with engineering leaders over the past year, I keep seeing the same four failure patterns. They're not new failures — they're old failures that AI has made impossible to hide.

Failure 1: Faster generation of unvalidated requirements. Product managers were already shipping PRDs that contained hidden assumptions about users, problems, and value. Engineers used to push back on these implicitly — by asking clarifying questions during refinement, by raising concerns during implementation, by uncovering edge cases that revealed fuzzy thinking. The slowness of building was a forcing function for clarity. Now the AI just builds it. The fuzzy thinking ships. The hidden assumptions become product decisions. And nobody catches it because the friction that used to surface the problems has been engineered out of the workflow.

Failure 2: Velocity theater on stilts. Output metrics like "tickets closed" or "features shipped" were always bad proxies for value, but they got worse slowly. AI makes them get worse fast. A team using these metrics to demonstrate "productivity" can now ship a staggering volume of low-value or actively-harmful work, and the metrics will look better than ever. By the time outcome data catches up — usually quarters later, sometimes never — the damage is significant and diffuse enough to be hard to attribute. The dashboard says you've never been more productive.

Failure 3: Defect bow-waves in the validation phase. Teams that didn't have real validation loops compensated, historically, by catching issues during the long build phase. Engineers reviewing code would notice things. QA cycles would surface bugs. Integration testing would reveal architectural mismatches. With generation faster and the build phase shorter, more issues now arrive at the validation phase, and the validation phase — which most organizations have starved for years — can't handle the load. The pile of "we'll deal with that later" grows much faster than the team's ability to actually deal with it.

Failure 4: Decision drift without accountability. When code was expensive, the decision to build something was implicitly weighty — somebody's salary was being committed to the work. When generation is cheap, the implicit weight evaporates. Decisions get made faster, by more people, with less scrutiny. Without a real product function to push back, the result is a thousand small decisions per quarter, none of them strategically coordinated, none of them validated against user outcomes, all of them shipped. The product becomes a collection of features that solved problems somebody once thought were important.

Each of these failures was already happening at fake-agile organizations. AI just removes the buffer that was hiding them. The teams running real feedback loops — short cycles between decision and evidence, real product authority, real customer contact, real willingness to undo work that didn't land — handle the compression fine. The teams that adopted ceremonies and called it transformation are about to discover what those ceremonies were supposed to be wrapping.

What real agility actually looks like in this environment

Here's the part that's harder to swallow if you've spent a decade rolling out frameworks: most of what makes a team effective in the AI era is the same thing that made teams effective in 2001 when the Manifesto was written. The principles haven't changed. What's changed is that you can no longer fake them.

A team that builds the right thing in this environment has a few characteristics. They have direct, frequent contact with the people who will use what they're building. Not personas, not market research artifacts, not what the sales team reports — actual users, often. They have product leadership that is willing to say no, that holds a clear point of view about what the product should and shouldn't be, and that has the authority to act on that view without going up three layers of approval. They have engineers who are participants in the decision, not order-takers — engineers who can say "this idea is bad and here's why" and have that opinion treated as input, not insubordination. They have feedback loops that are measured in days, not quarters — meaning the time between deciding to try something and seeing real evidence of whether it worked is short enough that the original decision is still fresh in everyone's mind when the evidence arrives. They have the cultural permission to undo work, kill features, and admit that something didn't land — without it being a career-affecting event.

None of this is new. All of it was in the original manifesto, in the early XP literature, in the original Lean Startup arguments. What's new is the cost of not having it. In 2015, a team without these properties shipped slowly but mostly fine. In 2026, a team without these properties ships fast and badly, in a way that's increasingly visible to leadership, customers, and competitors.

This is the actual argument. AI doesn't make agility obsolete. AI raises the price of faking it. The teams that built real feedback loops have a moat. The teams that adopted theater have a problem.

What this means for engineering leaders

If you're running an engineering organization right now, the temptation is to focus on the build side of the equation — adopt AI tooling, accelerate code generation, ship faster. That work is real and worth doing. But it's not where the leverage is. The leverage is on the two phases that AI just made dominant: deciding and validating.

Three questions are worth sitting with. First: when your teams ship a feature, how long does it take before you have real evidence about whether it solved the problem it was supposed to solve? If the answer is "we usually don't know" or "next planning cycle," your validation loop is broken, and AI will compound the cost of that brokenness every quarter. Second: who has the authority to kill a feature mid-stream when evidence suggests it's the wrong direction? If the answer involves more than two people or requires escalation, your decision loop is broken, and AI will multiply the volume of wrong-direction features faster than your escalation paths can review them. Third: when was the last time someone on an engineering team said "I think this idea is wrong" and had it taken seriously by the people whose idea it was? If the answer is "rarely" or "never," your team is shipping someone's unexamined assumptions, and AI is about to ship a lot more of them.

These questions don't have framework answers. There's no certification that fixes them. They're about how your organization actually works — who has authority, who talks to whom, what gets measured, what gets celebrated, what gets punished. The same conditions we keep returning to in this series. The same conditions that fake agile rollouts couldn't change because changing them would have threatened the existing power structure.

The reframe

The "AI killed agile" take is appealing because it lets organizations skip the hard work of actually building feedback loops. If agile is dead, then the failure of your agile rollout wasn't your fault — the methodology was just outdated, and now we move on to the next thing. The frame absolves everyone. It also guarantees that the next thing, whatever it's called, will fail in exactly the same way and for exactly the same reasons.

The truer take is harder. Agile didn't fail you, and AI didn't kill it. The thing called "agile" at your organization was never agile, and the thing AI is exposing was the disguise. The work in front of engineering leaders right now isn't picking the next methodology. It's looking at the conditions under which their teams operate and asking, honestly, whether those conditions allow real feedback loops to function — and if not, why not, and what would have to change.

That's a harder conversation than "agile is dead, what's next." It's also the only conversation that actually leads anywhere. The teams that have it will be fine. The teams that don't will keep shipping the wrong thing faster, with increasingly impressive metrics, until something downstream — revenue, retention, headcount — makes the question impossible to avoid.

AI didn't kill agile. It just removed the cover that was hiding which teams were doing it and which teams were performing it. That's not a death. That's a reckoning.

Next in the series: velocity is not a productivity metric and never was.