GitHubs Git-Neuaufbau für agentenbasierte Skalierung trennt Repository-Lesezugriffe von der Schreibkoordination

GitHub baut die Speicherarchitektur hinter seinem Git-Dienst um, um ein Entwicklungsmodell zu unterstützen, in dem Menschen, CI-Systeme und Software-Agenten gleichzeitig in dieselben Repositories schreiben können. Der jüngste Engineering-Beitrag des Unternehmens beschreibt einen Entwurf, der dauerhafte Repository-Daten zunehmend in Azure Blob Storage verlagert, die Lesekapazität unabhängig skalierbar macht und die Schreibkoordination von der Repository-Ebene auf die einzelnen Git-Referenzen beschränkt, für die eine Reihenfolge tatsächlich erforderlich ist.

Das ist eine bedeutende Infrastrukturänderung, aber keine neue Funktion, die Nutzer einfach aktivieren können. GitHub stellt die Arbeit als laufenden Umbau dar, der während des regulären Betriebs stattfindet. Nach dem Folgebeitrag hat das Unternehmen bereits Kopien von 99,99999 % seiner Repositories nach Azure verschoben. Für die verbleibenden Sonderfälle sind jedoch Änderungen am Schreibprotokoll nötig. Die Beiträge berichten außerdem über interne Verbesserungen beim Durchsatz. Sie veröffentlichen jedoch nicht genügend Benchmark-Details, um diese Zahlen als Kapazitätsgarantie für ein bestimmtes Unternehmen oder eine konkrete Agentenflotte zu verstehen.

Für Plattformteams lautet die unmittelbare Frage deshalb nicht, ob ein Repository plötzlich 35-mal schneller wird. Entscheidend ist vielmehr, automatisierte Entwicklungs-Workloads so zu entwerfen, dass nicht jeder Checkpoint zu einem Push werden muss, jeder Branch dieselbe stark belastete Referenz verwendet oder jeder CI-Job wiederholt dieselben Daten klont.

Was GitHub ändert

GitHubs bestehende Architektur, die das Unternehmen in seiner Engineering-Serie als „Spokes“ beschreibt, hält vollständige Repository-Kopien auf Storage-Knoten vor und nutzt für Schreibvorgänge eine quorum-basierte Koordination. Dieses Design bietet Dauerhaftigkeit und Konsistenz, verbindet jedoch mehrere unterschiedliche Aufgaben miteinander. Dasselbe allgemeine Replikatset ist an der dauerhaften Speicherung von Schreibvorgängen beteiligt, stellt Git-Lesezugriffe bereit und unterstützt Wartungsarbeiten wie Komprimierung und Garbage Collection.

Diese Kopplung wird teurer, wenn die Aktivität in mehrere Richtungen gleichzeitig steigt. Ein Agent kann deutlich häufiger Commits oder Checkpoints erzeugen als ein menschlicher Entwickler. Eine große Agentenflotte kann in einem Repository zahlreiche Branches anlegen. Nach jeder Änderung kann CI Lesezugriffe vom Branch-Spitzenstand aus auffächern. Merge-Warteschlangen und Release-Automatisierung können die Schreibvorgänge anschließend wieder auf wenige Referenzen konzentrieren.

GitHubs Neuentwurf folgt zwei miteinander verbundenen Prinzipien: Nur das koordinieren, was koordiniert werden muss, und dauerhafte Speicherung von der Rechenleistung trennen, die Anfragen bedient.

Das erste Prinzip betrifft die Aktualisierung einer Referenz innerhalb eines Git-Pushs. Ein Git-Repository enthält unveränderliche Objekte, die durch ihren Inhalt identifiziert werden, sowie veränderliche Referenzen wie Branch- und Tag-Zeiger. Die Aktualisierung der Referenz ist der Teil, der eine Reihenfolge benötigt: Sobald ein Client einen neueren Wert für eine Referenz sieht, sollten spätere Lesezugriffe nicht wieder einen älteren Wert zurückgeben. Viele andere Vorgänge rund um einen Push – darunter die Speicherung von Objekten, die Validierung der Verbindung, die Prüfung auf Geheimnisse und Wartungsarbeiten – können parallel ausgeführt oder aus dem engen Pfad bis zur Bestätigung herausverlagert werden.

