The software factory · the bottleneck

Why code review is the software factory's real bottleneck

Agentic coding made writing software cheap. It did nothing for the part that was always the constraint — a human deciding whether to trust the result. Here's the math that stops the factory.

The pitch for the software factory is a generation story: point a fleet of agents at your backlog and watch the pull requests pour out. And they do — teams running agent fleets report huge jumps in PRs opened. But shipping isn't generating. Every one of those PRs still has to pass a human who decides it's safe to merge, and that human's day did not get longer. Generation scaled; review didn't. Drag the sliders and watch where the line jams.

You ship what you can review, not what you can write

The simulator has one honest cruelty built in: throughput is capped by the slowest stage, and the slowest stage is the human gate. Add agents past your review capacity and the "generated" bar keeps climbing while the "shipped" bar flattens. The gap between them isn't progress — it's a growing backlog of un-reviewed code, or worse, code that gets waved through unread. Roughly half of developers already admit they don't consistently review the AI code they commit. A factory that merges what it can't review isn't fast; it's just accumulating risk quickly.

Why more agents can make it worse

It gets counterintuitive. As you parallelize more agents across a codebase, the pull requests get bigger and more entangled — 2026 surveys put the jump at well over a hundred percent larger diffs on high-adoption teams — and a big, unfamiliar diff is exactly what a human reviews slowly and badly. So the review lane doesn't just stay fixed while generation grows; its effective capacity drops under the load. Meanwhile trust in AI-written code has been falling year over year, which means reviewers are being asked to look harder at more code in less time per line. That's the jam.

How you actually widen the gate

The fix is not "hire more reviewers" (linear, expensive) or "run fewer agents" (surrenders the point). It's to make each review faster and better targeted: keep PRs small so a diff is legible; put honest evals in front of the human so obvious failures never reach the queue; and route each judgment to the person who can actually make it — a senior engineer on the risky logic, but the non-technical stakeholder on whether the screen reads right, the copy lands, the flow makes sense. That last part is the half of "review" that code review can't do, and it's where a lightweight human-feedback loop earns its keep: twocents lets your agent share the running result, real people pin exactly what's wrong right on it, and the agent gets those notes back structured enough to fix. It doesn't check your logic — evals and a senior reviewer do that — it clears the human-facing reviews off the critical path so the expensive reviewer only spends time where it counts.

The stats here are directional, drawn from 2026 industry surveys on agentic-coding adoption (more PRs merged, longer review times, larger diffs, falling trust in AI code). The simulator is a teaching toy, not a capacity planner — but the shape it draws, generation outrunning review, is the one every team scaling agents runs into.