We're coding 4 hours faster per week, but shipping no faster. What's broken?

General
1

Six months ago, our engineering team adopted AI coding assistants across the board. GitHub Copilot for most folks, a few trying Cursor and Codeium. The feedback from developers has been overwhelmingly positive—they feel faster, more productive, less bogged down by boilerplate.

But here’s what’s keeping me up at night: Our delivery metrics haven’t changed. At all.

The Math That Doesn’t Add Up

Recent research shows developers save 3.6 to 5.4 hours per week using AI coding tools. That’s substantial—nearly a full workday. If coding time dropped by that much, you’d expect to see our sprint velocity jump, cycle time shrink, and features shipping faster.

Instead? Our average cycle time is still hovering around 7 days. Our velocity is flat. And when I dig into the data, I see why: coding is only 43% of our cycle time.

The other 57%? That’s pull request reviews, QA testing, integration checks, and deployment. And here’s the kicker—while our developers are writing code faster, our PR review time has increased by nearly 90%.

The Bottleneck Just Moved

We didn’t eliminate friction; we just shifted it downstream. Now we have:

  • Junior developers producing more code than ever before, but senior engineers are drowning in review requests
  • AI-generated code that’s harder to review because it looks correct but can have subtle bugs, incomplete error handling, or security issues (research shows 48% of AI-generated code has vulnerabilities)
  • Security and QA teams that can’t keep pace with the volume of changes
  • Integration and testing phases that have become the new constraint

I greenlit a significant investment in these AI tools thinking we’d see measurable delivery improvements. Our developers are happier, which matters. But from a business perspective, we’re not shipping faster.

What Are We Missing?

I can’t be the only leader facing this. If you’ve adopted AI coding assistants, what have you done to address the downstream bottlenecks?

Have you:

  • Changed your code review process?
  • Restructured teams to handle increased volume?
  • Invested in different tooling for the review/QA/security phases?
  • Measured where your actual bottleneck is now?

I’d love to hear what’s worked—or what hasn’t. Because right now, I’m sitting on happy developers and flat delivery metrics, and I need to figure out where to invest next.

Sources:

2

Keisha, this resonates deeply. We experienced this exact problem at our company about 18 months ago, and you’ve diagnosed it perfectly: This is an organizational design problem, not a tooling problem.

When we rolled out AI coding assistants, we saw the same pattern—developers loved them, individual productivity metrics looked great, but organizational velocity stayed flat. The bottleneck had migrated downstream to code review, and our senior engineers were becoming the constraint.

What We Did

Here’s what actually moved the needle for us:

1. AI-Powered Code Review Assistants
We invested in tools like CodeRabbit and GitHub’s AI review features to help reviewers keep pace. These don’t replace human judgment, but they catch the obvious stuff (style issues, simple bugs, security patterns) so reviewers can focus on architecture and business logic.

2. Review Pods Instead of Individual Bottlenecks
We restructured from individual code ownership to “review pods”—small groups (3-4 engineers) with shared review responsibility. If one person is swamped, others in the pod can pick up reviews. This eliminated the “waiting for Sarah to come back from vacation” problem.

3. Shift-Left Security
We implemented automated security scanning earlier in the workflow—pre-commit hooks and CI checks that catch vulnerabilities before code even reaches human review. Our security team now focuses on architectural reviews rather than line-by-line audits.

4. New Metrics, New Focus
We started measuring review queue depth, time-in-review, and reviewer load as first-class metrics alongside velocity. What you measure is what you optimize for. Once we made the bottleneck visible, we could address it systematically.

5. Integration Engineers
We created a dedicated role: integration engineers who focus specifically on the testing and deployment phases. They’re not building features; they’re ensuring features flow smoothly through the pipeline.

Results

It took about three months, but we saw review time drop by 35% and our actual delivery velocity improve by 20%. The key insight: You can’t solve systemic bottlenecks with more of the same tools that created them.

The Question You Should Be Asking

Here’s what I’d challenge you and others to consider: Are you measuring where your bottleneck actually is right now, or are you still assuming it’s in the coding phase?

Most teams haven’t instrumented their delivery pipeline to see where time is actually spent. Once you have that visibility, the investments become obvious. But without it, you’re just guessing.

3

Keisha and Michelle, you’re both hitting on something that keeps me up at night too, but from a different angle: the long-term talent development implications.

I’m seeing junior engineers in our organization who are learning to code WITH AI from day one. They’ve never had to struggle through writing a loop without autocomplete, never had to debug a memory leak without suggested fixes, never had to architect an error handling strategy from first principles.

And this directly compounds the review bottleneck you’re describing.

The Code Looks Right, But…

