Our developers are 50% faster with AI, but we're shipping at the same pace. What gives?

[vp_eng_keisha]

Eight months ago, we rolled out AI coding assistants across our EdTech engineering team. The adoption was immediate—developers loved them. Within weeks, I was seeing activity metrics I’d never seen before: commits up 40%, pull requests up 65%, story points completed up 35%.

I thought we’d found the holy grail of engineering productivity.

But here’s what’s kept me up at night: our feature delivery velocity is exactly the same as it was before AI.

We’re generating more code than ever. Our developers genuinely feel more productive. But we’re shipping features at the same rate we did eight months ago. In some sprints, we’re actually shipping less because of the chaos that comes with all this new code.

The Data That Confirms I’m Not Crazy

I started digging into this and found I’m not alone. CircleCI’s 2026 State of Software Delivery report shows a 59% increase in average engineering throughput with AI tools. That tracks with what we’re seeing.

But here’s the kicker: their data also shows that feature branch throughput went up 15% while main branch throughput went DOWN 7%.

Teams are moving faster on their branches, but the code is getting stuck somewhere before it reaches production.

Where I Think the Productivity Is Vanishing

After months of observation and painful retrospectives, here’s my hypothesis: the bottleneck shifted from coding to everything that happens after coding.

Specific patterns I’m seeing on my team:

1. Review Queue Explosion
Our PR queue has tripled in size. PRs are not just more numerous—they’re also larger and more complex. Senior engineers who used to spend 30% of their time reviewing now spend 60%. They’re exhausted, and despite their best efforts, things are slipping through.

2. QA Team Overwhelmed
Our QA team’s capacity didn’t magically scale with the code output. They’re drowning. Features are “done” from an engineering perspective but sitting in a QA backlog for days.

3. Integration Chaos
More parallel development means more merge conflicts, more CI/CD queue time, more deployment coordination. Our main branch integration process wasn’t designed for this volume.

4. More Rollbacks
Because reviews are rushed and testing is overloaded, we’re catching issues in production that we used to catch earlier. Rollback rate is up 40%.

The Uncomfortable Realization

I realized we’ve been measuring AI productivity at the input (how fast developers code) instead of the output (how fast we deliver value to users).

Waydev’s research calls this the “engineering leadership blind spot of 2026”—activity goes up, but business outcomes lag. We’re optimizing the wrong part of the system.

It’s like we upgraded the engine on a car but left the transmission, brakes, and steering wheel unchanged. The engine roars, but the car isn’t going any faster because the other systems can’t keep up.

What I’m Trying Now

We’re experimenting with:

• Dedicated review capacity: Rotating senior engineers into full-time review weeks
• Stricter PR size limits: AI makes it easy to write 500-line PRs, but they’re impossible to review well
• QA automation investment: Using AI tools to generate test cases, not just implementation code
• Process redesign: Questioning every handoff that was designed for lower throughput

But I’ll be honest—I don’t know if these will work. The pressure to “move fast” is immense, especially when competitors are adopting the same tools.

Questions for This Community

For those of you managing engineering teams in the AI era:

• Are you seeing the same pattern? Increased activity but flat delivery velocity?
• Where is your bottleneck? Review? QA? Integration? Something else?
• What metrics are you tracking? I’m realizing commits and PRs are vanity metrics—what actually matters?
• How are you adapting your processes? What’s worked? What hasn’t?

I keep asking myself: are we optimizing the wrong part of the system? Should engineering leaders be investing in review infrastructure, QA automation, and integration tooling instead of just coding tools?

Would love to hear how other teams are navigating this.

[eng_director_luis]

Keisha, this hits way too close to home. We’re seeing the exact same pattern in our financial services org—and in our environment, the stakes are even higher because of regulatory requirements.

Our Numbers Tell the Same Story

Feature branch velocity: +40%
Main branch velocity: -12%

When I first saw those numbers, I thought our tooling was broken. Nope. The tools are working exactly as designed. The problem is everything around the tools.

In Fintech, the Bottleneck Is Compliance

