Every engineer on your team feels more productive with AI. More PRs, faster first drafts, quicker prototypes. The individual numbers look great.

So why does it feel like the team is moving slower, not faster?

The bottleneck moved

Everyone reports they’re faster. And they genuinely are … at their part of the work. But somehow, delivery keeps slipping. Features take longer to land.

The last post covered the individual-level version of this: developers feeling 24% faster while measurably shipping 19% slower. Now stack that effect across a whole team. The math gets ugly fast.

If every developer on your team suddenly produces three times as much code, what happens next? Three times as much code needs to be reviewed. Three times as many integration points need to be tested. Three times as many deployment decisions need to be made. The parts of the process that were never designed for this volume are now buckling under it. GitHub built their platform to handle 10x growth and got hit with 30x. If they couldn’t absorb the throughput increase, what makes you think your team’s review process can?

Coding speed was never the real constraint

Writing code felt like the slowest step, so we optimized it. But coding was always a minority of an engineer’s time. The rest (requirements clarity, review, testing, security, deployment) was where the real constraints lived. We just couldn’t see them clearly when code generation was the obvious bottleneck.

AI sped up the one step that felt slowest. The rest of the pipeline didn’t change. Now those surrounding steps are the obvious bottleneck. And the perception gap makes it worse: because everyone feels faster, teams tighten deadlines and fill backlogs with more work, planning as if generation speed is delivery speed. It isn’t.

Code review is where it hits first

When the volume of generated code overwhelms your review capacity, reviewers start rubber-stamping. Not because they’re lazy, but because it’s unmanageable. And that’s exactly the moment quality silently degrades.

The cracks are already showing in the open: maintainers report only 1 in 10 AI-generated PRs meets basic standards, Ghostty now bans contributors who submit AI slop they don’t understand, and GitHub has shipped settings letting maintainers disable pull requests entirely because they can’t keep up. If projects whose entire model is review-by-strangers can’t absorb the volume, the same dynamic is coming for internal teams. Just less visibly.

Code review was never primarily about catching bugs. It’s how teams transfer thinking, how you build shared knowledge of how the system behaves and why decisions were made. When changes balloon from 50 lines to hundreds, reviewers stop tracing logic and start scanning. The gate that was supposed to ensure quality becomes a throughput problem, and the shared understanding that made your team function as a team quietly disappears.

And the team you used to have, the one where reviewers caught each other’s blind spots and a PR thread was where junior engineers learned how the system actually worked, quietly stops being that team. Nobody calls a meeting about it. It just erodes.

Cheap to build isn’t cheap to own

When building is cheap, the temptation is to skip the hard work of figuring out what to build. “Let’s just try it and see” works great for prototypes. At scale, it’s waterfall thinking in agile clothing. Instead of a six-month planning phase ending in a big bang release, you get daily big bangs nobody has time to evaluate. Every experiment becomes a permanent maintenance commitment. Every “let’s try it” becomes someone’s on-call burden. The inspect-and-adapt loop that was supposed to keep you honest breaks down when nothing ever gets retired.

Stop optimizing the fast part

Most teams are still pouring investment into making generation faster: better prompts, more agents, faster models. Everything around it gets starved.

It’s like widening a highway on-ramp while the highway itself is a single lane.

The fix isn’t more throughput on the part that’s already fast. It’s reshaping the team around the parts that aren’t. The how is a longer conversation. The first step is recognizing where the constraint actually lives now.

The question to ask

If your team feels like it’s spinning faster but going nowhere, stop asking “how do we generate more?” and start asking “what’s blocking us from shipping what we already generated?”

The answer is almost never “more code.” It’s review capacity, integration testing, deployment confidence, requirements clarity. The work that was always there, just hidden behind the slowness of typing. Now that typing is fast, those costs are visible. Pretending they aren’t is how teams end up spinning faster every quarter and shipping less every year.

References

• The 84% Problem — Architect To CTO
• Code Review Is Dying — Chris Parsons
• Comprehension Debt - the hidden cost of AI generated code — Addy Osmani