AI writes code that breaks main half as often.

When several approved PRs merge around the same time, each one is green on its own, but combined they can still break main. A merge queue catches this by testing every PR against the real state main will have at merge time. When a batch fails and the queue has to pull it apart to find the culprit, that is a break it prevented before it reached anyone.

Across the cohort that happened on 5.1% of private merges and 1.1% of open-source ones. The average hides the real story, which is team size:

At two to five engineers, a green PR breaks main about once in 130 merges, rare enough to handle by hand. At forty-plus engineers sharing a repo, it is one in eight. That is most of a team's week. The curve bends between the 6–15 and 16–40 buckets, which is exactly where teams usually start feeling merge pain.

The mechanism is just math. More engineers means more PRs in flight at once, and more chances that two independent, individually-correct changes touch the same assumption. The failed batches show it directly: on private repos they bundle about six PRs on average, so one bad change can stall five good ones queued behind it.

This is the case for a queue in a single chart. Below roughly fifteen engineers, most teams get by without one. Above it, "green PR, broken main" goes from a curiosity to a standing tax, and the cost of catching it by hand grows with every hire.

None of this means the queue is slow. The median PR spends about seven minutes in it, and ninety percent are through within the hour, even on large teams where you'd expect contention to pile up. Throughput sits around three merges per active day for a typical repo, and the busiest ten percent push thirteen or more.

The surprise is how few teams batch. Batching tests several PRs together in one CI run and merges them as a group if they pass, which is the main lever for cutting CI spend on a busy queue. Yet 94% of private merges still go through one PR at a time. Only about 6% ride in a batch (2.7% in open source), and when they do the batch holds four PRs on average, sixteen at the most. Most teams are leaving that saving on the table, probably because the default feels safe and nobody has gone back to tune it.

One more split worth noting: not all queue traffic is human. Automation like Dependabot and Renovate clears the queue in about 0.4 minutes, against roughly twelve for a human PR. Small mechanical dependency bumps fly through, real changes take real CI. We report the two separately through the rest of this report so the bots don't flatter the human numbers.

A word on what "a queue" means here, since GitHub shipped its own in 2023. For the simple case (serialize merges, test each against the queue), the native one does the job. The findings that bite hardest at scale lean on two things it does not do: batching with automatic bisection (the lever just above), and parallel queues by scope, so a change in one corner of a monorepo does not wait behind an unrelated migration. That gap, plus priority lanes and queue analytics, is where teams reach for a dedicated queue. Our comparison with GitHub's native queue lays out the specifics.

About one in seven private merges now carries a sign of AI assistance, the kind of "Generated with" footer or co-authored-by line a coding assistant stamps on a commit. In open source it's one in fourteen. And that is a floor, not a ceiling. We can only count the tools that stamp their work (Claude Code is most of what we see); an engineer using inline Copilot or Cursor leaves no trace, so the real share is higher.

It shows up as assistance. Autonomous agents authoring whole PRs on their own are still a rounding error, a few hundred merges out of 153,000. What we're seeing is simpler: most of a team writing code with a model open in the next pane, then shipping it through the same queue as always.

Now the part we didn't expect. AI-assisted PRs broke main about half as often as the rest, 1.9% against 4.4%. That runs straight into the common worry that AI fills your branch with confident, subtly wrong code, so we tried to break the finding. Comparing AI and non-AI PRs inside the same repositories, AI still came out lower in 21 of the 27 repos where the rates differed. Splitting by PR size, the gap held in every bucket: AI stays near 1.7% whether the change is ten lines or a thousand, while human PRs climb from 3.2% to 5.3% as they grow. And the obvious explanation, that AI PRs are just smaller and safer, turns out backwards. They're larger on average, 137 changed lines versus 84.

We're careful here. This is observational, not a controlled trial. The teams that keep the AI footer on their commits may be more disciplined in ways we can't see, and "in a failed batch" means a PR rode in a batch that broke, not that it caused the break. So the honest claim is that AI assistance is associated with fewer broken-main batches, and we leave causation alone. But the two easy explanations, smaller PRs and lucky repos, both fall apart when you check them. Whatever is happening, the data does not support the idea that AI is making main more fragile.

The open-source numbers look healthier almost everywhere, and it's worth being honest about why. Open-source PRs break main a fifth as often (1.1% versus 5.1%), spend less time tangled in batches, and lean on AI half as much (7.6% versus 14.4%). It's tempting to read that as open-source teams being more careful. The likelier reason is structural. A lot of open-source contribution is isolated, a fix or a feature from someone touching one corner of the codebase. Private monorepos run the other way, with dozens of engineers editing interlocking code on a shared deadline, which is exactly the condition that turns two green PRs into a broken main.

The real split is isolated work against interdependent work. Open source skews isolated; private codebases concentrate the interdependent kind. If your open-source project ever grows into a busy monorepo, expect your numbers to drift toward the private column.

A few things follow from the data if you run engineering at a growing company.

Watch the size curve, not the calendar. The broken-main rate barely moves until somewhere around fifteen to twenty engineers on a shared codebase, then it bends hard. Below that, a queue is optional, and you'll know when you cross the line because main starts breaking on days nobody changed anything obvious. Above it and still merging by hand, the 12.5% figure is roughly how often that is quietly costing you a revert and a context switch.

Turn on batching once the queue is busy. It is the clearest underused lever in the data, with 94% of merges still running one PR per CI cycle. On a queue doing dozens of merges a day, batching is where the CI bill actually comes down, and because a bad batch gets bisected automatically, you are not trading safety for the saving.

Stop gating AI-assisted code harder than the rest.Plenty of teams have added extra review friction for anything a model touched. The data gives no support for that as a merge-time policy, because AI-assisted PRs are not the ones breaking main. Put that review attention where the failures actually are, on large human-authored changes in big teams.

The data covers every pull request merged through Mergify's queue over a rolling 90-day window, more than 200,000 merges across 477 organizations. The rates in this report are computed on the subset running a real queue: repositories with at least ten merges and two distinct human authors in the window, about 160 organizations and 153,000 merges. The filter keeps toy repositories and bot-only projects from skewing the benchmarks.

Everything is aggregated and anonymized. No customer, repository, pull request, or author is identifiable, and any segment with fewer than five organizations is suppressed. Where we report distributions we use medians and percentiles rather than averages, which are less sensitive to a handful of outlier teams.

One honest limit. AI assistance is measured from the signatures tools leave on commits, mostly Claude Code's, so every AI number here is a floor and assistants that leave no trace are invisible to us.

A note on the named teams. The report is anonymous, but a few teams run their queues publicly enough to name, and they appear in the callouts above.