The anti-pattern is scaling an AI coding pilot on adoption and velocity signals while the delivery system underneath stays unchanged. DORA's 2025 industry survey report says that path buys throughput and instability together. The fix is a gate on review, rollback and measurement before the pilot scales.
The Production Failure That Started This
The pilot dashboard is green. Seats are active, commits are up, developers report they are faster. Then the change fail rate climbs, and nothing in the adoption metrics moves to explain it.
That is the shape of the central finding in DORA's State of AI-assisted Software Development 2025 (v. 2025.2), an industry survey report whose survey of 4,867 respondents ran June 13 to July 21, 2025 [1, pp. 4, 103]. In DORA's 2025 industry survey report, 90% of respondents use AI as part of their work and more than 80% believe it has increased their productivity [1, p. 4]. The report states that AI adoption "now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability" [1, p. 4].
The Anti-Pattern Mechanism
DORA's headline is that AI "is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones" [1, p. 3].
The mechanism the report proposes is batch size. AI raises the volume of code per change. DORA hypothesises the instability is "likely, in part, because it is harder to review larger batches of code" [1, p. 57]. Review degrades, defects pass, and they surface as failed deployments.
The monitoring misses it because the pilot measures the wrong state. Adoption and self-reported speed describe the individual. DORA measures instability at the delivery system: change fail rate, "the ratio of deployments that require immediate intervention following a deployment," and rework rate [1, p. 13]. If the pilot never instruments those, the regression is invisible until it is an incident. Green is not correct.
The Architecture I Recommend
DORA's 2025 industry survey report names seven capabilities that amplify AI's positive impact: clear and communicated AI stance, healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, user-centric focus, and quality internal platform [1, p. 63, Figure 45]. I map three of DORA's 2025 seven directly onto a delivery gate a platform lead can own.
| Gate | DORA capability | Evidence [1] | Trade-off |
|---|---|---|---|
| Review | Working in small batches | AI's benefits "depend on teams working in small batches"; product performance amplified, friction reduced (p. 58) | Individual effectiveness gains "slightly reduced" (p. 58) |
| Rollback | Strong version control practices | Benefits depend on commit frequency and rollback use (p. 56); rollback proficiency "associated with better team performance" (p. 64) | Revert drills cost engineering time |
| Measurement | Quality internal platform | Platform quality enables "magnifying the positive effects of AI on organizational performance" (p. 64) | Instrumentation before rollout delays the pilot |
The measurement gate is a contract, not a dashboard. Every deploy emits one record:
deploy_id, commit_time, deploy_time, failed, ai_assistedfailed is true when the deploy needed a rollback or hotfix, which is DORA's change-fail definition. Lead time is commit to production, DORA's definition [1, p. 13]. Split by ai_assisted, and the amplifier becomes visible per team instead of per survey.
Production Readiness Checklist
- Median lines per change and changes per release are tracked, with a team-set ceiling for AI-assisted changes.
- Every change is reviewed before merge; oversized AI-assisted diffs are split, not waved through.
- A revert of the last production deploy has been run and timed within a window the team sets.
- Every deploy writes the record above, including
failedandai_assisted. - Change fail rate and lead time are computed for a baseline window before the pilot scales.
- A written AI policy names permitted tools and usage, DORA's "clear AI policy" practice [1, p. 64].
- The scale-up decision has a named owner and a numeric stop threshold the team sets in advance.
What I Would Build Differently
DORA's 2025 industry survey report gives cross-sectional associations with 89% credible intervals [1, p. 4]; they do not prove that a gate causes stability on your team. I have not run this check against any real team's deploy history. The thresholds in the blueprint are my starting defaults, not DORA benchmarks. The report also does not isolate how much of the instability effect each capability removes, so I treat the three gates as necessary, not sufficient. The next evidence I want is a team's own before-and-after change fail rate, split by ai_assisted. Start there.
What we offer: the Delivery Readiness Check blueprint, a scored checklist plus a tested Python script that computes change fail rate and lead time from your deploy CSV (Delivery Readiness Check on the roiscale.ai marketplace).
References
- DORA (Google Cloud). State of AI-assisted Software Development 2025, v. 2025.2. Survey June 13 to July 21, 2025. https://dora.dev/research/2025/dora-report/ (accessed 2026-10-14). Page numbers refer to the full English PDF.