Das zweite Prinzip verändert die Nutzung von Repository-Kopien. Statt von jedem Worker, der Lesezugriffe bedient, zugleich ein vollständiges dauerhaftes Replikat zu verlangen, beschreibt GitHub ein Modell, in dem Azure Blob Storage als dauerhafte Quelle dient und schlanke Worker eine zwischengespeicherte Lesekapazität bereitstellen. Fällt ein Worker aus, entspricht das eher dem Verlust eines Caches oder von Rechenkapazität als dem Verlust der maßgeblichen Repository-Kopie. Für leseintensive Lastspitzen lassen sich neue Worker hinzufügen, ohne automatisch bei jedem Schreibvorgang dieselben zusätzlichen Kosten zu verursachen.

Die Architektur wird schrittweise eingeführt. GitHubs Beiträge beschreiben virtuelle Replikate, Storage-gestützte Worker, die Serialisierung pro Referenz und Hintergrundwartung als Bestandteile einer Migration – nicht als eine einzelne, bereits abgeschlossene Produkteinführung.

Warum Agenten-Workloads den alten Engpass sichtbar machten

Die Änderung wird häufig als Geschichte über „KI-Infrastruktur“ beschrieben. Der zugrunde liegende Druck ist jedoch präziser: Softwareentwicklung mit hoher Nebenläufigkeit erzeugt eine andere Verteilung von Git-Operationen.

Ein menschlicher Entwickler arbeitet möglicherweise mehrere Minuten, bevor er einen Commit erstellt und einen Branch pusht. Ein automatisierter Agent kann dagegen bereits nach einzelnen Aufgaben einen Zwischenstand speichern, Tests ausführen, Dateien überarbeiten und den Ablauf wiederholen. Tausende Agents, die an einer Codebasis arbeiten, können dadurch viele gleichzeitige Schreib- und Lesevorgänge, Merge-Versuche und Statusaktualisierungen erzeugen. Dafür müssen die Agents nicht im umfassenden Sinn autonom sein. Schon eine skriptgesteuerte Programmierschleife, die mit einem Modell verbunden ist, kann denselben Druck auf die Infrastruktur ausüben, wenn sie häufige Repository-Operationen ausführt.

GitHub zufolge stieg die monatliche Git-Aktivität von 218,2 Milliarden Ereignissen im September 2025 auf 473,3 Milliarden im August 2026. Das Unternehmen meldet außerdem 7,38 Milliarden Commits im September, 3,35 Milliarden monatliche Pushes, nahezu ein vierfaches Wachstum bei Pull-Request-Merges sowie 3,26 Milliarden GitHub-Actions-Läufen in diesem Monat. Diese Zahlen beschreiben die gesamte Plattformaktivität und messen nicht isoliert die durch Agents verursachte Aktivität. Sie umfassen die Arbeit herkömmlicher Entwickler, CI, Automatisierung und das Wachstum der Kundschaft. Dennoch zeigen sie, warum ein Repository-Dienst, der für ein geringeres Maß an Parallelität ausgelegt wurde, neu bewertet wird.

Der Druck beschränkt sich nicht auf Schreibvorgänge. Ein Repository mit vielen Agents oder CI-Prozessen kann nach jeder Branch-Aktualisierung eine Welle von Fetches, Klonen, Statusabfragen und Pull-Request-Operationen erhalten. Wenn die Lesekapazität an dieselben vollständigen Replikate gebunden ist, die am Schreibquorum beteiligt sind, kann die Skalierung der Lesevorgänge die Schreibvorgänge verteuern. Benötigt ein Repository viele zusätzliche Replikate, um einen Lesespike abzufangen, können diese Replikate den Koordinations- und Wartungsaufwand erhöhen, selbst wenn sich das Schreibmuster nicht verändert hat.

Der Neuaufbau soll diese Rückkopplung durchbrechen. Lese-Worker können entsprechend der Nachfrage skaliert werden, während der dauerhafte Repository-Zustand und die geordneten Referenzaktualisierungen in einer separaten Schicht verbleiben. Dadurch wird nicht jede Git-Operation billig, und die Notwendigkeit von Konsistenz entfällt ebenfalls nicht. Verändert wird vielmehr, an welcher Stelle das System sein Koordinationsbudget einsetzt.

Koordination pro Referenz ist das entscheidende Designdetail

Das nützlichste technische Detail in GitHubs jüngster Erklärung ist der Wechsel von einer repositoryweiten Koordination zu einer Serialisierung pro Referenz.

