Twelve demo changes go through two review processes with the same arrival times. Lane B writes code at the same speed as lane A and finishes 5.5 s sooner, because it sends each finished change somewhere else.
Finding: the same twelve changes finish 5.5 s apart
Both lanes receive every change at the same moment. Lane A sends each one to a single reviewer. Lane B sends routine changes to automated checks and only the rest to the reviewer.
Figure 1
Same changes, two review processes
Demonstration data. Concept, not measurement.
- 01 · Same changes, two lanes
Demo: twelve changes become ready for review, one every 0.9 s. Both lanes receive every change at the same moment.
- 02 · Lane A's line grows
One reviewer needs 1.4 s per change while a new one arrives every 0.9 s, so lane A's line grows. Lane B sends routine changes to 0.35 s checks and never builds a line.
- 03 · Arrivals stop
The last change arrives at 10.5 s. From here both lines can only shrink: that is the end of the inflow, not the policy. Lane B finishes at 11.9 s.
- 04 · Lane A drains last
Lane A is done at 17.4 s. Same changes, same arrival times: the 5.5 s difference comes from the review process.
Mechanism: one reviewer, a new change every 0.9 s
A reviewer decides whether a change is safe to ship. In lane A that reviewer needs 1.4 s for each change, and a new change arrives every 0.9 s, so the line grows for as long as changes keep arriving. A faster agent makes them arrive sooner and changes nothing else.
If your team opens more pull requests each week and merges the same number, you are looking at lane A over days instead of seconds.
What changes when the arrivals stop?
Evidence: the gap comes from the process
The last change arrives at 10.5 s. From then on both lines can only shrink, with or without a policy, because nothing new comes in. Do not credit that drop to any process; the figure gives it a step of its own.
Lane B finishes at 11.9 s and lane A at 17.4 s. Inflow is identical in both lanes, so the review process accounts for the whole 5.5 s.
How do you find lane B on your team?
What to do: split the review wait by change type
Your code host already records three timestamps for every change. The gap between the last two is the wait.
| Timestamp | What it marks |
|---|---|
| Opened | The author created the change |
| Review requested | The change joined the queue |
| Merged | A reviewer or a policy let it through |
Split the wait by change type before you change anything. If one or two types make up most of it and a policy can decide them, you have found lane B. If every change needs judgement, add reviewers.
Questions
Drafted with AI assistance; reported, checked and edited by Sample Author.
Keep reading
People-led AI combines employee leadership with shared direction
People closest to the work lead improvements, supported by shared priorities, connected tools and governance.
The 4D Framework, drawn on one migration ticket
Delegation, Description, Discernment and Diligence, one at a time, on a single database migration that goes from "should an agent touch this?" to a signed change.