What is the stability paradox in AI-assisted delivery?
The stability paradox is the pattern showing up in recent DORA research: AI assistance increases software delivery throughput, more changes shipped, faster, while delivery stability degrades, with higher change failure rates and more unplanned rework. Teams generate code faster than their verification systems can absorb it, and production is where the difference lands.
DORA's four key metrics split cleanly into a speed pair (lead time for changes, deployment frequency) and a stability pair (change failure rate, failed deployment recovery time). For a decade the research message was that elite teams get both. The AI era broke that correlation for many organizations: the speed pair improves quickly because generation is cheap, while the stability pair depends on review capacity, test depth, and operational maturity, none of which an assistant upgrades for free.
The practical symptom set: merge queues fill, review latency stretches, change failure rate creeps up, and incident retros keep landing on a change nobody fully understood.
What does the DORA research actually say?
In its recent State of AI-assisted Software Development reporting, DORA found AI adoption near-universal, roughly nine in ten surveyed developers using AI at work, with throughput gains now measurable but software delivery instability rising alongside adoption. DORA's own framing: AI is an amplifier of existing organizational strengths and weaknesses, not a substitute for them. Verify exact figures against the published reports before quoting them.
Two details matter more than the headline:
- ▸The trend moved. DORA's earlier AI-era data (the 2024 cycle) associated AI adoption with small declines in both throughput and stability; the following cycle showed throughput turning positive while instability persisted. The plausible reading is that teams learned to go faster before they learned to stay safe.
- ▸The mediators are old friends. DORA's AI capabilities work points at unglamorous practices, working in small batches, strong version-control habits, quality internal platforms, a clear organizational stance on AI use, as what separates teams that convert AI speed into performance from teams that convert it into incidents.
Nothing in the data says AI-generated code is inherently worse. It says unverified volume is destabilizing, whoever wrote it.
Why does faster code generation destabilize delivery?
Because generation scales and verification does not. An assistant multiplies the code a team produces, but review capacity, test depth, and deployment safety stay where they were. The constraint moves downstream: the bottleneck is no longer writing changes but safely absorbing them, and unabsorbed changes fail in production.
- ▸Review capacity is flat. PR volume rises, but the number of people qualified to review core paths does not. Teams either accept latency (queues, stale branches, painful rebases) or accept shallower review. Both raise failure rates.
- ▸Batch size creeps. Agents happily produce 1,500-line diffs, and large batches have always correlated with failed changes. The small-batches guidance in DORA's research predates AI and matters more now, not less.
- ▸Comprehension debt accumulates. Code enters the repository that no human on the team has fully reasoned through. It works until an incident demands the reasoning back. We covered the long-tail cost in The Technical Debt Time Bomb of AI-Written Code.
- ▸Tests confirm rather than challenge. Assistant-written tests tend to assert what the code does, not what it should do, high coverage, low protection.
- ▸Churn rises. Public analyses of large commit datasets have reported growing code duplication and quickly-reverted changes since assistants went mainstream; treat exact percentages cautiously, but the direction matches what we see in client repositories.
Where do AI-era incidents actually come from?
Mostly the same places as before, config changes, dependency bumps, contract violations between services, missing edge-case handling, but arriving in higher volume and reviewed more thinly. The genuinely new contributors: plausible-but-wrong logic that passes shallow review, hallucinated API usage, and insecure defaults reproduced from training data.
Patterns worth naming in retros:
- ▸Plausible-but-wrong logic: compiles, passes its generated tests, reads clean, and is subtly wrong about a business rule, the hardest class to catch without a domain-aware reviewer.
- ▸Cross-cutting inconsistency: the assistant edits one call site correctly and misses the siblings; nobody greps.
- ▸Silent contract drift: a generated change alters response shape or error semantics; downstream consumers fail hours later, disconnecting the incident from its cause.
- ▸Security regressions: permissive CORS, disabled certificate validation, and string-built SQL still appear in generated output; The Hidden Risks of Shipping AI-Generated Code to Production goes deeper.
If your incident reviews just say bad deploy, start tagging AI-assisted changes at merge time, a PR label is enough, so retro data can actually answer whether assisted changes fail more often for you.
How do you fix review latency without rubber-stamping?
Treat review capacity as a budgeted, engineered constraint rather than an infinite free resource. The levers: shrink diffs, route by risk, require verification evidence from authors, and let machines do the mechanical pass so humans spend their minutes on design and domain correctness.
- ▸Risk-tier the routing. Docs, tests, and config-with-guardrails get one reviewer plus automation. Auth, payments, migrations, and public contracts get a designated owner, no exceptions.
- ▸Cap diff size. A soft cap, say 400 changed lines, with stacked PRs above it. Reviewers approve small stacks faster and catch more.
- ▸Demand evidence, not vibes. The author (human plus agent) attaches test output, before-and-after behavior, and the spec or ticket link. Reviewing evidence is faster than reconstructing it.
- ▸Automate the mechanical pass. Linters, static analysis, and AI pre-review handle formatting, obvious bugs, and convention drift, so human review time buys design scrutiny. Our position on latency as the metric that matters is in Code Review Culture: Optimize for Latency, Not Gatekeeping.
Which merge gates actually protect stability?
Gates that bind evidence to the merge and shrink blast radius after it: required CI with meaningful tests, coverage measured on the diff rather than globally, static and secret scanning, a merge queue that keeps main green under volume, feature flags on risky paths, and progressive delivery with automated rollback tied to SLO burn.
Ordered roughly by return on effort:
- ▸Merge queue. At AI-era PR volume, testing each change against latest main before merge stops the green-in-isolation, broken-together failure class.
- ▸Coverage-on-diff. Require the changed lines to be exercised; global coverage numbers hide untested new code.
- ▸Progressive delivery. Canary a slice of traffic, watch error rate and latency against SLO burn, roll back automatically. This is the gate that converts a would-be incident into a non-event.
- ▸Feature flags with expiry. Risky paths ship dark, enable gradually, and flags get deleted on a schedule, flag debt is its own incident source.
- ▸Test discipline upstream. Gates catch symptoms; tests that assert intended behavior catch causes. A Testing Strategy That Survives Refactoring describes the shape that holds up.
What does not work: adding human sign-off layers. Extra approval steps raise latency, not quality, and DORA's change-approval research has said so for years.
What should you measure to catch the paradox early?
Pair every throughput metric with a stability twin and review them together, weekly, on one chart. Lead time pairs with change failure rate; deployment frequency pairs with recovery time; PR throughput pairs with rework rate. A speed metric improving while its twin degrades is the paradox announcing itself.
- ▸Rework rate: the share of changes reverted, hotfixed, or materially re-edited within 14 days. The most sensitive early signal we know.
- ▸Review depth proxies: time-in-review and approval-without-comment rate on non-trivial diffs. Gameable individually, informative in trend.
- ▸Authorship gap in incidents: the fraction of incidents where no responder authored the offending change, a direct measure of comprehension debt.
- ▸Flag and queue health: stale feature flags, merge-queue wait times, and rollback frequency round out the picture.
Avoid weaponizing any of these against individuals. The moment a metric becomes a target for engineers, it stops describing the system.
How do you keep incident response working when nobody wrote the code?
Assume responders have no authorship memory and engineer substitutes for it: traces that show what the code actually did, commits linked to specs and tickets that say what it was meant to do, runbooks per service, and retros that update all three. Authorship knowledge was always a crutch; AI removed it faster than teams noticed.
- ▸Link intent to change. Every merge references its spec, ticket, or ADR. During an incident, the question of what this code was supposed to do must be answerable without archaeology.
- ▸Prefer observability over tribal knowledge. Distributed traces and structured logs answer questions the author is no longer around, or was never around, to answer.
- ▸Run blameless retros that produce engineering change, not action-item theater; the discipline in Post-Incident Reviews: Turning Breaches into Engineering Change applies to reliability incidents exactly as it does to breaches.
- ▸Practice on purpose. Game days against services with heavy AI-authored code reveal comprehension gaps before an outage at 03:00 does.
How TuniCyberLabs helps
We build and operate software for EU and North African clients with AI assistance in the loop, so we live with this paradox daily. Our answer is the guardrail stack above, merge queues, coverage-on-diff, progressive delivery, and paired speed-stability metrics, implemented as part of our software engineering services. If your throughput went up this year and your incident count followed, we can help you find which gate is missing.
Book a delivery-stability review with an engineer: contact TuniCyberLabs.