More Code, Fewer Deployments: Why Progressive Delivery Is the Missing Half of Your AI Coding Strategy
AI coding agents have multiplied the code teams merge, but deployments per week are falling and incidents per change are climbing. The fix is not more line-by-line review. It is a release system that limits how much damage any single change can do: feature flags, canaries, automated rollback and a risk-tiered release policy.
Why Are Teams Shipping Less Often When AI Writes More Code?
In October, a discussion of an Ars Technica piece titled "AI coding agents generate more code, but not more software" climbed to the top of Hacker News with more than 300 comments. The thread kept returning to one complaint: code volume has gone up, but the amount of working, released software has not kept pace. Engineers described review queues they cannot clear, AI-written tests that assert the wrong behaviour, and releases that feel riskier than they did two years ago.
The telemetry backs the mood. Faros AI's Acceleration Whiplash report, built on engineering telemetry rather than survey answers, compares teams with high and low AI adoption. High-adoption teams complete 33.7% more tasks and 66.2% more epics per developer. Yet deployments per week are down 11.7%. Pull requests are 51% larger, median review time is five times longer, and incidents per pull request are up 242.7%. More code is entering the pipeline. Less of it is leaving, and what does leave breaks more often.
Harness found the same pattern from a different angle. In its 2026 State of DevOps Modernization research, which surveyed 700 engineering teams, 35% of the most active AI coding users already release daily or more. Those same teams have the highest rate of deployments needing remediation, at 22%, and the longest time to recovery, at 7.6 hours. Harness sells release tooling, so read its conclusions with that in mind, but the numbers line up with Faros and with what most delivery leads see on their own dashboards.
The common reading of this data is that AI-generated code is simply worse. Sometimes it is. The more useful reading is structural: the release system most teams run was designed for a world where writing code was the expensive step and every change could be read carefully by a colleague. That world ended about eighteen months ago. The code side of the pipeline was upgraded. The release side was not.
Key Takeaways
- High-AI-adoption teams complete more work but deploy 11.7% less often
- Incidents per pull request rose 242.7% and review time grew roughly fivefold
- Harness found 22% of deployments from the heaviest AI users need remediation, with 7.6-hour recovery
- The bottleneck has moved from writing code to releasing it safely
Why Can't Code Review Carry the Load on Its Own?
The instinctive response to rising incident rates is to tighten review: more approvers, stricter checklists, a rule that every AI-generated line must be read by a human. Many organisations have already done this. A LeadDev and Harness survey on AI-driven software releases found that 57% of organisations require manual human review of every line of AI-generated code, regardless of risk. Of those, 38% now spend more time on code review than before they adopted AI tools. Meanwhile 32% saw release sizes grow, and only 49% have guardrails specific to AI-generated code.
That is a policy that treats a copy change and a payment-routing change identically, and then asks the same scarce senior engineers to read both. It produces exactly the Faros curve: review time balloons, pull requests batch up, releases get larger and less frequent, and each release carries more unreviewed risk because nobody can hold a 2,000-line diff in their head. Larger, rarer releases are the classic recipe for worse incidents, which is the opposite of what the stricter review policy was meant to achieve.
Google's DORA programme warned about this before most agent tooling shipped. Its 2025 report, summarised by InfoQ, surveyed nearly 5,000 technology professionals and found that nearly 90% use AI at work. AI adoption was now associated with higher delivery throughput, a reversal from the previous year, but software delivery instability continued to rise. The report's central framing was that AI acts as an amplifier: it magnifies the strengths of organisations with good engineering foundations and the weaknesses of those without them. RedMonk's analysis of the report drew the same conclusion about instability.
Review still matters. We have argued elsewhere that it carries accountability no model can, in our piece on Copilot pull request approvals. But review is a pre-production filter, and every filter leaks. The question is not whether defects will reach production. At current code volumes they will. The question is how many users they reach and for how long. That is a release engineering problem, and it is cheaper to solve than a reviewing problem.
What Does Progressive Delivery Actually Change?
Progressive delivery is an umbrella term for a few old ideas used together. The core one is separating deployment from release. Deploying means putting new code on production servers. Releasing means letting users hit it. When those are the same event, every merge is a bet placed with your entire user base. When they are separate, new code can sit dark in production, be switched on for internal staff, then 1% of traffic, then 10%, and be switched off in seconds if a metric moves the wrong way.
Four mechanisms do most of the work. Feature flags wrap new behaviour in a runtime switch, so release becomes a configuration change rather than a deployment. Canary releases send a small slice of traffic to the new version and compare its error rates and latency against the old one. Ring or cell-based rollouts expand a change through progressively larger groups of users, regions or tenants. Automated rollback reverses a release without waiting for a human to notice the dashboard. None of these prevents a bad change from being written. All of them limit how much harm it can do once it ships.
The arithmetic is what makes this attractive in the AI era. If agents double the number of changes you ship and your change failure rate stays flat, you have twice as many failures. You cannot review your way back to the old absolute number without giving up the throughput you bought. You can, however, shrink the blast radius of each failure. A defect that reaches 1% of traffic for four minutes before an automated gate reverts it is a line in a log. The same defect at 100% for 7.6 hours is an incident review, a customer credit and possibly a regulatory report.
This also changes what you ask of review. When a change ships dark behind a flag and must survive a canary before it reaches customers, reviewers can concentrate on design, security and the handful of paths where no runtime check will save you, rather than trying to be a human test suite for every diff. That is a far better use of the senior engineers who are, in most organisations, the actual constraint.
Key Takeaways
- Separate deployment (code on servers) from release (users exposed to it)
- Feature flags, canaries, ring rollouts and automated rollback each limit blast radius
- With more changes, the lever that scales is smaller impact per failure, not fewer failures
- Review shifts to design, security and the paths no runtime check can protect
What Did the Biggest Outages of the Last Two Years Teach?
The case for progressive delivery is not theoretical. The most widely felt outages of 2024 and 2025 all came down to a change reaching everything at once, and each provider's remediation list reads like a progressive delivery checklist. None involved AI-generated code. They are relevant because they show what happens at any company when change velocity outruns release controls.
Google Cloud's June 2025 outage is the cleanest example. According to Google's own incident report, a new quota-checking feature was added to Service Control on 29 May and went through the usual region-by-region rollout. The faulty code path never ran during that rollout because it needed a specific policy change to trigger it. On 12 June that policy change, containing blank fields, was replicated globally and crashed Service Control in every region. Google wrote that the change "did not have appropriate error handling nor was it feature flag protected," and that "if this had been flag protected, the issue would have been caught in staging." Its first remediation commitment was to "enforce all changes to critical binaries to be feature flag protected and disabled by default."
Cloudflare's 18 November 2025 outage followed a similar shape. Its postmortem explains that a database permissions change made a query return duplicate rows, roughly doubling the size of a Bot Management feature file that was regenerated every five minutes and pushed across the network. The file exceeded a hard limit of 200 features, the proxy panicked, and failures began at 11:20 UTC; all systems did not return to normal until 17:06 UTC. Cloudflare's commitments included "hardening ingestion of Cloudflare-generated configuration files in the same way we would for user-generated input" and "enabling more global kill switches for features."
CrowdStrike's July 2024 incident is the extreme case. As TechTarget reported from the company's root cause analysis, a content update with a mismatch between 21 defined input fields and 20 supplied values evaded multiple layers of validation and sent more than 8 million Windows systems into reboot loops. The mitigations included staged deployment of that content type and giving customers control over when updates land. The lesson every one of these companies wrote down was the same: tests and reviews will miss things, so the rollout itself has to be a safety system.
Key Takeaways
- Google Cloud committed to putting every change to critical binaries behind a flag, disabled by default
- Cloudflare committed to more global kill switches and to validating internal config like user input
- CrowdStrike added staged deployment for the content type that caused its outage
- The shared lesson: validation misses things, so the rollout must limit the damage
Are Feature Flags a Risk of Their Own?
Yes, and any team adopting them at AI-era volumes should take that seriously. A flag is a branch in production code that is controlled outside the normal deployment process. Left unmanaged, flags accumulate into a combinatorial mess nobody can reason about, and stale flags become dormant code paths waiting to be switched on by accident.
The canonical warning is Knight Capital. The SEC's 2013 order describes how, on 1 August 2012, Knight deployed new trading code but missed one of eight servers, which still carried an obsolete function called Power Peg. The new code reused the flag that had once activated Power Peg. When the flag was switched on, that one server began executing the dead logic, sending more than 4 million orders in 45 minutes and producing a loss of more than $460 million. Automated emails flagging the problem were sent before the market opened, but nobody treated them as alerts.
AI agents make flag hygiene more urgent, not less. An agent asked to ship a feature safely will happily wrap it in a flag, and an agent asked to fix a bug will happily add another. Few of them will remove the flag once the rollout finishes unless your process demands it. Teams that adopt flags at scale need three rules: every flag has an owner and an expiry date, release flags are deleted within a fixed number of sprints after full rollout, and flag names are never reused. These are exactly the kind of mechanical rules worth encoding in agent instructions and CI checks, as we described in our article on agent skills.
Vendor lock-in is the other risk. Flag evaluation ends up in every service, so switching providers later means touching every call site. OpenFeature, a CNCF incubating project since December 2023, provides a vendor-neutral flag evaluation API with SDKs for the major languages. Coding against it from the start costs little and keeps your options open, which matters in a market where release tooling vendors are consolidating quickly.
How Do You Let Metrics, Not Reviewers, Promote a Change?
A canary only protects you if something is watching it. In many teams the canary step is a human glancing at a dashboard for ten minutes before clicking promote, which fails precisely when attention is thinnest: late on a Friday, or when twenty agent-generated pull requests are queued behind this one. The goal is automated analysis, where a release advances only if predefined metrics stay within bounds, and reverts on its own if they do not.
The open source tooling for this is mature. Argo Rollouts' analysis feature runs queries against Prometheus, Datadog, New Relic and other providers during a rollout and aborts it automatically when a success condition fails. Flagger does the same for Kubernetes workloads behind a service mesh or ingress controller. Commercial platforms add statistical comparison between canary and baseline. The tools are rarely the hard part.
The hard part is the metrics. Automated promotion needs service level objectives that reflect what users experience, such as error rate, p95 latency and the success rate of key business transactions, plus enough traffic in the canary slice to tell signal from noise. It needs telemetry tagged by version or flag state, so you can see that the new code path, not the whole service, is misbehaving. Teams without those foundations discover that their canary analysis either never fails or always fails, and quietly turn it off. This is why the observability work we described in our piece on the observability bill is a prerequisite, not an optional extra.
A newer pattern uses AI agents to interpret ambiguous canary results: a latency shift that might be a regression or might be a traffic mix change. That can be useful as an advisory layer. It should not replace deterministic threshold gates, for the same reason you would not let the model that wrote a change be the only one to approve it. Hard thresholds give you a floor that does not depend on any model's judgement.
| Strategy | What it limits | Main prerequisite | Best fit |
|---|---|---|---|
| Feature flag (dark launch) | Who sees new behaviour | Flag SDK, ownership and expiry rules | New features, risky logic changes |
| Canary release | Share of traffic on a new version | Version-tagged metrics and SLOs | Service deployments with steady traffic |
| Ring or cell rollout | Number of tenants or regions exposed | Tenant or regional isolation in the architecture | Multi-tenant SaaS, global platforms |
| Blue-green deployment | Time to revert a full release | Duplicate environment capacity | Monoliths, infrequent large releases |
| Automated rollback | Duration of a bad release | Reliable health signals and reversible migrations | Every strategy above |
What Should a Release Policy for AI-Generated Changes Look Like?
The practical answer is risk tiering. Instead of one review-and-release rule for every change, classify changes by what they can break, and attach review depth and rollout speed to the class rather than to who or what wrote the code. Authorship is getting harder to determine anyway, as agents, pair-programming tools and humans all touch the same diff.
A workable scheme has three tiers. Low-risk changes, such as copy, styling, internal tooling and test-only changes, get lightweight review, possibly AI-assisted, and ship through the standard pipeline with automated health checks. Medium-risk changes to application logic ship dark behind a flag, pass through an automated canary and are released progressively. High-risk changes, covering authentication, payments, data migrations, infrastructure and anything touching personal data, require named human review from a code owner, a staged rollout with explicit hold points and a tested rollback or roll-forward plan before merge.
Two engineering disciplines make the scheme hold together. First, database migrations must be backward compatible, using the expand-and-contract pattern, because a rollback that cannot undo a schema change is not a rollback. Second, the tiering must be enforced by tooling, through path-based rules in CODEOWNERS, CI checks that require a flag for changes in certain directories and pipeline templates per tier, rather than by asking developers or agents to self-classify. Agents follow enforced rules well. They follow written guidelines inconsistently.
Finally, measure the release system, not just the code. Track change failure rate and the newer DORA rework rate per tier, the share of incidents caught at canary versus by customers, time from merge to full release and the number of stale flags. If canary aborts are rising while customer-facing incidents fall, the system is working. If neither moves, your gates are not sensitive enough. Our article on why DORA metrics need rethinking in the AI era covers how to read these numbers without gaming them.
Key Takeaways
- Tier changes by what they can break, not by whether a human or an agent wrote them
- Low risk: light review and automated checks. Medium: flag plus canary. High: code-owner review and staged rollout
- Backward-compatible migrations are what make rollback real
- Enforce tiers with CODEOWNERS, CI rules and pipeline templates rather than self-classification
Who Builds the Release Layer When Your Team Is Busy Shipping Features?
Most product teams understand all of this and still do not do it, for a simple reason: progressive delivery is platform work, and platform work loses every prioritisation meeting to customer features. Building flag infrastructure, wiring version-tagged telemetry, writing canary analysis templates, refactoring migrations to be reversible and cleaning out years of stale flags is weeks of focused engineering that nobody on the roadmap owns. Meanwhile the AI tools keep increasing the volume of changes the missing system has to absorb.
This is where a dedicated development team works well. At Stepto, we regularly embed engineers with cloud and DevOps expertise alongside a client's product teams to build exactly this layer: an OpenFeature-based flag setup, Argo Rollouts or equivalent canary pipelines, SLO definitions that reflect real user journeys, and the CI rules that enforce a tiered release policy for human and agent-written code alike. Your in-house engineers keep shipping features, and the release system matures underneath them instead of being bolted on after the next outage.
Nearshore matters here for a practical reason. Progressive rollouts happen during business hours, when traffic is high enough for canary analysis to mean something and when people who can make a call are awake. A team in Serbia shares most of the working day with Western European clients and has a meaningful overlap with the US East Coast, so the engineers who built the pipeline are online while it promotes, holds or reverts a release. That is a different experience from waking up to an offshore team's overnight deployment that went wrong at 3 a.m. your time. Our nearshore development model is built around that overlap.
If you want to test the fit before committing, our engagements typically onboard in 2-4 weeks from the first call, and a two-week paid trial is enough to deliver a first concrete result, such as one critical service moved onto flag-gated canary releases with automated rollback, which is usually all the proof an engineering leadership team needs.
Upgrade the Release Side, Not Just the Code Side
AI coding agents have done what they promised: they write far more code, far faster. What they have not done is make that code safe to ship, and the data from Faros, Harness and DORA all points the same way: more changes, larger releases, longer reviews and more incidents per change. Tightening review alone treats a throughput problem as a diligence problem and makes releases bigger and riskier. The teams pulling ahead treat the release itself as the safety system. They decouple deploy from release, put meaningful changes behind flags with owners and expiry dates, promote through canaries gated on real user metrics, roll back automatically and tier their policy by risk rather than by authorship. Google, Cloudflare and CrowdStrike each learned this the expensive way and published the lessons. You can learn it from their postmortems instead of writing your own.
Building a team in Eastern Europe?
StepTo helps European and US companies build senior-led nearshore engineering teams in Serbia. Let's talk about what your next engagement could look like.
Start a conversation