AI-Generated Code Produces 1.7x More Issues Per PR—But Teams Ship 20% More PRs Anyway. Who Owns the Quality Ratchet?

General
1

I’ve been sitting with the CodeRabbit State of AI vs Human Code Generation Report for a couple of weeks now, and the numbers are making me rethink how we measure engineering productivity at my org.

The Numbers That Should Make Every Engineering Director Uncomfortable

CodeRabbit analyzed 470 open-source GitHub PRs (320 AI-co-authored, 150 human-only) and the headline findings are stark:

  • AI-authored PRs produce 10.83 issues per PR vs 6.45 for human-only PRs — that’s ~1.7x more issues
  • AI PRs show 1.4-1.7x more critical and major findings, including business logic mistakes, incorrect dependencies, and flawed control flow
  • Performance inefficiencies appear nearly 8x more often in AI-generated code (excessive I/O, unnecessary allocations)
  • The single biggest gap? Readability — AI code violates local naming conventions, clarity patterns, and structural expectations

Meanwhile, the industry data from ByteIota and others paints an even more concerning picture at scale:

  • PRs per author are up 20% year-over-year
  • But incidents per PR jumped 23.5%
  • Review times increased 91%
  • AI-generated PRs wait 4.6x longer for code review than human contributions
  • Technical debt increases 30-41% after AI adoption

The Uncomfortable Productivity Paradox

Here’s what keeps me up at night: my teams are shipping more PRs than ever. Our velocity metrics look phenomenal. Sprint burndown charts are beautiful. But when I dig into our incident reports and post-mortems, I’m seeing patterns that weren’t there 18 months ago.

We’re generating code faster than we can review it. And the review burden is falling disproportionately on our senior engineers—the exact people who should be doing architecture work, mentoring, and strategic thinking.

One of my senior staff engineers told me last month: “I spend more time now reviewing AI-generated code than I ever spent writing code myself. And the AI code looks right, which makes it harder to review than obviously bad code.”

The Quality Ratchet Question

At my org (40+ engineers, financial services), I’m trying to figure out who owns the quality ratchet:

  1. Is it the IC who prompts the AI? They generated the code, but they may not have the experience to know what “good” looks like in our specific domain.
  2. Is it the reviewer? We’re asking senior engineers to be the safety net, but the volume is overwhelming them.
  3. Is it the team lead/manager? Should we be setting AI adoption thresholds per team?
  4. Is it the org? Should engineering leadership mandate quality gates that are AI-aware?

The Exceeds.ai benchmarks suggest the sweet spot is 25-40% AI-generated code — teams in that range see 10-15% productivity gains while keeping review overhead manageable. Above 40%, quality gates start failing.

What I’m Experimenting With

On my teams, I’ve started a few experiments:

  • “AI Budget” per sprint: Each team can use AI for no more than 40% of new code, measured by our tooling
  • Mandatory self-review: If you used AI to generate code, you must add inline comments explaining why the AI’s approach is correct for our domain
  • Paired AI sessions: Junior engineers can only use AI coding tools when pairing with a senior engineer (not pairing with each other)
  • Incident attribution: We now tag post-mortems with whether AI-generated code was involved, no blame, just data collection

Early results after one quarter: incident rate dropped 18% while still maintaining most of the velocity gains. But it’s early.

The Broader Org Design Question

What I’m really wrestling with is this: AI coding tools are a force multiplier for code generation, but we haven’t redesigned our organizations around the new bottleneck, which is code review and validation.

We optimized our orgs for a world where writing code was the constraint. Now the constraint is understanding, reviewing, and maintaining code. That’s a fundamentally different organizational challenge.

Curious to hear from other engineering leaders: How are you thinking about this? Are you seeing similar patterns? And most importantly—who at your org owns the quality ratchet?

2

Luis, this post hit me right in the gut. I’m living this exact paradox at my org and I think the framing of “who owns the quality ratchet” is the wrong question — because the answer is the organizational system owns it, and most of our systems weren’t designed for this failure mode.

The Senior Engineer Burnout Spiral

Your staff engineer’s quote — “I spend more time reviewing AI code than I ever spent writing code myself” — could have come from any of my tech leads. What I’m seeing is a dangerous feedback loop:

  1. Junior engineers generate more code with AI
  2. Senior engineers spend more time reviewing
  3. Senior engineers have less time for architecture and mentoring
  4. Junior engineers get less mentoring, so they lean more on AI
  5. The quality gap widens

We tracked this at my org. Our senior engineers went from spending ~30% of their time on code review to 55% in the last year. That’s not sustainable. And the irony is brutal: the people with the most institutional knowledge are now spending the majority of their time being human linters instead of doing the high-leverage work that made them senior in the first place.

