41% of code is now AI-generated. So why aren't we shipping faster?

General
1

Last week I sat in our sprint retro and someone asked: “We’re all using Claude, Cursor, Copilot… why does it still feel like we’re moving at the same pace?”

The silence was loud.

Here’s what I’ve been thinking about: 41% of all code written in 2025 is AI-generated. That’s not a prediction—it’s already happened. 82% of developers use AI tools weekly. Some of us are running 3+ tools in parallel. And yeah, we’re definitely coding faster. Studies show 30-55% speed improvements for scoped tasks.

But our delivery velocity? Basically unchanged.

The bottleneck just moved

I started tracking this on my team. Developers finish features 40% faster than last year. Pull requests get opened way more frequently—someone mentioned a 98% increase in PR volume across high-adoption teams.

But guess what else happened? PR review time increased 91%.

The bottleneck didn’t disappear. It just migrated downstream.

Now we’re all waiting on reviewers. And reviewers are drowning because AI-generated code tends to be… verbose. More lines to review. More edge cases to think through. And here’s the kicker: only 33% of developers say they actually trust AI-generated code. So reviewers are reading everything twice.

From a design perspective, I’m seeing the same pattern in UX review. Engineers prototype UIs faster with AI assistance, but the designs are often inconsistent with our system, use deprecated patterns, or ignore accessibility. So design review has become the new bottleneck.

Are we optimizing for the wrong metrics?

Individual velocity is up. That’s real. But organizational throughput is flat—or worse, because we added coordination overhead.

It’s like giving everyone on an assembly line faster tools, but not widening the conveyor belt. You just create a pile-up.

I keep thinking about what happens when 50%+ of code is AI-generated by late 2026 (current trajectory). If we don’t fix the downstream bottlenecks—review, QA, security validation, integration testing—we’re just making the pile-up bigger.

What if we’ve been measuring the wrong thing all along?

Instead of “how fast can one person write code,” maybe the question is “how fast can value flow through the entire system?”

What should we actually measure?

I’m genuinely curious what y’all are seeing:

  • Are your teams shipping faster with AI tools, or just coding faster?
  • Where are your bottlenecks showing up now?
  • What metrics are you tracking beyond individual velocity?
  • Has anyone successfully restructured their review/QA processes to match the new pace?

Because right now it feels like we’re all optimizing our local maxima while the global system stays stuck.

What am I missing here?

2

Maya, this resonates hard. We’re seeing the exact same pattern in financial services.

The fundamental issue is that we’re applying an individual productivity lens to what is fundamentally a systems throughput problem.

In our org, we’ve instrumented this carefully. Individual developer velocity is up 35-40% on average. Sprint velocity (story points per sprint)? Up maybe 5%. Deployment frequency? Unchanged. Lead time from commit to production? Actually increased by 18%.

Where the bottleneck shows up

Your PR review example is spot-on, but it goes deeper:

  1. Review capacity is fixed - We didn’t hire more senior engineers to do reviews just because AI makes code faster. So review became the constraint.

  2. Code volume inflates - AI-generated code is often longer and more verbose. One function that used to be 20 lines is now 45 lines. More surface area to review.

  3. Trust tax - When only 33% of devs trust AI output, reviewers compensate by being more thorough. Review time per line of code has increased.

  4. Integration complexity - More PRs means more merge conflicts, more coordination overhead, more “wait, who’s working on that module?”

The systems view

What we’re learning: optimizing one part of the value stream just reveals the next constraint. It’s Theory of Constraints 101.

The real question isn’t “how do we code faster?” It’s “what’s preventing value from flowing through the entire system?”

We’ve started instrumenting different metrics:

  • Cycle time (idea → production) rather than coding time
  • Review queue depth - how many PRs are waiting for review
  • Rework rate - how often does AI-generated code need fixes after merge
  • Cross-team dependencies - are we creating more coordination overhead?

The teams that are actually shipping faster with AI aren’t just coding faster—they’ve restructured their entire review and validation pipeline to handle higher throughput.

Anyone else instrumenting beyond individual velocity? What metrics actually correlate with business outcomes?

3

This thread is exactly why Product and Engineering need to be in constant alignment.

From a product perspective, I’ll be blunt: I don’t care if engineers are coding 50% faster if we’re not shipping value to customers faster.

We’ve been tracking AI tool adoption on my teams, and here’s what I’m seeing:

The metrics that actually matter

Individual coding velocity is a lagging indicator of business value. What I care about:

  1. Time to market - How long from customer request to shipped feature? (Mostly unchanged despite AI adoption)

  2. Feature quality - Are we reducing support tickets and bug reports? (Actually up 15% - AI code introduces subtle bugs)

  3. Customer value delivered - Revenue impact, retention improvements, usage metrics (Flat to slightly negative)

  4. Team capacity for innovation - Are we spending time on differentiated features or fighting AI-generated bugs? (More time on QA)