Your QA and review challenges? Multiply that by regulatory compliance requirements and you’ll see what we’re dealing with.

AI generates code fast—sometimes frighteningly fast. A junior developer can scaffold an entire microservice in a few hours. But our security and compliance teams still need to validate every single line before it touches production.

We can’t shortcut this. A security vulnerability that would be a “whoops, patch it” moment at a consumer app could mean millions in fines and regulatory scrutiny for us.

The Trust Problem

Here’s what keeps me up at night: How do you review code when you can’t tell if the patterns are best practices or AI hallucinations?

Last month, one of our senior engineers caught a SQL injection vulnerability in an AI-generated data access layer. It had already passed through two code reviews. The code looked fine—proper ORM usage, parameterized queries in most places. But tucked in one conditional branch was a string concatenation that would’ve been a security disaster.

The reviewer who missed it is one of our best. She’s just exhausted. When you’re reviewing 3x the volume of code, things slip through.

What We’ve Tried (Mixed Results)

1. AI-Assisted Code Review Tools
We deployed tools that use AI to review AI-generated code (yes, I see the irony). Results have been mixed. They catch some patterns well, but they also generate false positives that waste reviewer time.

2. Stricter Automated Testing
We’ve invested heavily in expanding our test coverage and security scanning. This helps, but it’s not a silver bullet. Tests can only catch what they’re designed to catch.

3. Pair Programming for AI-Generated Code
We experimented with requiring pair programming sessions when using AI tools. Quality improved, but it defeated the productivity gains. We’re basically back to pre-AI speed.

4. Trust Tiers
We tried creating different review levels based on risk. Low-risk changes get lighter review, high-risk changes get intensive scrutiny. This is theoretically sound but practically hard to implement. How do you classify risk accurately at scale?

The Dilemma We’re Stuck In

We can’t slow down AI adoption—our competitors aren’t waiting, and the talent market expects these tools now. But we also can’t compromise on quality in a regulated environment.

The regulatory framework hasn’t adapted to AI-generated code. Our auditors still expect the same rigor, the same documentation, the same attestations. And they’re right to expect that.

So we’re trying to move twice as fast while maintaining the same thoroughness. The math doesn’t work.

Questions I’m Wrestling With

For teams in regulated industries: How are you handling security review of AI-generated code at scale? What’s working?

For platform/infrastructure teams: What automated quality gates have you implemented that actually move the needle?

For anyone: How do you balance the competitive pressure to adopt AI tools with the quality pressure to get it right?

I’m starting to think the real ROI of AI coding assistants won’t come from individual developer productivity—it’ll come from the investments we’re forced to make in automated testing, better review tools, and more robust quality gates.

Maybe AI is forcing us to fix the parts of the development process we should have fixed years ago.

[cto_michelle]

I’m going to push back on the framing here, because I think we’re asking the wrong question.

The question isn’t “where does productivity vanish?” It’s “are we measuring the right kind of productivity?”

The Uncomfortable Alternative Hypothesis

What if the productivity isn’t vanishing at all? What if teams are (consciously or unconsciously) investing those AI-generated time savings into quality activities that don’t show up in feature delivery velocity?

Think about it: if AI makes coding 50% faster, what do developers do with that extra time?

Option A: Ship 50% more features (this is what we expect)
Option B: Spend the saved time on better design, more thorough testing, more thoughtful code review, more documentation, more refactoring (this is what actually happens)

We’ve been operating under the assumption that Option A is the goal. But maybe Option B is the wiser choice.

Our Data at the SaaS Company

We’ve had AI coding assistants for 10 months. Here’s what happened:

Feature delivery velocity: +8% (modest, not the 50% we expected)

But also:

• Test coverage: +42%
• Code review discussion length: +35% (more thorough reviews)
• Documentation quality scores: +40% (developers actually writing docs because AI makes it less painful)
• Time spent on architectural discussions: +28%
• Technical debt remediation: +55%
• Defect escape rate: -35% (fewer bugs making it to production)
• Customer-reported quality issues: -28%

Coding Is Only 20-30% of Software Delivery

This is the critical insight that keeps getting missed.