Bei einer repositoryweiten Sperre oder einem vergleichbaren serialisierten Schreibpfad können sich zwei Pushes gegenseitig behindern, selbst wenn sie voneinander unabhängige Branches aktualisieren. Ein Push auf feature/alice wartet hinter einem Push auf feature/bob, weil das Repository die Einheit bildet, auf deren Ebene das System die Aktualisierung koordiniert. Dieser Ansatz ist leicht nachzuvollziehen, doch sein Durchsatz wird durch das langsamste Replikat, die für das Quorum nötigen Netzwerk-Roundtrips und die Zahl der Schreibvorgänge begrenzt, die die gemeinsame Warteschlange passieren können.

Die Serialisierung pro Referenz verengt den Konfliktbereich. Aktualisierungen desselben Branches müssen weiterhin geordnet werden. Zwei Force-Pushes auf dieselbe Referenz können nicht als unabhängig behandelt werden, weil ihr Endzustand von Reihenfolge und Richtlinien abhängt. Aktualisierungen verschiedener Branches können jedoch parallel ablaufen, sofern sie nicht gegen die Konsistenzregeln oder die Governance des Repositorys verstoßen.

GitHub zufolge erreichten Schreibvorgänge auf unterschiedliche Referenzen in internen Tests des neuen Ansatzes im beschriebenen Migrationsszenario bei geringerer Latenz ungefähr den drei- bis vierfachen Durchsatz. Dieses Ergebnis ist konkreter als die in einem früheren Architekturbeitrag genannte allgemeinere Angabe von „bis zu 35-mal höherem Schreibdurchsatz“, doch beide Werte bleiben interne Messungen. Die veröffentlichten Materialien enthalten nicht genügend Angaben zu Repository-Größe, Parallelität, Workload-Mix, Basishardware, Latenz-Perzentilen oder dem Rollout in der Produktion, um die Zahlen direkt in eine Dimensionierungsformel für ein externes Team zu übertragen.

Für die technische Planung ist diese Unterscheidung wichtig. Ein Repository mit Tausenden unabhängiger, kurzlebiger Branches kann von der geringeren Konkurrenz profitieren. Ein Workload, bei dem Tausende Worker denselben gemeinsamen Branch, denselben Release-Tag oder dieselbe Merge-Queue aktualisieren, hat dagegen weiterhin eine Hot Reference. Koordination pro Referenz begrenzt Konflikte zwischen unabhängigen Vorgängen; sie macht einen einzelnen geordneten Datenstrom nicht unendlich parallelisierbar.

Dauerhafter Speicher und Leseskalierung

Gits inhaltsadressiertes Objektmodell eröffnet die Möglichkeit, unveränderliche Daten vom veränderlichen Referenzzustand zu trennen. Sobald ein Objekt gespeichert und validiert wurde, leitet sich seine Identität aus seinem Inhalt ab. Der veränderliche Teil des Repositorys ist vergleichsweise klein: Referenzen bewegen sich, und das System muss sicherstellen, dass Clients eine mit diesen Bewegungen konsistente Reihenfolge sehen.

GitHub beschreibt Azure Blob Storage als dauerhafte Ebene für Repository-Daten und führt ein virtuelles Schreibreplikat ein, das eingehende Schreibvorgänge an den Objektspeicher weiterleitet. Der Schreibvorgang wird erst bestätigt, wenn die Daten auf dieser Ebene dauerhaft gespeichert sind. Leichtgewichtige Lesereplikate können anschließend ihre Caches aus dem Objektspeicher aufwärmen und den Leseverkehr bedienen, ohne sich auf dieselbe Weise wie ein vollständig dauerhaftes Replikat am Schreibquorum zu beteiligen.

Der Vorteil besteht nicht einfach darin, dass „Cloud-Speicher schneller ist“. Objektspeicher und Rechenkapazität für die Bereitstellung können unterschiedlich bereitgestellt und wiederhergestellt werden. Ein Lese-Worker lässt sich hinzufügen, wenn ein Release, eine CI-Fächerung oder eine Agentenflotte Nachfrage erzeugt. Ein ausgefallener Lese-Worker kann ersetzt und sein Cache neu aufgebaut werden. Wartungsarbeiten am Speicher können von separaten Workern durchgeführt werden, statt direkt mit laufenden Abrufen und Pushes auf denselben Maschinen zu konkurrieren.

