Merge Rate

Software is rarely created in one single pass. Programmers propose individual changes, such as a bug fix or a new feature. Such a proposal is reviewed, often revised, and only then incorporated into the official version of the program. In technical jargon, this act of incorporation is called a merge. The merge rate measures what proportion of all submitted proposals make it all the way through this process. If sixty out of a hundred proposals are merged, the merge rate is 60 percent.

Why this number determines the fate of AI programmers

Ever since AI systems started writing code on their own, companies have needed an honest yardstick for their usefulness. Many earlier metrics are of little use for this. The number of lines of code written says nothing about quality. Test tasks in benchmark suites are also of limited significance, because the tasks are small and cleanly defined. Real projects are messy, have grown organically, and are full of edge cases.

The merge rate has one decisive advantage: at the end of the process stands a human who approves or rejects. A proposal is only accepted if an experienced developer considers it good enough. This means the metric does not measure whether code looks plausible, but whether someone is willing to take responsibility for it. That is precisely the hurdle at which weak AI proposals fail.

That is why merge rates now show up in quarterly figures and investor presentations. When a provider reports that a growing share of the company’s code comes from AI and is nevertheless being merged, that is a solid argument. Conversely, a low merge rate can become costly: every rejected proposal has consumed review time without delivering any benefit.

From proposal to approval

The process is similar in almost all projects. Someone changes code in their own working copy and submits the change as a package. On platforms like GitHub, this package is called a pull request. Automated tests first check whether the program still works. Afterwards, at least one human reads the change and comments on it. Only after approval is it merged.

To calculate the rate, one divides the number of merged proposals by the number of all completed proposals within a given period. Open, still undecided proposals are usually excluded. Otherwise the rate would drop merely because a lot had just been submitted. The same applies to proposals that were only meant for experimentation.

A common misconception is that a merge rate of 100 percent would be the goal. It would actually be a warning sign. It would mean that the review process filters out nothing, meaning it is either superficial or not happening at all. It is also important to distinguish this from the plain acceptance rate of autocomplete suggestions. There, it already counts if someone accepts a suggestion by pressing the Tab key. Whether the code ever makes it into a product remains an open question.

Merge rates in company reports and developer teams

Currently, the term is most often encountered in reports about AI programming tools. Providers of assistant systems and autonomous coding agents cite merge rates to demonstrate progress. Large technology corporations, too, now report what share of their new code was generated by machines. Anyone reading such figures should always ask how they were measured.

After all, the metric can easily be dressed up. A team can submit very small, low-risk changes, such as fixing typos in comments. Such proposals are almost always accepted and push the rate upward. The number only becomes meaningful when considered together with the scope of the changes and the number of revision rounds required.

For development teams themselves, the merge rate is also a diagnostic tool for their own workflow. If it declines over months, something is often wrong with coordination. Perhaps people are working on things nobody requested. Perhaps the review process is overloaded and proposals go stale before anyone looks at them. In such cases, the metric points to a problem, but does not name its cause.