Your team shipped more last quarter than in any previous quarter, but delivery is slower than in the spring. We are pretty sure nobody stopped working. What we feel, though, is that the work has stopped moving and is almost certainly sitting in the review column. Let's see.
Why the bottleneck moved
Start with the cheap side, because it is easy to underrate. GitClear's June 2026 report, The Maintainability Gap, version 2026.6.1, found that about a quarter of the commits it detected in 2026 showed measurable AI assistance. Two caveats travel with that figure: it is year-to-date from a partial sample, so read it as a direction rather than a closed number, and it counts only what GitClear's own tooling can detect, so treat it as a floor.
GitClear, The Maintainability Gap (v2026.6.1, June 2026): AI code quality research
Now the other side. Stack Overflow ran its 2025 Developer Survey in the middle of the year, self-reported, with respondents recruited largely through Stack Overflow's own channels, so read it as what engaged developers say rather than a census. Of the roughly 31,000 people who answered the frustration question, 66% picked output that is almost right but not quite. It was a select-all question, so the options run past a hundred.
That single option is the entire week. Obviously wrong code costs you thirty seconds, because you read it, reject it, and move on. Almost right code costs a careful person the time to read every line and then make a decision. It looks finished, it compiles, the tests pass, and somebody still has to work out whether it does the thing you actually meant.
Forty-five percent of that same group said debugging AI-generated code is more time-consuming. Both of those frustrations sit at review time. Neither of them is writing time, which is the part that got cheap.
Stack Overflow 2025 Developer Survey: AI tool frustrations and accuracy
There is also what happens after the code integrates. GitClear tracks churn, meaning code revised or reverted within two weeks of being written, and its two-week churn sat near 16% in 2023 and 2024, stepped up to about 19% in 2025, and is sitting a shade under that so far in 2026. The 2026 value is partial-year and serves as a leading indicator rather than a closed annual figure, and almost the entire increase is a single step between 2024 and 2025. Their method covers specific repositories in specific languages, so do not read it as true of every team or every stack.
Rework is not a separate problem from review. It arrives on the same desk, in the same week, in front of the same people. This is the flow-economics half of a thread that started with the difference between using AI and delegating to it, and it is the half nobody staffs for.
Review is not a step; it is a queue
Most teams treat review as a step in a workflow, something that happens between writing and merging. It is really not a step. It is a queue, because it holds work still until a person is free to make a decision about it, and queues behave differently from steps.
The best model for this is still Don Reinertsen's 2009 book, The Principles of Product Development Flow. It is a foundational model rather than recent research, and it predates all of this by more than a decade. Three of his principles carry the argument.
The first is the Principle of Invisible Inventory. Product development inventory is invisible, physically and financially. A plant manager walks the floor and sees the pile, while your finance team opens the balance sheet and finds no line item for half-reviewed pull requests. Reinertsen argues that queues are the largest source of economic waste in product development, largely because they have no natural predators, and that this is his organizing argument rather than a measured result.
The second is the Principle of Queueing Capacity Utilization. Queue size does not increase linearly with load. It rises sharply as a system approaches full capacity, so a review step running near full utilization backs up badly even when average capacity looks adequate on paper. Reinertsen derives the arithmetic for a single-server queue; a review queue has several reviewers, so the shape of that result holds here, while the specific numbers do not.
The third is the Principle of Rate-Matching, and it is what the rest of this runs on. Cap the work-in-process between two steps, and you force the average arrival rate into that pool to match the average departure rate from it. Reinertsen takes the idea from data networks, where limiting how many packets can be in flight before an acknowledgment returns forces a fast sender down to the speed the receiver can absorb. Generation is the fast sender, review is the slow receiver, and on most teams nothing is capping the work in flight.
What the research supports, and what it does not
DORA's 2025 research reverses part of what it found the year before, and if you only half remember the 2024 headline, you will carry the wrong version. In 2024, DORA associated AI adoption with lower throughput and worse delivery stability. In 2025, throughput flipped to positive: the speed problem resolved. What did not resolve is instability, which DORA defines as the sum of change failure rate and rework rate, both self-reported.
DORA also says plainly that its own data does not put it in a position to explain why instability did not adapt when three other outcomes did. So the mechanism I am about to offer is mine, not theirs. Instability on its own is not automatically bad, since it can mean a system is deliberately absorbing more risk, and the real question is whether anyone chose that or it's just happening.
The one place DORA states the dynamic directly is in its value stream chapter, which is guidance rather than a measurement. Its example is that a team may discover through mapping that code review is a significant bottleneck, and that the real win is applying AI to improve the review process rather than using AI to generate more code, which would only make that bottleneck worse. That is DORA reaching for review as its example of a constraint. It is not DORA reporting that review is the industry's constraint, and the difference matters.
DORA 2025, State of AI-assisted Software Development (v. 2025.2): research report
Signs your review column is the constraint
You do not need a study to answer this. You need four observations, and all four are visible from a board.
Merged output is up and cycle time is flat or worse. The review column is the only column whose card count nobody quotes in a standup. Approvals cluster around one or two names, which means your real capacity is smaller than your headcount suggests. And rework arrives fast rather than late, showing up as items coming back for a second pass rather than as incidents weeks later.
If three of those are true, stop arguing about tooling and go measure. The rest of this page is how.
The Verification Capacity Planner
One definition first, because the unit is where this goes wrong. An item is one thing that requires one review decision: a pull request, a merge request, a change list, or a ticket, depending on how your team reviews. Never a commit. GitClear's quarter is measured in commits, and a single pull request typically holds many of them, so mixing the two units puts you off by roughly an order of magnitude in the direction that makes your situation look catastrophic.
THE VERIFICATION CAPACITY PLANNER
Size review as a capacity, not as a free step.
An item is one thing that needs one review decision:
a pull request, a merge request, a change list, or
a ticket. Never a commit.
1 AI-ASSISTED ITEMS PER WEEK
Items your team put up for review last week.
______
2 REVIEW-HOURS AVAILABLE PER WEEK
Hours that genuinely go to review. Not headcount
times forty.
______
3 REVIEW TIME PER ITEM
A careful read of one item, in hours.
Forty-five minutes is 0.75.
______
4 SECOND-PASS SHARE
Share of reviews that send an item back, as a
decimal. One in four is 0.25.
______
WORK IT THROUGH
A Reviews per week = line 2 / line 3 ______
B Reviews per item = 1 / (1 - line 4) ______
C CEILING, items/wk = A / B ______
D Where you sit = line 1 / C ______
READ LINE D
under 0.7 you have headroom
0.7 to 0.9 watch it. Queue growth is sharply
nonlinear near full capacity
0.9 to 1.0 you are at the ceiling
over 1.0 you are past it, and the surplus
is accumulating in a column
SET THE LIMIT
Cap AI-assisted items entering review each week.
Start the cap at line C, not below it.
The cap goes upstream of review, never on review.
A cap costs something: it turns away work that
might have been valuable and leaves some
capacity idle. Reinertsen argues a light limit
is worth that trade and a tight one is not.
WHAT THIS WILL NOT DO
It will not predict how long your queue will be,
or how long an item will wait. Classic queueing
math assumes a single server, and your review
queue has several reviewers.
DONE WHEN
You can say line 1 and line C out loud without
opening anything, and the cap is written down
where work enters review.Here is the shape, with invented numbers. Use yours, not mine.
WORKED EXAMPLE, illustrative numbers only Three qualified reviewers. Not everyone with merge rights: the people whose approval you would want on a change that touches money. Each has six hours a week that genuinely goes to review. Not a full week. Six hours. They have their own work. 1 AI-assisted items per week ............ 60 2 Review-hours available per week ....... 18 3 Review time per item (45 min) ......... 0.75 4 Second-pass share (one in four) ....... 0.25 A Reviews per week = 18 / 0.75 ......... 24 B Reviews per item = 1 / 0.75 .......... 1.33 C CEILING, items/wk = 24 / 1.33 ......... 18 D Where you sit = 60 / 18 ........... 3.3 This team can verify about eighteen items a week without cutting corners, and it is putting up sixty. That is more than three times its ceiling. The difference does not evaporate. It accumulates in a column. The cap: eighteen AI-assisted items entering review per week, held upstream, until line C moves.
If you would rather reach eighteen a different way, three-quarters of twenty-four reviews end in an approval, and each approval clears one item, which arrives on eighteen too. Two ways in, same answer. Nineteen is also a defensible reading, and it is the optimistic one, because it assumes every rejected item clears on its second pass and that rework never recurs. In my experience, rework recurs and recurs and recurs, and a ceiling meant to set a limit should be a cue to exercise caution.
Where the limit goes
The obvious move here is the wrong one. Reinertsen's Principle of the Critical Queue says to put the limit where the queue is most expensive, not where it is easiest to measure. The expensive queue is finished work sitting still, waiting on a reviewer, which means the limit does not go on review. It goes upstream, on how much you let into the pipe.
You cap generation to protect verification. That felt backward to me the first time I said it out loud, and it is the same logic as placing a task on the delegation ladder by risk rather than by enthusiasm. The limit has a real cost, and Reinertsen is honest about it: a cap permanently turns away work that might have been valuable and lowers capacity utilization. He argues a light limit is worth that trade and a tight one is not, so setting it aggressively will cost you more than it saves.
Try this next week
Count two numbers. What your team generated, and what your team can actually review. Then fill in the four lines above and read line D aloud in front of the people whose approval is the constraint.
If line D is above one, you do not have a productivity story. You have a queue, and the fix is a cap on intake rather than pressure on reviewers. If line D is below one and your review column still feels heavy, the load is per item rather than per unit of volume, and that is a different fix: shrink what a reviewer has to hold in mind. Smaller items, clearer intent, and reviewers who know the AI code anti-patterns worth recognizing on sight.
One caution on the cap. A limit on intake changes who decides what enters review, which is a decision that needs a name on it, the same way every shipped AI change needs a named human accountable. A cap with no owner is a suggestion.
Cheap generation does not give you free verification, yet. I say "yet" on purpose, in this and in most change efforts, because the constraint is real today and it is not permanent. Something will change soon enough to remove this bottleneck and present another :)