What Rate-Limits Two Sessions
In one line: §5.8's read-reach is real, but the throughput case is refuted, not merely unproven — and the thing that actually limits two sessions is neither review nor CI, it is how many open pull requests one session can hold in working memory.
The measurement. Sixty pull requests merged over three days on the flagship project:
| Stage | Median | Share of PR life |
|---|---|---|
| open → first bot review | 8 min | — |
| open → last review round | 9 min | 6% |
| CI critical path | 15 min | overlaps review |
| last review → merge (idle) | 63 min | 62% |
| open → merged | 101 min | 100% |
Security ran 10 minutes, process gates under one. The reviewer answers in eight minutes and 15% of pull requests merge with no review at all. Review and CI together occupy about a quarter of a pull request's life. The dominant term is the idle tail: work that is reviewed, green and mergeable, sitting untouched until a session comes back to it.
At peak the project held 15 pull requests open simultaneously and sustained ~0.9 merges/hour. Adding a second session raised the number of things in flight without proportionally raising the rate they left the pipe, because the binding resource is attention, not compute.
The constraint is context-switching between simultaneously-open pull requests. Not coding, not the reviewer, not CI.
The throughput case is refuted on its own evidence. The peak day — 35 merges — predates the second session's existence. Whatever produced that burst, it was not concurrency. What justifies §5.8 is a severity asymmetry, not a rate: the benefits are unrecoverable harms avoided, the costs are recoverable hours. Say that plainly when proposing the pattern, because a team told "two sessions go faster" has been mispriced twice — once on effort (§5.8) and once on rate.
Complement on reading, collide on writing. Every catch that mattered came from one session re-deriving what the other had convinced itself of. Every collision came from both writing: two stale-base near-misses, one squash-merge that broke a stacked pull request, one wasted work-block. The split is clean enough to be a rule:
- one session owns mainline and performs merges;
- the other reads, challenges, and never holds a base another session stacks on.
Peer agreement carries no evidential weight. Measured: of three false claims corrected over the period, two had already been "confirmed" by the second session. The challenge is what pays; the concurrence is worth nothing, and a second session that agrees has told you only that it read the same way. §5.8's rule that disagreement is settled by counter-measurement has a mirror — agreement settles nothing at all.
Starvation is a property of the sequence, not of the pull request. The merge gate is a per-PR rule, correctly applied one PR at a time by both sessions, and neither asked what its own merge did to the other's in-flight run. Measured on one afternoon: mainline moved twice in forty minutes while a pull request with zero open findings and 19 of 20 checks green sat blocked on CI predates current mainline; three re-run cycles gained nothing, because a 15-minute CI run cannot survive a mainline that moves every 20–35 minutes. The re-run was the correct lever — merging mainline in would have reset the review-at-head — so the right move also could not win the race.
The remedy is a convention, not a mechanism, and it costs the yielding session nothing:
- do not merge within ~20 minutes of another session pushing an otherwise-green head;
- when both want mainline, whoever is closer to done goes first — fewest open findings, then fewest checks outstanding.
And the input nobody measured. Four independent analyses, each adversarially challenged, all built on one unquantified premise handed to them — "the deployed build is behind mainline" — and none asked for the number. It was seven commits, not the seventy-nine pull requests the framing implied, which turned a frightening decision into a twenty-minute one. The adversarial pass challenged reasoning and never inputs.
A quantity asserted without a number is an input nobody has measured. Adversarial review must include one pass over the premises, not only the argument built on them.
This is the same failure as a diagnosis carrying an unmeasured blast radius (§7.7), one level up: the fact everybody accepts is the one nobody measures, and consensus is where it hides.
How — four rules:
- Bound simultaneously-open pull requests. The idle tail is the price of exceeding what one session can hold; finish what is open before opening more.
- Split roles, not work — one session owns mainline, the other never holds a base another stacks on.
- Treat peer agreement as zero evidence. Only a counter-measurement moves a claim.
- Adversarially review the premises, not only the reasoning — every unquantified quantity is an unmeasured input.
Declared gaps:
- The idle tail is measured, its cause is inferred. 62% of PR life is idle and the correlation with open-PR count is strong, but no experiment held one variable fixed. A team that bounds work-in-progress and sees no change should report that rather than assume the figure travels.
- One project, three days. Same caution as §5.8: these are not months of data and must not be quoted as if they were.