Damit sind jedoch Abwägungen verbunden. Ein neu erstellter Lese-Worker startet möglicherweise mit einem leeren Cache. Der Abgleich mit dem dauerhaft gespeicherten Zustand muss auch bei gleichzeitigen Aktualisierungen korrekt funktionieren. Für manche Lesevorgänge ist ein aktuellerer Referenzzustand erforderlich als für andere; eine Synchronisierung im Hintergrund reicht dann möglicherweise nicht aus. GitHub zufolge sollen spätere Schritte einen größeren Teil des Abgleichs in den Anfragepfad verlagern, sodass ein Replikat den Referenzzustand und die Daten abrufen kann, die sich seit seinem letzten Aufholvorgang geändert haben.

Die Architektur verlagert das Problem also, statt es zu beseitigen. Anstatt jedes vollständige Replikat an jedem Vorgang zu beteiligen, muss das System Cache-Aktualität, dauerhaft gespeicherten Referenzzustand, Wiederherstellung, Komprimierung sowie die Grenzen zwischen Bereitstellung und Wartung steuern. Das Design ist attraktiv, weil sich diese Aufgaben unabhängig voneinander skalieren lassen. Diese Unabhängigkeit erfordert jedoch ausdrücklich definierte Konsistenzregeln und eine aussagekräftige Überwachung.

Die Zahl „35-mal“ muss sorgfältig gelesen werden

In einem früheren Beitrag schreibt GitHub, dass die neu aufgebaute Architektur in internen Benchmarks eine bis zu 35-mal höhere Schreibkapazität erreicht habe. Das ist ein nützlicher Hinweis auf die Richtung der Arbeit, aber kein Versprechen, dass ein Kunden-Repository eine 35-fache Verbesserung sehen wird.

Der öffentliche Beitrag beschreibt die Benchmark-Konfiguration nicht detailliert genug, um festzustellen, für welchen Bereich die Zahl gilt. Angaben zur Repository-Größe, zur Anzahl der Referenzen, zum Parallelitätsgrad, zur Verteilung der Schreibvorgänge, zum Verhältnis von Lese- zu Schreibvorgängen, zum Vergleichssystem, zur Latenzverteilung, zu Fehlerbedingungen oder dazu, ob der Benchmark Produktionsverkehr abbildet, fehlen. Ebenso wird nicht gesagt, dass jedes Repository bereits auf den neuen Pfad migriert wurde oder dass die Messung ein allgemein verfügbares Dienstlimit darstellt.

Die Statistiken zur Aktivität des Unternehmens sollten mit derselben Vorsicht betrachtet werden. Das schnelle Wachstum bei Pushes und Commits zeigt, dass die Plattform unter Druck steht, beweist aber nicht, dass Agents den gesamten Anstieg verursacht haben. Es zeigt auch nicht, dass mehr Git-Operationen proportional mehr brauchbare Software hervorbringen. Eine hohe Zahl automatisierter Zwischenstände kann produktive parallele Arbeit, unnötige Änderungen, wiederholte Wiederholungsversuche oder eine Mischung aus allen drei Faktoren darstellen.

Die operative Schlussfolgerung ist einfach: Eine Agentenplattform sollte nicht dimensioniert werden, indem die aktuelle Parallelität mit dem Schlagzeilen-Benchmark multipliziert wird. Betrachte den Benchmark als Beleg dafür, dass GitHub einen strukturellen Engpass angeht, und miss anschließend den eigenen Workload anhand von Push-Latenz, abgelehnten oder wiederholten Pushes, API-Ratenlimits, Wartezeit in Warteschlangen, CI-Fächerung und der Zeit bis zum Merge.

Was das jetzt für Engineering-Teams bedeutet

Nutzer müssen ihre üblichen Git-Arbeitsabläufe wegen dieser Ankündigung nicht neu schreiben. GitHub will nach eigenen Angaben Verzweigungen, Reviews, Merges, Historie, Branch Protection, erforderliche Reviews, Audit-Logs, die Sichtbarkeit von Repositories und andere Kontrollen erhalten und lediglich das Backend ändern, das sie bereitstellt.

Teams, die umfangreiche Automatisierung betreiben, sollten ihre Workload-Gestaltung dennoch überprüfen. Diese Prüfung ist auch dann sinnvoll, wenn GitHubs Migration den aktuellen Druck später weitgehend beseitigt, denn sie reduziert verschwendete Arbeit und erleichtert die Wiederherstellung nach Fehlern.

