GitHub gab am 6. Oktober 2026 in seinem offiziellen Engineering-Blog bekannt, die Git-Infrastruktur hinter dem weltweiten Code-Hosting neu zu bauen – aus einem direkten Grund: Wer den Code schreibt, hat sich verändert. Commits, Pushes und Merges von Agenten und Entwicklern auf GitHub haben sich im vergangenen Jahr vervielfacht, und die für menschliches Tempo gebaute Speicherarchitektur ist zuerst an den Schreib-Engpass gestoßen.
Zuerst die Zahlen: Pushes erreichen 3,35 Milliarden pro Monat
Die von GitHub gemeldete Größenverschiebung ist steil. Im August 2026 erreichten die Git-Ereignisse auf der Plattform 473,3 Milliarden, mehr als doppelt so viele wie ein Jahr zuvor; im September 2026 lagen die Commits bei 7,38 Milliarden, über fünfmal so viele wie im Vorjahr. Die Pushes stiegen von 0,69 auf 3,35 Milliarden pro Monat, ein Plus um das 4,9-Fache; die Merges von Pull Requests wuchsen auf fast das Vierfache, und GitHub Actions lief im September 3,26 Milliarden Mal, ebenfalls über viermal so oft.
Die Arbeitsweise von Agenten verstärkt jeden Schreibvorgang. Tausende Agenten, die parallel auf eigenen Branches eines Repositories arbeiten, erzeugen eine Dauer-Schreibrate, die auf einen einzigen Punkt zuläuft – den Trunk: Merges konkurrieren um eine Referenz, und Trunk-basierte Entwicklung, Release Trains und Merge Queues bündeln die gesamte Arbeit auf eine einzige Referenz, die jeden Merge aufnehmen muss. Jeder Push vervielfacht sich zudem zu tausenden Lesevorgängen, weil CI und Code-Scanning dieselbe Branch-Spitze tausende Male pro Minute klonen oder fetchen.
Lesen skaliert leicht, Schreiben nicht: die Kopplung der alten Architektur
GitHubs aktuelle Speicherschicht Spokes hält von jedem Repository eine vollständige Kopie auf den lokalen Platten mehrerer Fileserver – standardmäßig fünf – und nutzt ein Drei-Phasen-Commit-Protokoll mit Quorum, damit Weboberfläche, API und CI bei einer Referenzaktualisierung einen konsistenten Stand sehen. Diese Kombination trägt heute eine Milliarde Repositories.
Das Problem: Dauerhaftigkeit und Skalierung sind derselbe Mechanismus. Die Kopien auf den Platten sind zugleich die Quelle der Wahrheit und die Quelle der Lesekapazität. Mehr Lesekapazität bedeutet ein weiteres dauerhaftes Replikat, und jedes Replikat nimmt an jedem Schreibvorgang teil – ein Push ist nur so schnell wie sein langsamstes Replikat. Replikate für mehr Leseleistung verlangsamen das Schreiben, ein verlorenes Replikat kostet Lesekapazität, und ohne Quorum stoppt das Schreiben ganz. Für die meisten Repositories geht dieser Kompromiss auf; bei den aktivsten wird er zur Decke.
Die Richtung des Neubaus: Dauerhaftigkeit von Skalierung trennen
Die neue Architektur trennt Dauerhaftigkeit von Skalierung und hält dabei drei Linien: Die Workflows bleiben gleich – Branching, Review, Merge und Historie laufen auf der neuen Infrastruktur genau so, wie Teams sie heute vertrauen, ohne Gewohnheiten zu ändern. Zuverlässigkeit hat Vorrang, jeder Kompromiss wird an ihr gemessen. Und die Kontrolle bleibt beim Menschen: Branch-Schutz, Pflicht-Reviews, Audit-Logs und Repository-Sichtbarkeit bleiben erhalten – egal wie viel Agenten leisten, geprüft und freigegeben wird der Code von seinen Eigentümern. Technisch steht minimale Koordination im Vordergrund: Ein Repository mit vielen Pushes muss Aktualisierungen schnell annehmen und veröffentlichen, statt bei jedem Schritt auf globale Einigkeit zu warten. Der gesamte Umbau läuft, während die Plattform weiterläuft – es gibt kein Wartungsfenster, in dem der Code der Welt stillsteht.
Die Tragweite geht über ein Unternehmen hinaus. Sobald Agenten-Output in Milliarden von Commits gezählt wird, wandert der Engpass von der Modellfähigkeit zur Infrastruktur: Repositories, Reviews und CI, gebaut für menschliches Tempo, müssen für Maschinentempo neu gebaut werden. Diese Seite hat zuvor GitHubs ReviewBench-Evaluierung vorgestellt, die Agenten-Code an 219 echten Pull Requests misst – dort geht es darum, ob agentengeschriebener Code vertrauenswürdig ist. Dieser Neubau beantwortet die andere Hälfte: ob die Plattform selbst mit dem Tempo Schritt hält, in dem Agenten schreiben. Für Teams, die stark auf Coding-Agenten setzen, werden Schreibdurchsatz, Merge-Warteschlangen und Audit-Fähigkeit von Code-Plattformen in den nächsten zwei Jahren genauso aufmerksam zu beobachten sein wie die Modelle selbst.
