Code review is the slow part
Agents made code cheap to write. Someone still has to decide whether to trust it.
Point a fleet of agents at your backlog and the pull requests pour in. Teams report big jumps in PRs opened. Each PR still needs a person to decide it's safe to merge, and that person's day didn't get longer. Move the sliders and watch PRs generated pull away from PRs shipped.
The factory throughput simulator
Reviewers get slower per PR as agents multiply, because parallel work makes bigger, more tangled diffs.
You ship what you can review
The slowest stage caps throughput, and that stage is the human gate. Past your review capacity, more agents just grow a pile of unreviewed code, or code waved through unread. Plenty of developers already admit they don't always review the AI code they commit.
Why more agents can make it worse
Run many agents in parallel on one codebase and the PRs get bigger and more tangled. People review big, unfamiliar diffs slowly and badly, so review capacity drops as the load grows. Meanwhile trust in AI-written code keeps falling.
How to widen the gate
Hiring more reviewers is expensive. Running fewer agents defeats the point. Make each review faster instead. Keep PRs small. Put evals in front of the human so obvious failures never reach the queue. And send each judgment to the right person: a senior engineer for the risky logic, a non-technical stakeholder for whether the screen, copy and flow make sense.
Code review can't do that last check. twocents can: your agent shares the running result, people pin what's wrong on it, and the agent gets the notes back ready to fix. It won't check your logic. It clears the human-facing reviews so your senior reviewer only spends time on the risky logic.
The simulator is a teaching toy, but teams scaling agents keep hitting the shape it draws.