Merge-Rate

Software entsteht selten in einem Rutsch. Programmiererinnen und Programmierer schlagen einzelne Änderungen vor, etwa eine Fehlerbehebung oder eine neue Funktion. Ein solcher Vorschlag wird geprüft, oft überarbeitet und erst dann in die offizielle Version des Programms übernommen. Dieses Übernehmen heißt im Fachjargon Merge, also Zusammenführen. Die Merge-Rate misst, welcher Anteil aller eingereichten Vorschläge diesen Weg bis zum Ende schafft. Werden von hundert Vorschlägen sechzig übernommen, liegt die Merge-Rate bei 60 Prozent.

Warum die Zahl über KI-Programmierer entscheidet

Seit KI-Systeme selbstständig Code schreiben, brauchen Unternehmen einen ehrlichen Maßstab für deren Nutzen. Viele frühere Kennzahlen taugen dafür wenig. Die Zahl der geschriebenen Codezeilen sagt nichts über Qualität aus. Auch Testaufgaben in Prüfungssets sind begrenzt aussagekräftig, weil die Aufgaben klein und sauber gestellt sind. Echte Projekte sind unordentlich, gewachsen und voller Sonderfälle.

Die Merge-Rate hat einen entscheidenden Vorteil: Am Ende steht ein Mensch, der zustimmt oder ablehnt. Ein Vorschlag wird nur übernommen, wenn ein erfahrener Entwickler ihn für gut genug hält. Damit misst die Kennzahl nicht, ob Code plausibel aussieht, sondern ob jemand bereit ist, Verantwortung dafür zu tragen. Genau das ist die Hürde, an der schwache KI-Vorschläge scheitern.

Deshalb tauchen Merge-Raten inzwischen in Quartalszahlen und Investorenpräsentationen auf. Wenn ein Anbieter berichtet, dass ein wachsender Anteil des Firmencodes von KI stammt und trotzdem übernommen wird, ist das ein handfestes Argument. Umgekehrt kann eine niedrige Merge-Rate teuer werden: Jeder abgelehnte Vorschlag hat Prüfzeit gekostet, ohne Nutzen zu bringen.

Vom Vorschlag bis zur Zustimmung

Der Ablauf ist in fast allen Projekten ähnlich. Jemand ändert Code in einer eigenen Arbeitskopie und reicht die Änderung als Paket ein. Auf Plattformen wie GitHub heißt dieses Paket Pull Request. Automatische Tests prüfen zuerst, ob das Programm weiterhin funktioniert. Danach liest mindestens ein Mensch die Änderung und kommentiert sie. Erst nach der Freigabe wird zusammengeführt.

Zur Berechnung teilt man die Zahl der zusammengeführten Vorschläge durch die Zahl aller abgeschlossenen Vorschläge in einem Zeitraum. Offene, noch unentschiedene Vorschläge lässt man dabei meist außen vor. Sonst würde die Rate allein dadurch sinken, dass gerade viel eingereicht wurde. Ähnliches gilt für Vorschläge, die nur zum Ausprobieren gedacht waren.

Ein häufiger Irrtum ist, dass eine Merge-Rate von 100 Prozent das Ziel sei. Sie wäre eher ein Warnsignal. Sie würde bedeuten, dass die Prüfung nichts aussortiert, also entweder oberflächlich ist oder gar nicht stattfindet. Auch die Abgrenzung zur reinen Akzeptanzquote von Autovervollständigung ist wichtig. Dort zählt schon, dass jemand einen Vorschlag mit der Tabulatortaste annimmt. Ob der Code jemals in ein Produkt gelangt, bleibt dabei offen.

Merge-Raten in Firmenberichten und Entwicklerteams

Am häufigsten liest man den Begriff derzeit in Meldungen über KI-Programmierwerkzeuge. Anbieter von Assistenzsystemen und autonomen Coding-Agenten nennen Merge-Raten, um Fortschritt zu belegen. Auch große Technologiekonzerne berichten inzwischen, welcher Anteil ihres neuen Codes maschinell entstanden ist. Wer solche Zahlen liest, sollte immer nachfragen, wie sie gemessen wurden.

Denn die Kennzahl lässt sich leicht schönen. Ein Team kann sehr kleine, risikoarme Änderungen einreichen, etwa Tippfehler in Kommentaren. Solche Vorschläge werden fast immer übernommen und treiben die Rate nach oben. Aussagekräftig wird die Zahl erst zusammen mit dem Umfang der Änderungen und der Zahl nötiger Überarbeitungsrunden.

Für Entwicklerteams selbst ist die Merge-Rate außerdem eine Diagnose für den eigenen Arbeitsprozess. Sinkt sie über Monate, stimmt oft etwas mit der Abstimmung nicht. Vielleicht arbeiten Leute an Dingen, die niemand angefordert hat. Vielleicht ist der Prüfprozess überlastet und Vorschläge veralten, bevor jemand sie ansieht. Die Kennzahl zeigt in solchen Fällen ein Problem an, benennt seine Ursache aber nicht.