Maya’s question about measuring the wrong thing is critical. Engineering velocity != product velocity.

The AI productivity mirage

I’m starting to think we’re in an AI productivity mirage. High adoption (82% of devs using AI weekly), visible speed gains on individual tasks, but when you look at business outcomes? Modest at best.

It’s like the old Solow Paradox: “We see computers everywhere except in the productivity statistics.”

The teams that ARE seeing real gains are doing something different:

  • They’ve streamlined not just coding, but the entire feature delivery pipeline
  • They’ve invested in automated testing to handle higher PR volume
  • They’ve moved validation earlier (shift-left on quality)
  • They’ve reduced cross-team dependencies

What I need from Engineering

Honestly? I need us to stop celebrating “PRs merged” and start measuring “value delivered.”

If AI lets us code faster but QA becomes the bottleneck, let’s invest in AI-assisted testing.

If review is the bottleneck, let’s restructure review practices or add review capacity.

If integration is the bottleneck, let’s rethink our architecture.

Luis mentioned Theory of Constraints - that’s exactly right. Optimizing one step creates the next constraint. We need to optimize the entire system, not just the coding step.

Are other product leaders seeing this gap between engineering velocity metrics and actual business outcomes?

4

Maya, Luis, David - yes to all of this.

From an organizational design perspective, what we’re seeing is a classic misalignment between local optimization and system optimization.

We’ve handed individual contributors faster tools without redesigning the organizational systems around them. It’s like upgrading the engine in a car without upgrading the transmission or brakes.

The organizational response

Here’s what we’ve learned scaling our EdTech engineering org through high AI adoption:

1. Review is a capacity problem, not a process problem

When PR volume went up 98%, we didn’t just tell reviewers to “work faster.” We:

  • Added dedicated reviewers in rotation (20% of senior eng time)
  • Implemented AI-assisted code review to catch obvious issues
  • Created review SLAs with escalation paths
  • Paired AI code generation with AI code review

2. Trust is an organizational asset

The 33% trust rate for AI code isn’t just a technical problem - it’s a cultural and process problem.

High-trust environments (strong testing, good architectural patterns, clear standards) can move faster with AI. Low-trust environments add manual verification layers that negate AI speed gains.

We’ve invested heavily in:

  • Automated testing that validates AI-generated code
  • Clear coding standards that AI tools can follow
  • Architectural decision records (ADRs) that guide AI tool usage
  • Post-incident reviews that include “did AI contribute to this issue?”

3. Metrics that drive behavior

We shifted from individual velocity metrics to team flow metrics:

  • Lead time (commit to deploy)
  • Deployment frequency
  • Change failure rate
  • MTTR (mean time to recovery)

These are DORA metrics, but they focus on system throughput, not individual speed.

When teams are measured on flow metrics, they naturally optimize the entire pipeline - not just their individual coding speed.

The hard organizational question

Maya asked if we’re optimizing for the wrong metrics. I think the deeper question is: Are we willing to restructure our organizations to match the new reality?

AI tools are forcing us to confront inefficiencies we’ve ignored for years:

  • Manual review bottlenecks
  • Poor test coverage
  • Weak architectural patterns
  • Siloed quality practices

The teams shipping faster with AI aren’t just using better tools - they’ve redesigned their entire value stream.

That requires investment, organizational change, and often uncomfortable conversations about what we actually optimize for.

Anyone else gone through organizational restructuring in response to AI tool adoption? What worked? What failed?

5

Wow, this is exactly the conversation I needed.

Luis - your point about Theory of Constraints is crystallizing something for me. We’ve been treating AI productivity like it’s additive (“everyone codes faster = ship faster”) when it’s actually revealing systemic constraints we could ignore before.

David - the “AI productivity mirage” framing is perfect. It captures why leadership is excited (high adoption! visible speed!) while teams feel frustrated (why aren’t we shipping faster?).

Keisha - the organizational redesign point hits hard. From a design systems perspective, I’m seeing the same thing: teams that succeed with AI haven’t just adopted tools - they’ve restructured how design, engineering, and product work together.

What I’m taking away

The real competitive advantage isn’t AI tool adoption - it’s organizational adaptability.

Companies that can redesign their value streams around AI capabilities will win. Companies that just give everyone AI tools and expect magic will create expensive bottlenecks.

From a design lens, this reminds me of responsive design. It’s not enough to make individual components work on mobile - you have to rethink the entire experience for the new constraint.

Same with AI. It’s not enough to make individuals faster - we have to rethink:

  • Review capacity and processes
  • Testing strategies
  • Quality gates
  • Cross-functional collaboration
  • What we even measure as “success”

Practical question

For folks who’ve restructured their processes: what was the hardest part?

I’m guessing it’s not the technical changes - it’s the cultural shift from “individual hero productivity” to “system flow optimization.”

Especially in organizations that still promote based on individual contributions rather than system improvements.

Anyone navigate that successfully?