AI Doubled Our Merged PRs — Heres What Actually Broke (And What Didnt)

The Real Bottleneck Isn't AI Code Quality

When your platform serves 100 million concurrent clients and pushes 11–12 million backend requests per second across ~3,000 production services, the question "is AI writing bad code?" is the wrong question.

The right question is: can your verification system keep up with the volume of change AI lets you produce?

Google Cloud's 2025 DORA research already flagged the pattern: AI adoption correlates with higher delivery throughput but lower delivery stability. Most teams read that and panic about code quality. The actual failure mode is subtler — review, testing, rollout, and observability simply weren't designed for the new velocity.

Here's what a year of running AI-assisted development at scale actually revealed.

For the underlying engineering report, see the 근거자료.

The Metrics That Actually Moved

When merged PRs jumped from ~8,100 to 17,000 month-over-month, the instinct is to assume quality debt is piling up. The data said otherwise:

• Quality & optimization work: 27% → 31% of the mix (more than 2× absolute volume)
• Maintenance & config: 31% → 25% of the mix
• Rework rate: no corresponding rise, despite industry-wide code churn spikes (per FAROS 2026)

The key insight is the rework rate vs. code churn distinction. Code churn measures added-vs-deleted lines — a noisy metric that AI inflates naturally. Rework rate weights the age of code being changed, which is a better proxy for whether recent work holds up under real-world pressure.

# Simplified rework rate calculation
# Rework = changes to code younger than N days / total changes
def rework_rate(commits, code_age_threshold_days=21):
    recent_edits = 0
    total_edits = 0
    for commit in commits:
        for change in commit.changes:
            total_edits += 1
            # Age of the line being modified, not the file
            if change.line_age_days < code_age_threshold_days:
                recent_edits += 1
    return recent_edits / total_edits if total_edits else 0.0

# Warning: do NOT calibrate thresholds to make your team feel better.
# Two signals worth watching: code complexity and PR size.

Two metrics are creeping up and worth monitoring without immediately rewriting thresholds: code complexity and PR size. Pre-AI, a large PR was a red flag. Post-AI, a large PR may just mean a human and an agent reasoned through a bigger unit of work together. Nobody has conviction on which hypothesis is right yet — so don't touch the thresholds until you do.

The Failure Modes Nobody Warned You About

1. Compute Scarcity Is Now a Quality Problem

Industry-wide AI demand spiked CPU/GPU consumption without matching supply. For platforms that used to treat compute as "always available," regional failovers — normally a non-event — suddenly exposed capacity gaps. Lower service tiers got starved. End users noticed.

Mitigations that worked:

• Doubled reserved edge capacity after a real incident
• Manual service-mesh traffic shifting (edge traffic controls still in progress)
• Accepting that during failover, lower tiers may not get capacity

2. Silent Pipeline Failures Compound Fast

Content processing at 500K+ new items/day had two pre-existing weaknesses: failures that didn't page anyone, and no headroom for video transcoding spikes. Add a batch job competing with live uploads and a 10% scheduler throughput bug, and minutes-long publishes became hours-long delays.

3. Automated Fleet Changes Create New Failure Modes

A Java migration across backend services completed in 3 days via agentic changes. Impressive — until an automated dependency upgrade passed all safety checks and still broke production. The fix isn't less automation; it's rollback capacity, owner-hours scheduling, and stronger pre-merge safeguards.

If you're deploying inference infrastructure for these agentic workloads, the SageMaker HyperPod inference operator setup guide covers the one-click install path.

4. The Mobile Quality Cycle Is Spinning Faster

AI didn't make mobile code worse. It made the ship-fast-then-recover cycle spin faster, so gaps surface before existing guardrail metrics catch them. The response: broaden quality signals, add longer-term trend analysis to release decisions.

What This Means for Your Team

Three takeaways worth stealing:

1. Measure rework rate, not code churn. Churn is noisy under AI. Rework rate (age-weighted) tells you if recent work is actually holding up.
2. Assume your verification system is the bottleneck. If merged PRs doubled and your review/test/rollback capacity didn't, you're accumulating latent risk — even if incidents look flat.
3. Don't rewrite thresholds to feel better. When complexity and PR size creep up, resist the urge to redefine "normal." Watch for leading indicators before you recalibrate.

The uncomfortable truth: AI-authored code did not show up as a material direct contributor to major incidents. The pressure came from volume, capacity, and verification lag. Fix the delivery system, not the code generator.

Limitations & Caveats

• This is one company's data at one scale. Your mileage will vary based on service count, review culture, and on-call maturity.
• "No AI failure signature" is not the same as "AI code is safe." It means AI-attributable failures weren't distinguishable from baseline noise in their dataset.
• Compute scarcity is a macro trend — plan for it, don't assume it away.

Next Steps

• Audit your verification pipeline's throughput against your new PR velocity
• Instrument rework rate if you haven't already
• Stress-test regional failover under realistic (not ideal) capacity assumptions

Related Reading

• Holotron-12B: The Hybrid SSM Model That Doubles AI Agent Throughput — the inference-side story behind why agentic workloads are exploding.