What “Owning the Quality Ratchet” Actually Means

I’d push back on your four options and say it’s none of them individually. At my org (scaling from 25 to 80+ engineers), I’ve landed on this framework:

Layer 1 — Automated quality gates (org owns this): CI/CD pipelines that catch the 60-70% of AI issues that are detectable — style violations, performance anti-patterns, security misconfigurations. Invest heavily here so humans don’t have to.

Layer 2 — Team-level review norms (team lead owns this): Each team defines what “reviewable” means for AI-generated PRs. Some of our teams require AI PRs to include a “decision log” explaining what was accepted/rejected from AI suggestions.

Layer 3 — Individual accountability (IC owns this): The person who clicks “merge” owns the code, full stop. AI is a tool, not a co-author. We don’t let people say “the AI wrote it” in post-mortems.

Layer 4 — Organizational learning (leadership owns this): Aggregating patterns across teams, adjusting policies, and redesigning roles. This is where the real work is.

The Role Redesign Nobody Wants to Talk About

Here’s the uncomfortable truth I’ve been discussing with my CTO: we may need to create a new role — something like a “Code Quality Engineer” or “Review Architect” — whose entire job is reviewing AI-generated output. Not a junior role. Not a linting bot. A senior person whose craft is understanding code rather than writing it.

The skills are different. Writing code requires creativity and problem-solving. Reviewing AI code requires pattern recognition, domain knowledge, and the ability to spot “plausible but wrong” — which is much harder than spotting “obviously wrong.”

Has anyone else started thinking about review as a first-class engineering discipline rather than a tax on shipping?

3

Reading this thread as a design systems lead and I keep thinking — we solved a version of this problem in design already. And the solution wasn’t restricting the tools, it was creating better constraints.

When Figma made it trivially easy for anyone to create UI components, we didn’t say “only senior designers can use Figma.” We built design systems with tokens, constraints, and guardrails baked in. You can move fast, but you’re moving fast within a system that makes it hard to create garbage.

The Readability Finding Is the Tell

Luis, you mentioned the biggest gap was readability — AI code violates local naming conventions, clarity patterns, and structural expectations. That’s almost word-for-word what happened when we first rolled out our component library without design tokens. Everyone was technically using the system but creating visual chaos because the constraints were too loose.

The fix wasn’t “use fewer components.” It was making the components smarter — embedding the constraints so that the default output was good, and you had to actively opt out to create something bad.

What does that look like for code? I’m genuinely asking because I’m not an engineer, but from the design world, it would mean:

  • Project-level AI configurations that enforce your naming conventions, architectural patterns, and code style automatically
  • Templates and scaffolding that AI tools use as starting points instead of generating from scratch
  • “Component libraries” for code patterns — approved implementations of common patterns that AI can reference

Basically: instead of reviewing the output, constrain the input.

The 4.6x Review Wait Time Is a UX Problem

The stat that jumped out to me most was AI PRs waiting 4.6x longer for review. That’s a signal that your review process has a UX problem, not just a capacity problem. If reviewers are subconsciously avoiding AI PRs because they’re harder to review, that’s a design challenge.

In our design critique process, we found that reviewers engaged more when the creator provided a “decisions document” alongside their work — explaining what they tried, what they rejected, and why they landed where they did. It reduced review time by about 40% because the reviewer could focus on evaluating decisions rather than reverse-engineering intent.

Could something similar work for AI-generated PRs? Not just inline comments, but a structured “here’s what I asked the AI, here’s what it generated, here’s what I modified and why” document?

I know this is a different domain, but the pattern of “tool makes creation easy, review becomes the bottleneck, solve it with better structure” feels universal.

4

I’m going to be the uncomfortable voice in this thread and ask: are we sure this is actually a problem, or is it a measurement problem?

I’m a VP of Product, not an engineer, so I see this through a business lens. And from where I sit, the question isn’t “how do we reduce issues per PR” — it’s “what’s the total cost of quality at the feature level?”

The Metrics Mismatch

Luis, you mentioned your velocity metrics look phenomenal and your sprint burndown charts are beautiful. As a product leader, those are the outputs I care about — features shipped, customer problems solved, time-to-market. If your teams are shipping 20% more features with the same headcount, that’s a real business outcome.

The 1.7x more issues per PR stat is alarming in isolation, but what’s the end-to-end quality like? If those issues get caught in review (which they apparently do, since review time is up 91%), then the system is working — it’s just working differently.

