The AI Bottleneck Moved to Code Review
AI coding tools solved a visible problem and exposed a quieter one.
The visible problem was typing speed. Boilerplate, tests, refactoring suggestions, small bug fixes, API glue, documentation drafts. A lot of that can now be produced faster. Sometimes much faster.
The quieter problem is that software teams were rarely constrained by typing alone.
They were constrained by unclear requirements, overloaded reviewers, brittle tests, hidden dependencies, long feedback loops, and quality risks that only become visible after integration. AI does not remove those constraints. In many teams, it feeds them.
That is why a Delivery Manager should ask a different question from "How much code did AI help us write?"
Ask: "Can our system verify, integrate, and safely release the extra code?"
Local speed is not system throughput
The current research picture is more useful than the usual argument about whether AI coding tools are good or bad.
Maier and colleagues published a 2026 meta-analysis of 23 studies on generative AI in programming. They found a statistically significant but moderate positive productivity effect (Hedges' g = 0.33, 95% CI [0.09, 0.58]). The important part is the caveat: effects varied strongly by context, and gains were smaller in open-source and enterprise settings than in controlled experiments.
That should not surprise anyone who has watched real delivery systems.
A clean experiment can measure task completion time. A product team has to handle the rest: code review, test reliability, integration risk, security, domain fit, maintainability, deployment, and whether the change should exist at all. AI can accelerate the first part while leaving the expensive parts untouched.
If the team writes code 30 percent faster but review capacity stays flat, the constraint moves. Work piles up in pull requests. Senior engineers spend more time validating generated changes. Defects become harder to spot because the code looks plausible. More small tasks enter the system because starting work feels cheap.
That is not higher throughput. It is extra work-in-process with better autocomplete.
The dashboard may be hiding the problem
The SPACE framework by Forsgren, Storey, Maddila, Zimmermann, Houck, and Butler is useful here because it warns against a common management mistake: reducing developer productivity to activity.
Commits, pull requests, generated lines, accepted suggestions, and code review counts are activity signals. They can be useful. They are also easy to misread.
A rising pull request count may mean the team is flowing. It may also mean people are slicing work poorly, spraying changes across the codebase, or creating more review load than the system can absorb. Faster code generation may mean real productivity. It may also mean the team has moved effort into debugging, test repair, and architectural cleanup.
This matters because AI makes activity cheaper to produce.
When activity gets cheaper, weak measurement gets more dangerous. A dashboard can look healthier while the team feels worse. More output. More review pressure. More context switching. More "almost right" code. Less confidence.
Harness' 2026 State of Engineering Excellence survey is vendor-commissioned, so I would not treat it as causal proof. Still, the pattern is worth noticing. In a survey of 700 engineering practitioners and managers across five countries, 89 percent of leaders reported productivity gains after AI adoption, while 81 percent said developers spend more time in code review. Organizations estimated that about 31 percent of developer time is now invisible work such as reviewing AI-generated code, fixing bugs, and switching tools.
Sonar's 2026 developer survey points in the same direction. The press release reports that most developers surveyed do not fully trust AI-generated code, while fewer than half always check AI-assisted code before committing.
Treat those numbers carefully. Both sources sell into this problem. But as market signals, they match what many delivery leaders are starting to see: the bottleneck has moved from generation to verification.
Review capacity is a flow constraint
Lean thinking is useful here.
In product development flow, adding capacity at a non-bottleneck does not improve throughput. If review is the constraint, faster code generation increases queue length. Longer queues increase delay. Delay increases context loss. Context loss makes review harder. Harder review reduces quality or slows delivery further.
Telling people to "use AI responsibly" in a policy document will not fix this.
You fix it by making the constraint visible and managing it.
Start with review queue age. How long does a pull request wait before the first serious review? Track AI-assisted and non-AI-assisted work separately if you can do that without turning the metric into surveillance.
Then look at PR size. AI makes it easy to create large, polished changes. Large changes are harder to review, harder to test, and easier to rubber-stamp.
Track rework after review. How many AI-assisted changes come back because the first version was incomplete, overbuilt, brittle, insecure, or misunderstood the domain? The interesting measure is how much human correction was needed before the team trusted it.
Watch senior engineer load. If AI makes juniors faster but pushes more validation work onto the few people who understand the system, the team may be borrowing against its scarcest capacity.
Measure escaped defects and production incidents. The real test is not whether AI helped create code. The test is whether the released system behaves better, worse, or the same under load, change, and customer use.
A practical operating rule
Here is the rule I would use with a team:
Do not increase AI-assisted code volume faster than you increase verification capacity.
That means deterministic checks where they make sense: tests, static analysis, security scanning, contract checks, build checks, dependency checks. It also means human review where judgment matters: domain correctness, architecture fit, operational risk, usability, and maintainability.
It means protecting review time as real work, not treating it as an interruption between "productive" coding sessions.
It means separating improvement metrics from individual performance evaluation. If developers believe AI metrics will be used to rank them, they will optimize the signal.
And it means that Delivery Managers need a broader dashboard:
- review queue age;
- time to first review;
- PR size and change scope;
- rework after review;
- test failure patterns;
- escaped defects;
- deployment frequency and change failure;
- developer cognitive load and confidence.
No single metric tells the story. The useful pattern is the tension between them.
The better AI conversation
The weak AI conversation asks whether developers are "more productive" now.
The better conversation is about where the constraint moved.
If AI helps a team draft code faster and the rest of the system can absorb it, good. Use it. Learn from it. Make the boring parts easier.
If AI increases code volume while review, testing, and release confidence degrade, the team has not improved flow. It has created a faster way to produce unverified inventory.
For CTOs and delivery leaders, this is the practical point: AI adoption is not a typing-speed initiative. It is a flow-design problem.
The teams that benefit will be the ones that notice the new bottleneck early, treat review as scarce capacity, and measure the whole loop from idea to production confidence.
Sources
- Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of developer productivity: There's more to it than you think. Queue, 19(1), 20–48. doi.org/10.1145/3454122.3454124
- Harness. (2026, May 13). The state of engineering excellence 2026. harness.io/press-and-news/ai-has-outpaced-how-engineering-organizations-measure-developer-productivity
- Maier, S., Gunzenhäuser, M., Schweisthal, J., Schneider, M., & Feuerriegel, S. (2026). A meta-analysis of the effect of generative AI on productivity and learning in programming [Preprint]. arXiv. arxiv.org/abs/2605.04779
- Sonar. (2026, January 8). Sonar data reveals critical "verification gap" in AI coding [Press release]. sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/