If AI makes the coding part 50% faster, but coding is only 20-30% of the total software delivery cycle, then the maximum theoretical improvement to end-to-end velocity is 10-15%, not 50%.

The other 70-80% is:

• Requirements gathering and clarification
• Design and architectural decisions
• Cross-team coordination and dependencies
• Code review and knowledge sharing
• Testing and quality assurance
• Deployment coordination and risk management
• Monitoring and incident response
• Documentation and knowledge transfer

AI doesn’t automatically speed up those activities. In many cases, it can actually slow them down (more code to review, more integration complexity, more surface area to test).

The Productivity We’re Not Measuring

Here’s what I’m seeing that doesn’t show up in feature velocity:

1. Higher Quality Decisions
When developers spend less time fighting with syntax and boilerplate, they have more cognitive capacity for system design and architecture. We’re seeing better design proposals, more thoughtful API contracts, fewer “we need to refactor this” conversations three months later.

2. More Resilient Systems
With AI writing tests and handling edge cases, our systems are becoming more robust. We’re shipping at the same velocity, but what we ship is more reliable.

3. Better Developer Experience
Less time on tedious tasks means less burnout, better retention, higher engagement. That’s productivity, just not the kind that shows up in a sprint velocity chart.

4. Reduced Technical Debt
For the first time in years, we’re paying down technical debt instead of accumulating it. Because refactoring is less painful with AI, teams are actually doing it.

The Measurement Trap

We’re measuring outputs (features shipped) instead of outcomes (value delivered, quality achieved, systems improved).

It’s like judging a restaurant by how many dishes the kitchen produces per hour instead of whether customers enjoy the meal and come back.

If AI lets us ship the same number of features but with 35% fewer bugs, better documentation, cleaner architecture, and less technical debt—isn’t that a massive productivity win?

The Controversial Take

Maybe AI isn’t making us slower. Maybe it’s saving us from ourselves—from the relentless pressure to ship faster without thinking about sustainability.

Teams with AI tools are choosing quality over quantity. They’re investing the time savings in long-term excellence rather than short-term feature throughput.

The question we should be asking isn’t “why aren’t we shipping more?” It’s “what are we doing better because we’re not spending all our time on implementation details?”

Challenge for This Community

Before we try to “fix” the productivity paradox, maybe we should measure whether there’s actually a problem:

• Track your defect rates, not just your feature velocity
• Measure technical debt trends, not just story points completed
• Survey developer satisfaction and cognitive load
• Look at customer-reported quality issues over time
• Assess system reliability and resilience

If those metrics are improving while feature velocity is flat, you might not have a productivity problem. You might have a measurement problem.

What if the productivity isn’t vanishing? What if it’s being invested in ways we’re just not tracking?

[maya_builds]

As someone who watches engineering teams from the design side, I’m seeing something slightly different—and it’s making me uncomfortable.

The Pattern I’m Observing

Engineers are coding faster, yes. But they’re also thinking less.

Michelle’s hypothesis about investing time in quality is beautiful in theory. But that’s not what I’m seeing happen in practice—at least not consistently.

A Recent Example That Made Me Wince

Two weeks ago, our product team had a feature in the backlog that had been there for a month: an admin dashboard for managing user permissions. The designs were a month old. The requirements had evolved.

One of our engineers discovered it, got excited about trying out an AI coding assistant on a “real” project, and just… built it. In two weeks. The entire dashboard.

Product and design weren’t in the loop because the engineer assumed it would take 6 weeks (the old estimate). By the time we saw a demo, half the requirements had changed and the UX patterns didn’t match our design system updates.

We ended up rebuilding about 50% of it.

Net time from start to final version? About 6 weeks. The same as the original estimate before AI tools.

The Root Cause: When Implementation Feels Free

Here’s what I think is happening: AI makes implementation feel trivial, so teams skip the hard work of problem definition.

It used to be that building something took long enough that you had to think carefully first. The cost of building the wrong thing was prohibitive.

Now? “Let’s just code it and see” becomes a viable strategy. Except it’s not—you still need to understand the problem, validate the solution, and align with stakeholders.