Here’s an analogy from product: when we moved from waterfall to agile, our “defect rate per sprint” went up dramatically because we were shipping more frequently. People panicked. But our customer-facing defect rate actually went down because we were catching issues faster and iterating quicker.

The Question Product Leaders Should Be Asking Engineering

What I’d push back on is the framing that this is purely an engineering problem. If AI tools let your teams ship 20% more, but quality review is the bottleneck, then we need to have a portfolio conversation:

  1. Which features justify the full quality bar? Payment processing and security-critical paths need maximum human review regardless of how the code was generated.
  2. Which features can tolerate a faster, riskier path? Internal tools, prototypes, experimental features — maybe the review bar should be lower.
  3. What’s the cost of not shipping faster? In my fintech startup, every week we delay a feature is a week a competitor can get ahead.

Your “AI budget per sprint” approach concerns me a little — not because it’s wrong, but because it applies a uniform constraint to non-uniform situations. A 40% cap on AI code for a critical payment microservice makes total sense. A 40% cap on an internal dashboard seems like it’s optimizing for the wrong thing.

What I’d Want as a Product Partner

If I were working with you, Luis, here’s what I’d ask for:

  • Risk-tiered AI policies: Different quality bars for different parts of the system
  • Feature-level quality metrics: Not “issues per PR” but “customer-reported issues per feature”
  • Speed-to-fix metrics: If AI code introduces more bugs but we can also fix them faster, the net impact might be neutral or positive
  • Opportunity cost accounting: What’s the cost of the features we didn’t ship because we were being conservative with AI?

I know engineers hate hearing “ship faster, worry about quality later.” That’s not what I’m saying. I’m saying the quality conversation needs to include the business context, not just the code-level metrics.

5

This thread captures exactly why I told my board last quarter that “AI developer productivity” is the most dangerous metric in enterprise software right now.

Luis, your data is solid. Keisha, your layered framework is how I think about it too. Maya, the design systems analogy is more apt than most engineers would admit. And David — I hear you on the business context, but I’m going to push back hard.

David, the “Measurement Problem” Framing Is How You Get Production Incidents

With respect, “the system is working, it’s just working differently” is exactly what engineering leaders at three companies I advise said before they had major quality incidents. The 91% increase in review time isn’t the system working — it’s the system degrading gracefully before it fails.

In financial services (Luis and I share that context), the cost of a quality incident isn’t just a bug fix. It’s regulatory scrutiny, audit findings, and potentially millions in compliance penalties. When I hear “customer-facing defect rate,” I think about the defects that haven’t happened yet because senior engineers are burning themselves out catching them in review.

David, your risk-tiered approach makes sense in theory. In practice, the boundaries between “critical path” and “internal tool” get blurry fast. That internal dashboard nobody reviews carefully? It’s the one an analyst uses to make a $50M trading decision. I’ve seen it happen.

The CTO’s Actual Job Here

Here’s what I think this comes down to at the executive level:

AI coding tools are an organizational transformation, not a developer productivity tool. And like every organizational transformation, if you treat it as a tools decision, you’ll get tools-level outcomes.

What I’m doing at my company:

1. Redefining “engineering productivity”: We retired PR velocity as a leadership metric. Our new primary metrics are: time-to-production (including review), production incident rate, and mean time to resolution. These capture the full cycle, not just the generation phase.

2. Investing in review infrastructure: We allocated 15% of our engineering budget this year specifically to review tooling, automated quality gates, and — here’s the controversial one — hiring two senior engineers whose primary role is code review. Not “reviewer” as a rotation, but review as a specialization.

3. Creating “AI maturity levels” per team: Not a cap, but a progression. Level 1 teams (new to AI tools) have strict guardrails. Level 3 teams (demonstrated quality track record with AI) have more autonomy. Teams earn trust by demonstrating outcomes, not by asserting competence.

4. Board-level reporting on AI quality metrics: I now include AI-related quality data in my quarterly board updates. Not because the board asked for it, but because when (not if) we have an AI-related incident, I want a track record of proactive governance. In regulated industries, “we didn’t know” is not an acceptable answer.

The Uncomfortable Prediction

Here’s what I think happens over the next 18 months: the companies that treat AI coding tools as “free productivity” without reorganizing will see a wave of quality incidents. The ones that invest in review infrastructure, role redesign, and quality metrics will pull ahead.

The quality ratchet isn’t owned by any one person or role. It’s a property of the system. And right now, most engineering organizations are running a system that was designed for a different era.

Luis, your experiments are exactly the right approach — measure, iterate, don’t over-commit to a single framework. Keep sharing the data. This is the most important conversation in engineering leadership right now.