Unnötig häufige Pushes reduzieren

Ein Agent muss nicht jeden Zwischenstand einer Aufgabe in einen gemeinsam genutzten Remote-Branch pushen. Halte lokale Zwischenstände nach Möglichkeit lokal und pushe anschließend wichtige Meilensteine oder ein begrenztes Änderungspaket. Die richtige Häufigkeit hängt von den Anforderungen an die Wiederherstellung und den Kosten eines Verlusts lokaler Arbeit ab. Eine Richtlinie, die aus jedem Tool-Aufruf einen Remote-Push macht, erzeugt jedoch vermeidbaren Schreibverkehr.

Bei lang laufenden Jobs sollten lokale oder externe Checkpoints getrennt vom Branch-Update erhalten bleiben, wenn das Team eine fein abgestufte Wiederherstellung benötigt. So bleibt die dauerhafte Wiederherstellungsanforderung von der Git-Referenz getrennt, die andere Entwickler und Systeme verwenden müssen.

Keine einzelne stark belastete Referenz erzeugen

Tausende unabhängige Branches können weiterhin auf einen geschützten Branch, ein Release-Tag oder eine Merge-Queue zulaufen. Ermittelt die Referenzen mit der höchsten Schreibrate und die Workflows, die sich an ihnen serialisieren. Ein Repository kann eine hervorragende parallele Verarbeitung über viele Branches hinweg bieten, während eine gemeinsam genutzte Referenz praktisch zum Engpass wird.

Setzt Merge-Queues und kontrollierte Bündelung ein, wenn sie die Reihenfolge verbessern, und beobachtet dabei das Queue-Alter sowie das Retry-Verhalten. Eine Queue, die wiederholt denselben großen Änderungssatz neu berechnet oder validiert, kann den Druck von Git-Schreibvorgängen auf CI, Pull-Request-APIs oder die Testinfrastruktur verlagern.

CI-Lesezugriffe bewusst gestalten

Leseintensive Automatisierung kann ein Repository überlasten, selbst wenn das Push-Volumen moderat ist. Bevorzugt flache oder partielle Klone, sofern der Workflow das zulässt, verwendet Repository-Caches wieder, vermeidet wiederholte vollständige Klone identischer Eingaben und verteilt die Last, wenn ein Release oder eine Branch-Aktualisierung gleichzeitig viele Jobs auslöst.

GitHubs Empfehlungen für Repositories sehen vor, innerhalb betrieblicher Grenzen zu bleiben, etwa einer Push-Größe von 2 GB, einer empfohlenen Obergrenze von 15 Git-Leseoperationen pro Sekunde und Repository sowie sechs Pushes pro Minute und Repository als empfohlener Push-Rate. Diese Werte ersetzen keine Kapazitätsplanung und beschreiben nicht jede API- oder Enterprise-Konfiguration. Sie erinnern jedoch daran, dass ein Repository eine gemeinsam genutzte Servicegrenze ist. Automatisierte Clients sollten die veröffentlichten Limits als Designvorgaben behandeln, statt sie erst durch Drosselung kennenzulernen.

Verhindern, dass Retries einen Vorfall verstärken

Ein fehlgeschlagener Push oder Fetch kann dazu führen, dass eine große Flotte automatisierter Prozesse im selben Moment erneut startet. Verwendet exponentielles Backoff mit Jitter, begrenzt die Zahl der Wiederholungen, unterscheidet vorübergehende Transportfehler von Richtlinienfehlern und protokolliert die ursprüngliche Operations-ID oder den Commit-Bereich, damit ein Retry keine doppelte Arbeit erzeugt.

Eine Retry-Strategie sollte außerdem menschliche Prüfungen berücksichtigen. Wartet ein Workflow auf die Aktualisierung eines geschützten Branches, kann blindes Wiederholen dieselbe Referenz überfluten, während ein Operator den Vorgang untersucht. Backoff ist eine Maßnahme zur Zuverlässigkeit und nicht bloß eine clientseitige Optimierung der Leistung.

Governance trotz zunehmender Automatisierung bewahren

GitHub erklärt, dass die neue Infrastruktur Branch-Schutz, erforderliche Reviews, Audit-Logs und die Sichtbarkeit von Repositories erhalten soll. Organisationen sollten prüfen, ob ihre eigenen Agent-Workflows ausdrücklich auf diese Kontrollen setzen. Ein schnellerer Schreibpfad ersetzt weder Genehmigungsregeln noch Secret-Scanning, erforderliche signierte Commits, den Schutz von Umgebungen oder Deployment-Prüfungen.

