30.000 Merges bei Anthropic, 250 bei mir: derselbe Engpass

Am 14. Oktober 2026 wurden in meinem GitLab 250 Änderungen gemergt. Anthropic kam im September auf über 30.000 am Tag. Mein Spitzentag neben ihrem Tagesdurchsatz ist eine ganz andere Größenordnung. Die Frage dahinter kenne ich trotzdem gut: Worauf wartet fertiger Code?

TL;DR

• Anthropic hat für seinen riesigen Monorepo Scion gebaut. Ein allgemeiner Ersatz für Git soll das ausdrücklich nicht sein.
• Bei mir warten Änderungen auf Integration: Review, Pipeline, Release-Fenster und meine Entscheidungen. Git taucht in meinen Messungen nicht als Engpass auf.
• Was ich heute schon tue: Releases gehen nur abends raus, Merges laufen je Repo nacheinander, und was ich entscheiden muss, landet an einem Ort. Merge und Deploy zu trennen ist mein nächstes Vorhaben.

Hinter der großen Zahl steckt ein vertrautes Problem

Anthropic beschreibt im Engineering-Artikel vom 13. Oktober 2026 einen Wechsel des Engpasses. Claude produziert Code schneller, als die bisherige Infrastruktur ihn verarbeiten kann. Source Control, Builds und CI müssen hinterherkommen. CI sind die automatischen Prüfungen, die Änderungen bauen und testen.

Die Zahlen dafür sind Eigenangaben von Anthropic:

Scion löst dort ein konkretes Größenproblem. Allein die Historie des Hauptzweigs ist fast 100 GB groß. Für CI fallen in der Größenordnung von 25 Millionen Code-Checkouts täglich an. Mehrere hundert interne Git-Spiegel wurden mit steigendem Durchsatz immer schwieriger zu betreiben.

Deshalb verlagert Scion Arbeit auf den Server. Der beantwortet Fragen zur Historie, berechnet Unterschiede und führt Änderungen zusammen. Clients holen nur, was sie brauchen; manche Jobs kommen ganz ohne lokale Arbeitskopie aus.

Was Scion nicht sein soll, steht im Original ausdrücklich da:

Scion is by no means a suitable replacement for git for general use.

Derselbe Engpass heißt: Nicht das Schreiben bremst, sondern alles danach. Bei Anthropic ist dabei Git an seine Grenzen gestoßen. Bei mir staut es sich auf dem Weg vom fertigen Code bis live, obwohl meine Repositories klein sind.

Meine Kurve: von 13 auf 250 Merges am Tag

Am 15. September wurden in meinem GitLab 13 Merge Requests gemergt. Am 14. Oktober waren es 250 an einem einzigen Tag. Ein Merge Request, kurz MR, ist ein Änderungsvorschlag zur Aufnahme in den gemeinsamen Code. Die 250 sind ein Spitzenwert, der Median über die 31 Tage liegt bei 121.

Vom 15. September bis 15. Oktober kamen in 51 aktiven Projekten 3.108 gemergte MRs zusammen. 2.643 davon hat das Agenten-Konto eröffnet, das sind 85 Prozent. Eröffnet heißt dabei noch nicht geprüft oder ausgeliefert.

Die Zahlen sind echt, aber vom 15. Oktober. Und sie zählen Merges, nicht Qualität.

Wenn so viel Code gleichzeitig fertig wird, stellen sich drei Fragen. Wer prüft ihn, wann darf er zusammengeführt werden, und wann erreicht er die Nutzer? Darum geht es auch in Verifikation statt Tippen.

Git kommt in meiner Warteschlange kaum vor

Das größte untersuchte Repository hat 942 MB. Die untersuchten CI-Konfigurationen klonen flach, mit Tiefe 20, also mit begrenzter Historie. In der Pipeline-Stichprobe beträgt die Wartezeit auf einen Runner im Median 4 Sekunden. Ein Runner ist der Rechner, der die Prüfungen ausführt.

In Lastspitzen warten Jobs durchaus länger, auch das habe ich gemessen. Einen Git-Engpass habe ich dabei nicht gefunden. Ehrlich gesagt: Ein neues Versionskontrollsystem würde bei mir an der falschen Stelle ansetzen.

Integration meint hier den ganzen Weg nach dem Schreiben: Review, Zusammenführen, automatische Prüfung und Auslieferung. Eine Änderung kann auf ihrem Branch fertig sein und trotzdem noch lange nicht im Produkt laufen. Für die Nutzer zählt erst dieser letzte Schritt.

So läuft das bei mir heute

Tagsüber bleibt der Release-MR stehen

Bei mehreren meiner Produkte löst ein Merge auf main direkt den Prod-Deploy aus. Was auf dem Hauptzweig landet, geht also gleich zu den Nutzern. Deshalb gehen Releases bei mir nur abends raus: Von 06:50 bis 22:05 Uhr gilt für Releases eine Tagesruhe.

Release-MRs werden tagsüber vorbereitet und geparkt. Ab 22:05 Uhr laufen sie nacheinander in Merge-Zügen. Ein Zug bündelt mehrere fertige Änderungen eines Repos, damit statt vieler Pipelines nur eine läuft. Interne Änderungen werden auch tagsüber gemergt, nur Releases warten.

Bevor etwas auf main geht, meldet die Coding-Session es beim Navigator an, meinem Werkzeug oberhalb der Coding-Sessions. Die Ansage nennt MR und Code-Stand und sagt, ob die Pipeline grün ist. Dazu kommt, was der Merge auf main auslöst und was das Review sagt. Gemergt wird dann vom Navigator selbst, in einer festen Reihenfolge.

Damit ist klar, wer wann dran ist. Ein Merge allein belegt aber noch keinen erfolgreichen Live-Stand.

