Home → Leadership

The Bottleneck Is Review, Not Writing: Team Speed After AI

End-of-quarter meeting. I shared my screen: PRs opened had gone from 19 to 34 a week. A satisfied silence in the room. The second slide showed delivered work: almost unchanged. The third showed why: waiting time in the review queue had gone from 0.9 days to 2.5. We were writing faster and delivering at the same rate. The difference was waiting on somebody’s screen.

Sertaç Yıldırım · 22 September 2026, 15:00 · 12 min read

Why did we not get faster?

The answer is systems thinking: speeding up one station does not speed up the line, it moves the bottleneck. We doubled the writing step; everything after it stayed the same.

The table is clear: we gained 1.3 days in writing and lost 1.6 days in review. And nobody did anything wrong; everyone produced more. The system could not turn more output into delivery.

Change the measurement

The first thing I did was change the slide. PR counts, line counts and closed tickets are no longer discussed in the team; all three rise with AI and none of them produces a decision.

When the metric changed, the conversation changed. “Who wrote how much” took nobody anywhere; “where is the work waiting” has an answer in a table and can be fixed. The old rule from measuring performance holds here too: the thing that is easy to count is not the thing worth measuring.

Four changes

1. A limit on open PRs

At most 2 open PRs per person. Before opening a third you have to close one — which usually means “go and review somebody else’s PR”. The rule sounds bureaucratic; the effect showed in the first week: open PRs fell from 23 to 11 and waiting time from 2.5 days to 1.1. No new code was written; existing code was delivered.

2. PR size: 400 lines

A bot comments automatically on PRs over 400 lines: “can this be split?” Not a ban, a question. The difference we measured is convincing:

Look at the third column: as PRs get bigger, the number of comments falls. That does not mean review improved; it means review was abandoned. Nobody reads 1,400 lines line by line; approval happens at “it seems to work” level, and the rollback rate triples.

AI is part of the fix here too: splitting a large change into three used to be tedious manual work. There is no excuse left.

3. The “why” is mandatory

AI-written code opens a new gap: sometimes the person who wrote it does not know why it is that way. “It suggested this and it worked.” The reviewer does not know either. Two people approve code whose reasoning neither of them knows.

We added three lines to the PR template:

• What was tried and what did not work? (One sentence is enough.)
• Where is the risk in this change? In the author’s own words.
• Which test did you try to break? Break the code on purpose and watch the test go red.

The third one turned out to be the most useful. AI writes tests too, and whether those tests actually check anything is a separate question. Breaking the code on purpose and seeing the test fail takes 2 minutes; in the first month we found 6 tests that checked nothing this way.

4. Review goes in the calendar

“I will look when I get a moment” is the best-intentioned form of postponing; nobody gets a moment. There is now a block in the calendar from 09:30 to 10:15: review. No meetings allowed. Not until the queue is drained — every day.

Its effect on the team was bigger than I expected: once review stopped being something squeezed between tasks, its quality rose too. Comments per PR went from 3.2 to 5.1 and the rollback rate from 6% to 2%.

From the field: six weeks

The first row is deliberate: PR count fell, and that is not a failure. Delivered work went up, because work in progress went down. The sentence I used with the team was: “We will start less and finish more.”

What is the manager’s job here?

Three things, none of them popular:

• Move capacity. Giving time to review and testing means taking it from feature work. You are the one who has to defend that; the team cannot.
• Take output metrics off the agenda. If you report upward, you have to change it there too, otherwise the team works against two different measures. This is exactly where managing up earns its keep.
• Protect the junior’s learning path. When output rises, the person who suffers most is the one still learning: the code arrives finished, the review queue is long, and the space for questions shrinks. The subject of AI or leadership becomes concrete here: pairing, explaining, and deliberately slowing down.

What to watch

• Lead time (p50 / p85). Not one number but a distribution; where is the long tail?
• Waiting in review. From PR opened to first comment.
• Open PRs at once. Work in progress; if it rises, starting is rising, not delivery.
• PR size distribution. The share above 400 lines.
• Comments per PR. Falling means review is being abandoned.
• Rollback rate in production. The most honest number about quality.
• Distribution of review load. If one person does half the reviews, that person is the next bottleneck.

Checklist

Conclusion

The first slide I showed in that meeting was the wrong slide. 34 PRs was a nice number and it said nothing; the number that said something was that delivered work had not changed. The team was producing more and the system was delivering at the same rate; the difference was sitting on someone’s screen, piling up.

Nothing we did over those six weeks was new: WIP limits, small batches, time set aside for review, the right metric. The only new thing is that writing is no longer the bottleneck. That is why managing a team after AI is not an “AI topic” but an old flow problem — the bottleneck simply moved one step down the line.

The sentence to remember: start less, finish more. If output got cheap, output is not what is valuable; delivery is.