GitHub hat diese Woche eine Zahl veröffentlicht, die besser als jede Umfrage zeigt, was Coding-Agenten mit der Softwarewelt machen: 7,38 Milliarden Commits im September. Im August waren es 2,9 Milliarden. Die Zahl steht in einem Beitrag von Jay Parikh, Microsofts Executive Vice President für Core AI, der auch GitHub verantwortet, und in der Berichterstattung über GitHubs Ausbaupläne.
Die Infrastrukturzahlen dazu sind genauso unhöflich. Die monatlichen Plattform-Ereignisse stiegen von 218 Milliarden im September 2025 auf 473 Milliarden ein Jahr später. GitHub hat 2026 bisher vier Millionen CPU-Kerne hinzugefügt, dazu 160 Petabyte Hochgeschwindigkeitsspeicher, zusätzliche GitHub-Actions-Kapazität und 50 Terabit pro Sekunde Netzwerkkapazität. Das sind keine Marketingzahlen; es ist die Rechnung für den Ansturm.
Der eigentliche Befund ist jedoch architektonisch. GitHubs bisheriges Speicherdesign, intern „Spokes", schrieb Commits über ein dreiphasiges Verfahren und hielt dabei vollständige Repo-Kopien auf lokalen Festplatten. Ein Push war damit so schnell wie die langsamste Replik, die für ein Quorum gebraucht wurde. Für menschliche Arbeitsrhythmen war das jahrelang in Ordnung. Für Tausende parallel arbeitender Agenten ist es strukturell falsch. In einem Engineering-Beitrag Anfang Oktober beschrieb GitHub den Umbau: Jeder Commit wird genau einmal in Azure Blob Storage geschrieben, das die Replikation selbst übernimmt; Leseanfragen wandern auf leichte Worker; Lese- und Schreibpfad koordinieren sich nur noch über Referenzen statt über ganze Repositories. Interne Tests zeigen eine 35-fache Verbesserung bei Schreibvorgängen. Für Entwickler soll sich nichts ändern. Einen Migrationszeitplan nennt GitHub nicht.
Der Anlass war unangenehm. Im April häuften sich bei GitHub zehn Performance-Vorfälle in einem einzigen Monat; Ausfälle und Verlangsamungen trafen auch Copilot. Die Ursache war der Verkehr, den das alte Design nie vorgesehen hatte: Agenten schreiben in Bursts, öffnen viele Branches und Worktrees, committen in Schleifen und lösen pro Durchlauf CI aus. Ein Mensch committet ein paar Mal am Tag. Ein Agent committet hunderte Male pro Aufgabe.
Bemerkenswert ist, dass GitHub nicht allein dasteht. Auch Cursor und ein neuer Dienst eines ehemaligen GitHub-Chefs haben ihre Git-Speicherschicht aus demselben Grund umgebaut. Die Versionierung, das unspektakulärste Fundament der Branche, wird gerade für maschinelle Autoren neu gegossen.
Warum das zählt: 7,4 Milliarden Commits im Monat sind kein Produktivitätsmaß, sondern ein Lastprofil. Sie sagen, dass der Engpass der agentischen Entwicklung nicht mehr das Modell ist, sondern der Unterbau — Speicher, Nebenläufigkeit, Ratenbegrenzungen, CI-Kapazität. Wer Agenten als Feature betrachtet, plant zu klein; sie sind ein Verkehrsmuster.
Zweite Folge: Die Wahl des Defaults wird teurer. Wenn ein Monat Agentenverkehr die Plattformlast mehr als verdoppelt, dann ist „einfach auf GitHub hosten" keine neutrale Entscheidung mehr, sondern eine Kapazitätsfrage — für GitHub und für jede Firma, die ihre Agenten dort laufen lässt.
Offen bleibt die Frage, die GitHub nicht beantwortet: wie viele dieser Commits jemals von einem Menschen gelesen werden. Die Zahl misst Aktivität, nicht Fortschritt.
Quellen
- daily.devGitHub saw 7.4B commits in September, adding 4M CPU cores and 160 PB of storage (daily.dev summary)
- linkedin.comJay Parikh: Building Git infrastructure for agent-scale development
- borecraft.comGitHub is adding four million CPU cores to deal with the demand from AI (Borecraft)
- news.everythingdevops.devGitHub rewrote its storage to survive the agents (Everything DevOps)