Die laufende Pipeline bestimmt, wer als Nächstes darf

Die Reihenfolge regelt ein Fenster-Verfahren: Solange die main-Pipeline eines Repos läuft, ist das Fenster für den nächsten Merge dort zu. Änderungen werden dadurch nacheinander integriert. Im Kleinen ist das dieselbe Art Sperre, auf die Anthropic bei seinem Tempo verzichtet. Dort prüft man stattdessen automatisch nach dem Merge und vor dem Deploy.

Am 13. Oktober habe ich in einem Produkt-Repo eine Kette aus 10 Pipelines gemessen, hintereinander rund 3,7 Stunden. Das ist eine Folge dieses seriellen Ablaufs. Wie viele Agentenstunden dabei insgesamt verloren gingen, lässt sich daraus nicht ablesen.

Wer mehr Agenten auf die Implementierung setzt, kann vor dieser Sperre auch mehr fertige Arbeit ansammeln. Für mich ist das ein Grund, zuerst die Abhängigkeit zwischen den Schritten anzusehen. Zusätzlicher Code allein löst sie nicht auf.

Meine Entscheidungen landen an einem Ort

Freigaben, Rückfragen und Abnahmen landen bei mir in einer eigenen Warteschlange, der Owner-Queue. Offene Entscheidungen kommen dort mit Optionen und einer Empfehlung an. Entscheiden muss ich.

Vom 12. bis 14. Oktober kamen pro Tag 119 bis 125 neue Punkte dazu. Das sind Zugänge, keine erledigten Entscheidungen, und es geht dabei nicht nur um Merges.

An dieser Stelle werde ich selbst zum Engpass. Die Agenten können parallel weiterarbeiten, meine Aufmerksamkeit lässt sich nicht genauso vervielfachen. Wie diese Punkte bei mir ankommen, beschreibe ich in Vom iPhone zur Coding-Session.

Was ich als Nächstes ändern will

Drei Ideen aus Anthropics Artikel passen zu meinen Zahlen. Keine davon ist umgesetzt, das hier sind Vorhaben.

Merge und Deploy trennen. Das ist Anthropics Weg, und ich würde ihn zuerst an einem einzigen Produkt ausprobieren. Dabei baut main einen geprüften, noch nicht veröffentlichten Stand, ausgeliefert wird erst im Release-Fenster am Abend. Tagsüber könnte Code so bereits zusammengeführt werden.

Das verändert meinen Release-Weg und braucht eine bewusste Entscheidung. Die Pipeline-Sperre einfach zu entfernen, ohne die Prüfung vor der Veröffentlichung zu regeln, wäre mir zu wenig.

Den Abstand zwischen main und live beobachten. Anthropic setzt Claude als „Superfans“ ein, die je eine einzelne Komponente beobachten. Ein paar Wächter laufen bei mir schon, einer fehlt: einer für den Abstand zwischen main und dem, was wirklich live ist. Mehrmals war ein Stand gemergt und trotzdem stundenlang nicht live, einmal sogar tagelang.

Das Muster dahinter beschreibe ich in Gebaut, aber nicht eingeschaltet. Ein grüner Merge sagt noch nicht, dass das System läuft.

Reviews nach Wirkung unterscheiden. Das Scion-Team prüft laut Artikel weiter jede Änderung, aber auf ihre Absicht statt Zeile für Zeile. Ihr Review-Werkzeug unterscheidet dabei eine reine Kommentaränderung von einer Logikänderung.

Für reine Doku- und Test-Änderungen will ich einen gezielteren Review-Ablauf ausprobieren. Änderungen an der Logik bekommen weiter den vollen Review. Ob meine Warteschlange dadurch kleiner wird, muss ich erst messen.

Alle drei Vorhaben drehen sich um dieselbe Frage: Welcher Schritt muss auf welchen warten? Das verbindet sie mit Graph Engineering.

Bevor du weitere Agenten startest

Schau dir bei einer fertigen Änderung an, worauf sie gerade wartet:

• Fehlt ein Review?
• Läuft die Pipeline?
• Ist das Release-Fenster zu?
• Wartet eine Entscheidung?

Jeder dieser Fälle braucht eine andere Antwort. „Mehr Agenten“ sagt noch nicht, welcher davon schneller wird.

Ich würde zuerst diese Übergänge sichtbar machen. Ich kann zum Beispiel noch nicht beziffern, wie viel von langen MR-Liegezeiten auf die Tagesruhe geht. Ohne diese Zuordnung würde ich leicht an der falschen Stelle schrauben.

Für mich heißt die Lehre aus Scion: Integration als eigene Arbeit behandeln und ihre Wartezeiten prüfen. Git bleibt bei mir. Ein eigenes Versionskontrollsystem würde ein Problem lösen, das ich nicht habe, und ein Token-Budget in Anthropics Größenordnung geht sich bei mir nicht aus.

Wie die Flotte dahinter aufgebaut ist, steht in Eine Agenten-Flotte bauen. Der nächste Fortschritt muss sich für mich daran zeigen, ob geprüfte Änderungen verlässlich bei den Nutzern ankommen.

Quellen und Messstand

Anthropic: Redesigning source control at Anthropic, 13. Oktober 2026. Anthropic-Zahlen und das wörtliche Zitat stammen aus dieser Primärquelle.

Eigene Zahlen: interne Auswertung vom 15. Oktober 2026 in meinem privaten GitLab. Das Messfenster reicht vom 15. September bis zum 15. Oktober 2026, 07:51 UTC. Das sind 31 Kalendertage, der letzte nur teilweise erfasst. Der beschriebene Merge-Ablauf entspricht dem Stand Ende Oktober 2026.