Agents sollten nur die für ihre Aufgabe erforderlichen Berechtigungen für Repositories und Umgebungen erhalten. Trennt den Zugriff zur Codegenerierung von Merge-Berechtigungen, Deployment-Zugangsdaten und Produktionsdaten. Wenn ein Agent Branches anlegen, den geschützten Standard-Branch aber ohne Review nicht aktualisieren kann, erhöhen die Skalierungsverbesserungen der Plattform den Durchsatz, ohne den menschlichen Entscheidungspunkt stillschweigend zu entfernen.

Was weiterhin unbekannt ist

In GitHubs öffentlicher Beschreibung sind mehrere wichtige Fragen noch offen.

Das Unternehmen hat keinen vollständigen Zeitplan für den Rollout der neuen Architektur veröffentlicht. Es hat nicht beschrieben, wie viele Produktions-Repositories von dem speicherbasierten Lesemodell bedient werden, welche Workloads dafür infrage kommen oder wann Kunden mit erkennbaren Änderungen bei Limits und Latenz rechnen können.

Auch die Benchmark-Aussagen benötigen mehr Kontext. Externe Leser brauchen Definitionen der Workloads, Repository-Größen, Nebenläufigkeitswerte, p50- und p99-Latenzen, Angaben zum Fehlerverhalten sowie Vergleiche mit dem bisherigen Pfad. Ohne diese Details ist „bis zu“ ein nützliches technisches Signal, aber keine verlässliche Grundlage für die Planung.

Die Konsistenz während des Aufwärmens des Caches ist ein weiterer Bereich, den man beobachten sollte. Ein Worker, der seinen Zustand aus einem Objektspeicher wiederherstellt, darf keine veralteten Referenzwerte zurückgeben, wenn dadurch Git-Erwartungen verletzt werden. Das System muss außerdem Kompaktierung, Garbage Collection, unterbrochene Schreibvorgänge, Verzögerungen zwischen Regionen und die Wiederherstellung nach Teilausfällen bewältigen, ohne dass die Wartung selbst zu einem neuen Engpass beim Ausliefern wird.

Schließlich ist der Zusammenhang zwischen der Aktivität von Agents und dem gemeldeten Plattformwachstum weiterhin nur teilweise messbar. GitHubs Statistiken umfassen menschliche Entwickler, herkömmliche Automatisierung, CI und agentische Workflows. Das rechtfertigt architektonische Arbeiten, reicht aber nicht aus, um daraus abzuleiten, dass jede Organisation dasselbe Muster bei der Nebenläufigkeit erleben wird.

Die praktische Einordnung der Ankündigung

GitHub reagiert auf eine reale Veränderung der Softwareentwicklung: mehr Repository-Operationen, mehr parallele Branches, mehr automatisierte Lesezugriffe und größerer Druck auf gemeinsame Integrationspunkte. Die Antwort des Unternehmens besteht darin, unnötige Koordination zu reduzieren, dauerhaften Speicher von der Ausführungsleistung für die Bereitstellung zu trennen und die Lesekapazität, wo möglich, unabhängig vom Schreibquorum zu machen.

Für Kunden lautet die kurzfristige Lehre: Workloads diszipliniert steuern. Verhindern Sie, dass der Zwischenzustand von Agents zu ständigem Git-Verkehr über das Netzwerk wird, identifizieren Sie besonders belastete Referenzen, begrenzen Sie die CI-Verteilung, cachen Sie wiederholte Lesezugriffe und gestalten Sie Wiederholungsversuche schonend. Halten Sie Review- und Bereitstellungsgrenzen weiterhin durch, auch wenn die Automatisierung leistungsfähiger wird.

Die Architektur könnte GitHub letztlich deutlich mehr Spielraum verschaffen, doch die veröffentlichten Benchmarks machen es weiterhin erforderlich, reale Workloads zu messen. Für ein Plattformteam lautet die entscheidende Frage nicht, ob GitHub einen großen Multiplikator angekündigt hat. Entscheidend ist, welcher Teil des Entwicklungszyklus derzeit serialisiert wird, ob diese Serialisierung notwendig ist und was geschieht, wenn der nächste Schub automatisierter Arbeit eintrifft.