15% of Paxos PRs Come From an Agent. Now What?

On July 29, Paxos disclosed that Hoplites, its internally built Slack-native coding agent, now accounts for 15% of all merged pull requests across the company's repositories. More than 2,000 PRs loaded, more than half merged. This is a regulated financial infrastructure company, not a research lab, and the number is specific and sourced. The question it forces is not whether agents can produce code. That question is settled. The question is what a healthy review pipeline looks like when a meaningful fraction of incoming PRs has no human author.

Why 15% Is the Threshold That Changes the Pipeline#

Below some agent PR share, human review processes absorb the additional volume without structural change. Above some share, they cannot, because review is bounded by human attention and code generation is not. The exact crossover depends on team size and review depth, but 15% at a company-wide level is high enough to expose the structural problem without yet overwhelming the organization.

Amdahl's Law describes this precisely: the speedup available from optimizing one stage of a pipeline is capped by every stage left unoptimized. Paxos's Hoplites was built in under a month and reportedly costs five times less per PR than a developer using an AI assistant locally. That is an enormous compression of the generation stage. The review stage got no corresponding improvement. So throughput is now set by review, not by generation, and every hour a PR waits to be picked up is an hour the underlying codebase drifts further from the branch the agent was working on.

LinearB's 2026 Software Engineering Benchmarks, drawn from 8.1 million pull requests across 4,800 organizations, found that agentic PRs have a pickup time 5.3x longer than unassisted ones. The bottleneck is visible in that single number. The problem is not producing PRs. It is getting them reviewed before they become merge conflicts.

What the Merge Conflict Data Says#

A peer-reviewed dataset helps quantify the downstream cost of review delay. The AgenticFlict study (Ogenrwot and Businge, AIware '26, ACM) analyzed more than 142,000 agentic PRs from over 59,000 repositories. Of the roughly 107,000 that could be merge-simulated, 27.67% produced merge conflicts, across more than 336,000 conflict regions.

Better than one in four is a rate you design around. Agent workloads have a structural property human workloads mostly lack: many branches are cut from the same base commit at nearly the same moment, each worked on without knowledge of the others. Semantic conflicts, changes that merge cleanly at the text level but are wrong together, are a predictable output of this pattern. A merge queue tests the actual post-merge state rather than each branch in isolation, but under high agent volume the queue itself becomes a scheduling problem. Batching with a bisect strategy, staleness bounds on branches before they enter the queue, and enforced diff-size limits in CI are all mechanical responses to a mechanical problem.

The diff-size limit in particular is blunt and effective. LinearB's data shows AI-assisted PRs run 2.6x larger at the 75th percentile (408 lines vs. 157). A CI gate that rejects branches over a documented line-count ceiling and requires an override label pushes work back toward decomposition, which is the correct place to push it.

Three Things That Break at 15% Agent Share#

The Paxos disclosure is useful precisely because it names a real number at a real company. That number makes three failure modes concrete rather than theoretical.

First, the reviewer-per-PR ratio inverts. Reviewers now spend more hours reading than writing. The DORA State of AI-assisted Software Development report (Google Cloud, September 2025) found that 30% of respondents report little or no trust in agent-generated code, a gap that falls entirely on reviewers to absorb. Senior engineers who hold the context needed to approve changes in high-risk areas become the single point of failure, their own delivery stalls, and review quality falls precisely where it matters most.

Second, "the agent said it was done" becomes an auditable claim, not a chat message. Hoplites operates through Slack threads: users tag it, it claims a job, streams progress, and can dispatch follow-up jobs to fix failing builds. That is a workflow that produces evidence only if the review step also produces evidence. A Slack reaction is not a review record. The review event needs to be written somewhere that holds state , who reviewed it, when, and what they found , and that record needs to outlive the thread.

Third, test coverage and documentation co-generated by Hoplites inherit the same trust boundary as the code itself. An agent that writes the implementation and writes the tests is not providing independent verification. It is providing correlated confidence. A reviewer checking agent-authored tests for agent-authored code is in the same epistemic position as a model reviewing its own output: the misunderstanding that produced the bug is plausibly the same misunderstanding that failed to catch it.

What the Review Pipeline Needs#

The defender-side configuration changes fall into three categories, each addressing one of the failure modes above.

For the capacity problem: enforce a maximum changed-line count on agent branches as a CI check with a documented override, not a social convention. Set it. Require branches to be within a bounded distance of main before entering the merge queue. Rotate a named reviewer-of-the-day with protected time and no concurrent delivery commitments , review stops being the thing everyone does badly between meetings and becomes a staffed function.

For the auditability problem: require every agent-authored PR to carry a named human owner, not a team assignment. Named ownership is the mechanism that collapses diffusion of responsibility. Log review events with a timestamp, a reviewer identity, and a verdict in a system of record that is not a Slack channel. The record is what makes "the agent said it was done" into a claim that can be audited.

For the correlated-confidence problem: treat agent-authored tests as covering the happy path only until a human has independently verified the edge-case coverage. Move machine-decidable checks , lint, type safety, dependency policy, security scanning , entirely off the human reviewer and into CI. Human attention is the scarce resource and should be spent on intent, design, and the failure modes the agent was not prompted to consider.

The Artifact, Not the Author#

The Paxos number , 15%, over 2,000 PRs, more than half merged , is the most specific public data point available on what agent-at-scale looks like inside a production engineering organization. It will not be the last such disclosure. Stripe's Minions, Ramp's Inspect, and Spotify's Honk are all running variations of the same pattern, and the bottleneck analysis covered in detail here applies to all of them.

The correct framing for any of these systems is that the artifact that arrives at review is a PR. It has a diff, a test suite, and a description. Whether a human typed it or a Slack-native agent generated it from a thread context is a fact about provenance, not about what the review process needs to do. Scanning the artifact, not the author's chat history, is the only posture that scales.

Hyrax scans the artifact. Six agent domains across security, code quality, reliability, API and data, ops, and UX. Thirteen verification steps before a fix becomes a PR. The author's identity is not part of the analysis. At 15% agent-authored PR share and climbing, that distinction is not a product position. It is the only approach that remains valid as the numbers continue to move.

Hyrax is live at hyrax.dev.