Here’s a pattern I’m seeing multiple times a week: A junior developer submits a PR. The code is syntactically correct, follows our style guide, has tests. AI helped them write it quickly. But when I dig deeper in review, the architectural understanding isn’t there.

A recent example from our payment processing system: AI-generated error handling that looked perfect—try/catch blocks, proper logging, clean structure. But it failed catastrophically when we hit a specific race condition with concurrent transactions. The code handled the expected errors beautifully but had no concept of the unexpected ones.

In financial services, we can’t afford these subtle gaps. A bug in account management or payment processing doesn’t just impact user experience—it impacts trust, compliance, and potentially millions of dollars.

What We’re Trying

I’ll be honest: we’re still figuring this out. But here’s what we’re experimenting with:

1. Pair Programming with Intent
We pair AI-assisted junior developers with senior mentors. This slows down initial coding (which feels counterintuitive after investing in speed tools), but it dramatically improves what reaches review. The senior engineer can spot the architectural gaps in real-time.

2. “AI-Free” Learning Modules
For the first three months of onboarding, new junior engineers work without AI assistance on specific learning projects. They need to build the muscle memory and problem-solving instincts. Once they have that foundation, then AI becomes a multiplier rather than a crutch.

3. AI-Specific Review Checklists
We created review checklists specifically for AI-generated patterns:

  • Are null/undefined cases actually handled, or just caught generically?
  • Does error handling account for failure modes beyond “request failed”?
  • Are security validations comprehensive or just following common patterns?
  • Is there evidence of system-level thinking vs function-level solutions?

4. Valuing Mentorship Time
We’ve made mentorship a measured and valued part of senior engineer performance reviews. It’s not “overhead” anymore; it’s core to the role. This gives our senior engineers the space to invest in junior development even when it slows velocity.

The Uncomfortable Question

Here’s what I keep asking myself: Are we optimizing for short-term velocity at the cost of long-term team capability?

The business pressure is real. Leadership wants features shipped faster. But if we’re creating a generation of developers who can’t function without AI assistance, what happens when they need to debug complex production issues? What happens when they need to make architectural decisions?

I don’t have great answers yet. But I do think this is a cultural challenge as much as a technical one. We can’t just throw more AI at the review bottleneck without also thinking about how we’re developing the next generation of senior engineers.

Curious About Others’ Experiences

For those of you with junior developers on your teams:

  • How are you balancing AI assistance with fundamental skill development?
  • Have you seen this impact code review burden?
  • What does “senior engineer” even mean in a world where AI can generate most implementation code?

I’d love to hear how others are navigating this, especially if you’ve found approaches that work.

4

This is a fantastic thread, and I want to add a perspective from the product side that might be uncomfortable: The bottleneck has always been clarity, not speed.

Michelle, Luis, Keisha—you’re all diagnosing real problems with code review capacity and talent development. But I’d argue there’s an even earlier bottleneck that AI coding tools are actually making worse: requirements clarity and alignment.

We Shipped The Wrong Thing, Faster

Here’s a story from two months ago that still makes me cringe. We had a feature request from enterprise customers. Our engineering team, excited to try out their new AI tools, built and shipped it in about half the normal time. Everyone was proud. Velocity metrics looked great.

Except we built the wrong feature.

The engineers interpreted the requirements one way, AI helped them implement that interpretation quickly, and we shipped something that technically met the spec but completely missed the customer’s actual need. We had to rip it out and start over. All that speed? Wasted.

Faster Coding Without Better Requirements = Faster Garbage Production

Here’s the thing: AI coding assistants make it easy to jump straight into implementation. Too easy. The cognitive friction of “I have to write all this code” used to force a moment of pause: “Am I sure this is right? Do I understand what we’re building and why?”

Now that friction is gone. Developers can spin up features so quickly that there’s a temptation to code first, think later. And that compounds every downstream bottleneck you’ve mentioned:

  • More PRs to review (many of which shouldn’t have been written)
  • More edge cases discovered in QA (because requirements weren’t fully thought through)
  • More rework cycles (because the first implementation missed the mark)

What We’re Trying: Pre-Flight Checklists

We’ve implemented what we call “pre-flight checklists” that must be completed before any code is written:

1. Clear Acceptance Criteria
Not just “add a filter to the dashboard.” Specific, testable criteria: “User can filter transactions by date range, amount, and status. Filters persist across sessions. Default is last 30 days.”

2. Design Review Completed
Actual mockups or prototypes reviewed by PM, designer, and at least one engineer. Not just Slack screenshots—real collaborative review.

3. Edge Cases Documented
What happens when there’s no data? What if the API fails? What about mobile vs desktop? Write these down before writing code.

