We Tripled Code Output. Delivery Speed Didn't Budge.

A client's engineering team adopted AI coding tools across the board. Individual velocity soared. But their DORA metrics flatlined — and the reasons had nothing to do with the tools themselves.

The engineering director was genuinely proud, and I don't blame her. In six months, her team of fourteen had gone from writing around 40 pull requests a week to over 120. First-draft code was flying out. Developers reported feeling more productive than ever. The AI rollout — Copilot for autocomplete, Claude Code for larger tasks, a custom agent for boilerplate generation — had been textbook.

She brought me in because something didn't add up. Despite all that output, the team's delivery cadence was roughly the same as a year ago. Features were still taking three to four weeks from spec to production. The sprint burndown charts looked almost identical. How could they be writing three times more code and shipping at the same pace?

The pipeline didn't care about your typing speed

I spent the first week instrumenting their workflow. Not the code — the process. I sat in on standups, pulled timestamps from their project management tool, traced a dozen features from ticket creation through production deploy, and built a simple breakdown of where time actually went.

Here's what I found. Before the AI rollout, writing code had consumed roughly 35% of a feature's lifecycle. Design and planning took 15%. Code review, 20%. Testing and QA, 15%. Deployment and verification, 15%. Fairly typical for a team this size.

After the AI rollout, writing code had dropped to about 12% of the lifecycle. That was the win, and it was real. But every other phase had expanded to fill the gap.

The green compression in "Write Code" was swallowed entirely by the red expansion downstream. Three bottlenecks had quietly emerged.

Bottleneck one: the review queue

This one I've written about before, but it was stark here. The team had the same five senior engineers doing code reviews. They'd gone from reviewing 40 PRs a week to 120. Each PR was slightly larger on average because AI tools tend to generate generous implementations. The review queue had ballooned from a day or two to nearly a week.

Worse, the reviews were taking longer per PR. AI-generated code is syntactically correct but often subtly wrong in ways that require more careful reading. Two of the senior reviewers told me they'd started doing more manual testing of PRs before approving, because they'd been burned by AI code that passed linting and type checks but broke edge cases in production.

Bottleneck two: test failures tripled

The team had a solid test suite — around 2,800 tests, mostly integration and unit. Before the AI rollout, CI was red about 8% of the time. After, it was red 23% of the time. Not because the test suite got worse, but because the AI-generated code was failing tests more often.

This makes sense when you think about it. AI tools generate code that compiles and looks right. But they don't have access to the team's domain-specific invariants — the business rule that says a refund can't exceed the original charge minus already-refunded amounts, or the constraint that user IDs in the legacy system are always even numbers. These are the kinds of things that live in test suites, not in type signatures.

Each red CI run meant a round-trip: developer reviews the failure, prompts the AI tool to fix it, waits for CI again. Sometimes two or three cycles. The wall-clock time added up fast.

Bottleneck three: integration conflicts

More code generated in parallel by more developers meant more merge conflicts and more integration issues caught late. The team's microservice boundaries were already a bit fuzzy — three services shared a common internal API contract that wasn't formally versioned. When two developers independently asked their AI tools to extend the same API, the results diverged. Both implementations worked in isolation. Neither worked together.

This happened four times in the month before I arrived. Each time it took a day or two to untangle.

What we actually changed

The fix wasn't "use less AI." The tools were genuinely saving time in the coding phase. The fix was treating the downstream pipeline as a first-class engineering problem.

We restructured code review. Instead of five seniors reviewing everything, we implemented a tiered system. AI-generated PRs got an automated first pass — a static analysis step that checked for common AI patterns like unused imports, overly broad error catches, and duplicated logic. Only PRs that passed the automated check went to human review. That cut the human review load by about 40%.

We invested in test scaffolding. For the most common types of AI-generated code (new API endpoints, data transformations), we built test templates that developers ran before pushing. It wasn't bulletproof, but it caught the obvious domain-logic misses early.

We tightened the API contracts. The shared internal APIs got OpenAPI specs with generated clients. If your AI tool generated a call that didn't match the spec, it failed at compile time, not at integration.

The productivity paradox is a pipeline problem

GitLab's latest report put a number on this: 78% of developers say they code faster with AI, but organizational delivery velocity hasn't kept pace. That matches every engagement I've seen this year. The coding phase was never the only bottleneck, and in most teams it wasn't even the primary one.

Speeding up one stage of a pipeline doesn't speed up the pipeline. It just moves the constraint. Anyone who's read The Goal knows this, but somehow we keep relearning it every time a new tool makes one phase dramatically faster.

If your team adopted AI tools and you're wondering why you're not shipping faster, stop looking at the tools. Look at what happens after the code is written. That's where your weeks are going.