Progressive Delivery for the AI Era: Speed Without a Kill Switch Is Just Faster Chaos

Most teams think their AI problem is a model problem. It is not. The model is fine. The thing quietly buckling under the weight of all that new velocity is your release pipeline.

For two years the story has been throughput. Copilots and coding agents write more code, close more tickets, and open more pull requests than any team could manage a few years ago. Leaders watched the velocity charts climb and declared victory. Then production started getting noisier, incident channels lit up more often, and nobody could quite explain why the faster team also felt less safe. The uncomfortable truth is that AI did not just speed up how fast you write code. It sped up how fast you can break production.

The bottleneck did not disappear. It moved downstream.

Every delivery system has a constraint. When AI removed the constraint on writing code, the constraint did not vanish; it slid one step further down the line. First it landed on human review. I have argued that review capacity is the new delivery ceiling and that the merge queue has become the new critical path. Both of those are about getting change approved. This post is about the last mile: what happens when all that AI-generated change actually reaches production.

The data here is not soft. The 2025 DORA Report reoriented its entire research program around AI-assisted development, and its headline pattern was blunt: throughput without stability. AI adoption correlated with higher delivery throughput and, at the very same time, higher delivery instability. DORA described the effect as localized pockets of productivity lost to downstream chaos. The mechanism is not mysterious. AI raises the rate of change faster than your review and deployment systems can safely absorb it. Generate three times the change through a pipeline built for one third of it, and the change failure rate does not stay flat. It climbs.

This is the same reason so many pilots look great in the demo and fall apart in the quarter that follows. The fix is rarely a better model. It is a pipeline that can carry the model safely to production and pull it back just as fast.

Why AI features break the old release model

Even if your pipeline could absorb the volume, AI features carry a second problem that classic deployment practices were never designed for: they do not behave deterministically.

A conventional feature has a pass or fail line. You write tests, you go green, you ship, and the behavior in production matches the behavior in staging. An AI feature has a distribution of behavior, not a single answer. You cannot fully test it before release because the interesting failures only appear against real traffic, real prompts, and real data. You do not test an AI feature to confidence. You observe it into confidence, in production, on a controlled slice of users.

There is a third wrinkle that catches even mature teams. The thing you deploy is no longer just code. A model version bump, a prompt edit, a change to the retrieval index, or a config tweak can each swing behavior hard with no code diff attached. Your version control system sees nothing. Your test suite sees nothing. Your users see everything. That is a lot of release surface hiding outside the pull request.

Put those three facts together and one conclusion is unavoidable. A big-bang release of a non-deterministic feature is not a deployment. It is an uncontrolled experiment you are running on all of your users at once.

Progressive delivery, defined

Progressive delivery is the discipline of releasing change to a small, controlled slice of traffic, watching guardrail metrics, and expanding exposure only when the data says it is safe. It rests on a few building blocks that work together:

• Feature flags as the control surface. Deployment gets decoupled from release. Code ships dark, then you turn it on for a chosen cohort. The deploy is boring; the release is a dial you control.
• Canary and ring-based rollout. Exposure ramps in stages, from a 1 percent canary through 5, 25, and 50 percent, up to the full fleet, with a hold gate at every step.
• Blue-green environments for an instant switch back to the known-good version when you need it.
• Automated rollback driven by guardrail metrics rather than by whoever happens to be awake.

None of this is new. Martin Fowler and the release-engineering community documented feature toggles and canary releases years ago, and progressive delivery has been a mainstream practice at scale for a while. What is new is that AI has moved these techniques from good hygiene to survival gear. When your change volume triples, the only way to hold change failure rate steady is to shrink the blast radius of every individual change. Progressive delivery is precisely the machine that shrinks it.

The kill switch is a product decision, not just an engineering one

Here is where delivery leaders, not just platform engineers, need to lean in. A feature flag is not plumbing. It is a product control, and someone has to own it.

Every AI feature you ship should have a named owner who can turn it off and a written condition for when they will. That sounds obvious until an incident is unfolding at 2am and the on-call engineer does not know whether disabling the new summarizer is allowed, who to ask, or what the users will see when it goes dark. A kill switch nobody is authorized to flip is not a kill switch. It is decoration.

Owning the flag means owning the questions that surround it. Who is in the exposed cohort and why. What the fallback experience looks like when the feature is off. What healthy actually means for this specific feature, in numbers, before a single user sees it. Those are product decisions. They belong in the definition of done, next to the acceptance criteria and right beside the rollback steps on your release checklist, not bolted on after launch.

Wire rollback to your error budget

Progressive delivery only works if the question "is it safe to advance" gets answered by data instead of opinion. That is exactly what error budgets are for. I made the case that teams should prioritize error budgets over deadlines; progressive delivery is where that principle earns its keep.

Before a rollout begins, define the guardrail metrics and their thresholds. For most features that means latency and error rate. For AI features you add two more that classic pipelines ignore: a quality or eval score, and cost per request, because a model can be fast and wrong, or accurate and ruinously expensive. Set the budget. Then let the rollout run itself: it advances automatically while the metrics stay in budget, and it holds or reverts the moment they breach.

That is the whole loop. Ship the increment behind a flag, observe the guardrail metrics and evals, decide to advance, hold, or roll back, and adjust exposure accordingly. The error budget sits in the middle as the arbiter. No debate, no hero, no war room required for the routine case. The system either has budget to spend or it does not.

A 30-day plan to start

You do not need a platform team or a six-figure tooling contract to begin. You need one feature and four weeks.

• Week 1: instrument one feature. Pick a single AI feature, put it behind a flag, and define three guardrail metrics with explicit budgets. Latency, error rate, and one quality or cost metric is a fine start.
• Week 2: canary it. Release to a 1 percent cohort and watch the guardrails for a day or two. Resist the urge to ramp on excitement alone.
• Week 3: automate the rollback. Wire the flag to the metrics so a breach flips it without a human in the loop. Manual rollback is better than none, but automated rollback is the point.
• Week 4: name the owner and write the runbook. Document who can flip the switch, under what condition, and what users see when they do. Then do it again with the next feature.

Run that loop a few times and it stops feeling like ceremony and starts feeling like the floor. A flag, three metrics, and a documented rollback beat a big-bang deploy every single time.

The bottom line

The DORA data settled an argument that a lot of leaders were still having with themselves. AI makes teams faster, and unmanaged, it also makes them less stable. Those two facts are not in tension; they are the same fact seen from two ends of the pipeline. The teams that will win the AI era are not the ones generating the most code. They are the ones whose release pipeline can absorb it without setting production on fire.

Progressive delivery is how you build that pipeline. Feature flags decouple deploy from release, canary rollouts shrink the blast radius, and automated rollback wired to an error budget turns safety into a default rather than a scramble. Speed is not the achievement. Speed you can stop on a dime is. Everything else is just faster chaos.

References

• Google Cloud. Announcing the 2025 DORA Report. cloud.google.com
• DORA. Balancing AI tensions: Moving from AI adoption to effective SDLC use. dora.dev
• Martin Fowler. Feature Toggles (aka Feature Flags). martinfowler.com