4. Success Metrics Defined
How will we know this works? What are we measuring? How will we validate that we solved the customer problem?

The Results Are Humbling

When we enforce this checklist, features still get built quickly (AI helps), but with far fewer iterations. We have:

  • 40% fewer PRs that need major revisions
  • 30% less rework after QA
  • Measurably better alignment between what we ship and what customers actually needed

But here’s the uncomfortable part: It doesn’t feel faster. The total time from “idea” to “shipped” is about the same. We just moved the thinking time from after coding (rework) to before coding (planning).

The Challenge to This Group

Everyone in this thread is focused on optimizing the post-coding phases: review, QA, deployment. Those are real problems. But I’d challenge you to ask:

Are you measuring cycle time from “idea articulated” to “value delivered,” or just from “code written” to “code deployed”?

If you’re only measuring the coding-to-deploy phase, you’re missing the biggest source of waste: building the wrong thing, building it well, and having to start over.

AI makes us faster at implementation. It doesn’t make us better at understanding what to build or why. And if we’re not careful, that speed just means we fail faster without learning faster.

A Question for the Engineers

For those of you who’ve adopted AI coding tools: Have you noticed a change in how much time your team spends on requirements clarification, design review, and alignment before coding starts?

I’m genuinely curious whether this is a product-specific observation or if others are seeing the same pattern.

5

Okay, this thread is hitting SO close to home from a design perspective. David, your point about requirements clarity is giving me flashbacks to last month.

The Design-Engineering Handoff Is Getting Worse, Not Better

Here’s what I’m seeing: Developers can now implement designs faster than ever with AI assistance. That sounds great, right? Except the design → engineering translation is still slow, error-prone, and full of miscommunication.

Real example from three weeks ago:

I spec’d a feature with detailed Figma files—interaction states, edge cases, responsive behavior, the whole thing. An engineer picked it up, used AI to build it quickly, and shipped what looked like the design.

Except they completely misunderstood the interaction intent. The visual was right, but the user experience was wrong. The component looked like my design but behaved differently. We ended up with more rework cycles than before we had AI tools.

AI Helps With Implementation, Not Communication

This is the thing that nobody talks about: AI coding assistants are amazing at code generation, but they can’t fix gaps in shared understanding.

When an engineer doesn’t fully grasp the design intent—why a button is placed there, what the user is trying to accomplish, how edge cases should feel—AI just helps them build the wrong thing faster.

And honestly? I think the speed makes it worse. Before, the friction of writing code gave time for questions: “Hey Maya, what should happen when this list is empty?” Now it’s easier to just let AI fill in the gap with a reasonable-looking solution that might not match what users actually need.

What’s Helped (Even Though It’s Still Hard)

We’ve tried a few things to reduce this friction:

1. Design-Engineering Pair Sessions
Before any coding starts, we do a 30-minute session where I walk through the design with the engineer who’ll build it. Not a handoff meeting—an actual conversation about intent, edge cases, and interaction patterns.

It feels like overhead. But it saves hours of rework later when the AI-generated code doesn’t match what users need.

2. Shared Component Library
We maintain a shared library between Figma and our codebase. When I use a Button component in designs, it maps directly to the Button component in code. This reduces interpretation gaps and makes AI suggestions more aligned with our actual patterns.

3. “Definition of Ready” Checklist
No ticket enters engineering unless:

  • All interaction states are designed (hover, active, disabled, error, loading, empty)
  • Responsive behavior is documented
  • Edge cases have design solutions (not just “TBD”)
  • At least one engineer has reviewed and asked questions

4. Engineers in User Research
We started inviting engineers to user research sessions. When they see users struggle with something, they build with more empathy. AI can generate code, but it can’t give you context about why a feature matters.

The Honest Truth

Even with all these process improvements, we’re still seeing friction. Human collaboration is just hard, and you can’t automate it away.

What this thread is reminding me: Tool adoption without intentional process change just creates new problems in new places.

We got faster at coding, so the bottleneck moved to code review. We might get faster at code review, and then the bottleneck will be deployment, or QA, or customer validation. Or, like David is pointing out, we’ll realize the real bottleneck was always clarity and alignment, and we just built the wrong thing really efficiently.

A Question for the Group

Has anyone found good ways to use AI specifically for the design-engineering handoff?

Like, are there tools that help with:

  • Translating design intent into implementation guidance?
  • Catching misalignments between design and code?
  • Making it easier for engineers to ask questions about design decisions?

Or is this just forever a human problem that requires actual conversation and collaboration?

Because honestly, I’m starting to think the most valuable thing we can do isn’t adopt more AI tools—it’s invest in better communication practices between people who build different parts of the product.