The Collaboration Breakdown

Since AI adoption at our company, I’ve noticed:

• Fewer design-engineering pairing sessions
  Engineers feel less need to collaborate upfront because they can “just code it fast”

• More “we already built it” conversations
  Product and design finding out about features after they’re mostly done

• Less pushback on unclear requirements
  If coding is easy, engineers are less motivated to clarify requirements that don’t make sense

• Faster divergence from design systems
  AI suggests patterns that look reasonable but don’t match our established standards

The Speed Trap

Michelle, you talked about teams investing AI time savings in quality. I want to believe that’s happening. But I’m also seeing teams fall into what I call the speed trap:

1. AI makes coding feel effortless
2. Engineers jump straight to implementation
3. They discover problems mid-build that should have been caught in design
4. They iterate in code instead of in design tools (expensive)
5. Cross-functional teams get pulled in late to fix issues
6. The whole system slows down

The productivity doesn’t vanish—it gets wasted on preventable rework.

What We’re Trying (With Mixed Results)

Mandatory Design Review Before Coding
We now require a 30-minute design review before any AI-assisted feature work starts. It slows down the beginning, but it speeds up the end.

Early results: Features take about the same time start-to-finish, but we’re throwing away way less work.

“Pre-Flight Checklist” for AI-Assisted Features

• Requirements confirmed with product in last 2 weeks
• Design review completed
• UX patterns align with design system
• Success metrics defined
• Stakeholders aware this is in progress

It feels bureaucratic, but it’s catching a lot of “wait, why are we building this?” moments before they become “why did we build this?” regrets.

Explicit Time Allocation: 30-40-30 Rule

• 30% planning and design
• 40% building
• 30% testing and iterating

Forces teams to spend time thinking before coding.

The Uncomfortable Question

Here’s what keeps me up at night: Are we building the right things faster, or just building things faster?

AI optimizes for execution speed. It doesn’t optimize for building the right thing.

If a team uses AI to build the wrong feature in 2 weeks instead of 4 weeks, that’s not productivity—that’s negative productivity. You’ve wasted effort faster.

Questions for Engineers

• How has AI changed your collaboration patterns? Are you pairing with design/product more or less?

• How do you balance speed and thoughtfulness? What keeps you from jumping straight to code?

• Are you measuring feature success, not just feature delivery? Do the features you ship faster actually perform better?

Keisha, you asked where productivity is vanishing. I think a chunk of it is vanishing into features that solve the wrong problem—just solved really fast.

The paradox isn’t just about organizational bottlenecks. It’s about teams coding faster than they can think.

[data_rachel]

This entire thread is a perfect example of why this is fundamentally a measurement and observability problem, not just a productivity problem.

We’re all describing different parts of the elephant. Keisha sees bottlenecks. Luis sees compliance friction. Michelle sees quality investment. Maya sees collaboration breakdown.

You’re all right. And you’re all flying blind because you’re measuring the wrong things.

The Vanity Metric Trap

Let me share what happened with our data infrastructure team when we adopted AI coding assistants.

Metrics that went UP:

• Commits per developer: +52%
• Pull requests opened: +68%
• Lines of code written: +73%
• Story points completed: +28%

Leadership was thrilled. “Look at this productivity!”

Metrics that went DOWN or stayed FLAT:

• Time from idea to production: +3% (actually slower)
• Data pipeline reliability: -8% (worse)
• Time to resolve incidents: +15% (slower)
• Developer satisfaction: -12% (worse)
• Deployment frequency: -2% (slightly down)

We were moving faster but delivering worse outcomes. Classic Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure.

What We Actually Needed to Track

We built what I call a “productivity dashboard” that tracks end-to-end system health, not just developer activity:

Delivery Metrics:

• Feature lead time (idea → production, not just commit → merge)
• Cycle time breakdown (where is time actually spent?)
• Deployment frequency
• Change failure rate
• Mean time to recovery

Quality Metrics:

• Defect escape rate (bugs found in production vs caught in review/testing)
• Test coverage (and test effectiveness, not just %)
• Technical debt ratio (time spent on debt vs new features)
• Rework rate (how much code gets rewritten within 30 days?)

Developer Health Metrics:

• Code review wait time (are reviewers overwhelmed?)
• PR size distribution (are PRs getting too large to review well?)
• Context switching frequency (are developers juggling too much?)
• Developer satisfaction and cognitive load (survey data)

Business Impact Metrics:

• Customer-reported quality issues
• Feature adoption rates
• Support ticket volume related to bugs
• System reliability (uptime, performance)

What We Discovered (The Inconvenient Truth)

After 6 months of tracking these metrics alongside AI adoption:

Positive AI Correlation:

• Test writing velocity: +90% (AI is really good at generating test cases)
• Prototype speed: +65% (AI excels at scaffolding and boilerplate)
• Documentation completeness: +45% (AI makes docs less painful)

Negative AI Correlation:

• Bug density in production: +23% (more bugs per feature)
• Code review time per PR: +40% (larger, more complex PRs)
• Time spent resolving merge conflicts: +55% (more parallel development)
• “Why did we build this?” questions: +38% (the Maya problem—building without thinking)

Neutral/Complex:

• Overall feature delivery: +8% (modest gain, lots of variance)
• Developer satisfaction: Mixed (love the tools, hate the chaos)

The Bottleneck Visibility Problem

Here’s what the data showed us: the bottleneck shifted, but we didn’t notice because we weren’t measuring downstream effects.

1. Coding bottleneck → Review bottleneck
   Senior engineers maxed out on review capacity

2. Review bottleneck → QA bottleneck
   More code merged = more testing load

3. QA bottleneck → Integration bottleneck
   More features in flight = more conflicts, more coordination

4. Integration bottleneck → Deployment risk
   Larger batches of changes = higher failure rate

Each bottleneck created queue time that absorbed the AI productivity gains.

It’s like making your factory assembly line 50% faster but not upgrading the loading dock. Eventually the loading dock becomes the constraint and your factory runs at loading dock speed, not assembly line speed.

The Measurement Framework We Use Now

We track productivity in tiers:

Tier 1: Individual Developer Productivity
How fast can one developer complete isolated coding tasks?
AI Impact: Very positive (+30-50%)

Tier 2: Team Delivery Productivity
How fast can a team ship a feature from design to production?
AI Impact: Modest (+5-15%)

Tier 3: Organizational Value Productivity
How fast does the organization deliver business value to customers?
AI Impact: Mixed (quality up, speed flat)

The AI hype focuses on Tier 1. Leaders care about Tier 3. The gap between them is where productivity “vanishes.”

Recommendations for This Community

If you’re trying to understand where your AI productivity gains are going:

1. Stop tracking commits and PRs as productivity metrics
   They measure activity, not outcomes

2. Instrument your entire delivery pipeline
   Measure time and quality at every handoff

3. Track where work is waiting
   Queue time is where productivity dies

4. Measure quality outcomes, not just velocity
   Defect rates, rework rates, customer satisfaction

5. Survey your developers regularly
   Ask where they’re blocked, what’s frustrating, what’s slowing them down

6. Create feedback loops
   Don’t just measure—use the data to identify and fix bottlenecks

The Uncomfortable Insight

After analyzing all this data, here’s my conclusion: AI coding assistants reveal your organizational dysfunction faster than they create productivity.

If your development process is well-designed—good review practices, strong QA, smooth integration, clear requirements—AI will make you meaningfully faster.

If your process is dysfunctional—unclear requirements, weak review practices, manual QA, poor coordination—AI will amplify the dysfunction and create chaos that absorbs the gains.

Keisha, to answer your original question: The productivity isn’t vanishing. It’s getting absorbed by organizational bottlenecks that were always there but are now overwhelmed by increased throughput.

The fix isn’t better AI tools. It’s better organizational infrastructure to handle the increased flow.

Instrument your pipeline. Find your constraints. Fix them systematically.

Or keep measuring vanity metrics and wondering why the numbers look great but nothing feels faster.