AI-assisted PRs break main half as often as human ones

Pull requests written with AI assistance broke main about half as often as ones written without it: 1.9% versus 4.4%. That is the opposite of what almost everyone expects, and it is the finding I keep coming back to from our first State of Merge Queues report.

We pulled every pull request that went through Mergify’s merge queue over 90 days. That is more than 200,000 merges across 477 teams platform-wide. The numbers below come from the subset actually running a real queue (at least ten merges and two human authors per repo), which is roughly 160 teams and 153,000 merges. Everything is aggregated and anonymized.

The question we set out to answer was narrow. What happens to a PR between the moment it is approved and the moment it lands on main? That gap is where a green PR can still break the branch, because two changes that each pass CI on their own can fail once they sit on top of each other. 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 pulls it apart to find the culprit, that is a broken main it prevented, and counting those gives you a rate almost nobody measures because almost nobody has the data.

The AI result, and why we tried to kill it

The common worry is that AI floods the branch with confident, subtly wrong code. In the data it runs the other way. AI-assisted PRs broke main at 1.9%, non-AI ones at 4.4%.

An association like that usually has a boring explanation, so we went looking for one. The obvious guess is that AI PRs are smaller and safer. They are not. AI-assisted PRs were larger on average, 137 changed lines against 84. Splitting by PR size, the gap held in every bucket: AI stayed near 1.7% whether the change was ten lines or a thousand, while human PRs climbed from 3.2% to 5.3% as they grew. The other guess is that a few lucky repos carried the result. 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.

This is observational, not a controlled trial, so I will not claim AI writes safer code. Teams that keep the “Generated with” footer on their commits may be more careful in ways we cannot see. But the two easy explanations both fall apart when you check them, and the data gives no support for the idea that AI is making main more fragile.

One caveat on the AI numbers generally. We can only count tools that stamp their work on a commit, mostly Claude Code. An engineer using inline Copilot or Cursor leaves no trace. So when we say AI assistance shows up in 1 in 7 private merges, that is a floor. The real share is higher, we just cannot see it.

The finding that matters more

The AI result gets the attention. The quieter one changes how you should think about your CI.

The broken-main rate is not constant. It scales about 16x with team size. At two to five engineers sharing a repo, a green PR breaks main about once in 130 merges, rare enough to fix by hand when it happens. At forty-plus engineers, it is one in eight. That is 12.5%, a standing tax on every busy week.

The curve bends between the 6-15 and 16-40 engineer buckets, which is exactly where teams usually start feeling merge pain without knowing how to name it. The mechanism is just arithmetic. More engineers means more PRs in flight at once, and more chances that two independent, individually-correct changes touch the same assumption. On private repos, failed batches bundle about six PRs on average, so one bad change can stall five good ones queued behind it.

Somewhere on that curve a merge queue stops being optional. If main starts breaking on days when nobody changed anything obvious, you have crossed the line.

Private code breaks main 4.5x more than open source

Open-source PRs break main a fifth as often: 1.1% against 5.1%. It is tempting to read that as open-source maintainers being more disciplined. The likelier reason is structural.

A lot of open-source contribution is isolated work. One person touches one corner of a codebase, opens a PR, and moves on. Private monorepos run the other way, with dozens of engineers editing interlocking code against a shared deadline. That is the exact condition that turns two green PRs into a broken main. The real split is isolated work versus interdependent work, and if your open-source project grows into a busy monorepo, expect your numbers to drift toward the private column.

Batching is the lever nobody pulls

The queue itself is fast. The median PR spends about seven minutes in it, and 90% clear within the hour, even on large teams where you would expect contention to pile up.

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, with automatic bisection when the batch fails. It is the main lever for cutting CI spend on a busy queue, and it does not trade safety for the saving, because a bad batch gets pulled apart automatically. Yet 94% of private merges still go through one PR at a time. On a queue doing dozens of merges a day, that is money left on the table, probably because the default feels safe and nobody went back to tune it.

What I would do with this

Three things follow if you run engineering at a growing company.

Watch the size curve, not the calendar. Below roughly fifteen engineers on a shared codebase, a queue is optional. Above it and still merging by hand, that 12.5% figure is roughly how often broken main 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 whole dataset.

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. Put that review attention where the failures actually are, on large human-authored changes in big teams.

The full report has the charts, the percentile tables, the queue-speed breakdown, and the method in detail, including how we suppressed any segment with fewer than five teams. It is all here: State of Merge Queues 2026.