I wanted the factory to go faster, and I assumed I knew how: more agents, more parallelism, stations spawning workers to run things at once. Before building that, I measured what was actually slow. The measurement said the opposite.

The median isn’t the problem

Across 150 merged pull requests in the product repo:

Task filed → picked up by a station	36 seconds
PR opened → merged, no rework	14 minutes
PR opened → merged, with rework	1 hour 48
Merged with zero rework	82%

Fourteen minutes from a machine opening a pull request to it landing is not a throughput problem. Adding parallel workers wouldn’t have touched that number — it was never the slow part.

The tail is the whole problem

18% of pull requests consumed 37% of all elapsed time. The worst case took 48 hours and six rounds of review.

That’s the number that would have made “add more agents” actively worse. Every extra agent produces more pull requests, and review — not authorship — is the stage that’s slow. Parallelizing the fast part multiplies the input to the one bottleneck that isn’t fast.

Half the tail was embarrassing

I expected the slow tail to be hard problems: real disagreements, real rework, the kind of thing When the Factory Argues With Itself is about. Some of it is. But two of the six slowest merges had zero rework. They were documentation changes, sitting at 35.5 and 34.2 hours.

Nothing about them was hard. They were slow because a human had to notice they were done. That’s not a capacity problem, it’s a permission problem — so a docs-only PR now merges itself once the checks are genuinely green, no human noticing required.

Half the tail I still can’t measure

The rest of the tail is rework — real review rounds catching real problems, at real cost. I wanted to know which mistakes keep recurring, because that’s the difference between “review is doing its job” and “review is compensating for the same gap every time.”

I can’t answer that yet. The reviewer writes prose findings with no taxonomy, so out of 112 reviews I could reliably parse six. Which mistake keeps recurring is currently a question the factory cannot answer about itself, and I’d rather say that plainly than claim a fix I haven’t shipped. The instrumentation is next; the number isn’t.

So: the fast path was already fast, the slow path split cleanly into “a permission problem, now fixed” and “a measurement gap, not yet fixed,” and neither half of that would have been visible if I’d shipped the parallelism I originally reached for.