Wenn Git an seine Grenze kommt: Warum Anthropic die Versionsverwaltung neu gebaut hat

Git gilt seit Jahren als gesetzt. Für die meisten Teams auch zu Recht. Aber es gibt eine Größenordnung, in der die klassische Architektur sichtbar knirscht. Genau dort setzt der Fall von Anthropic an: Bei rund 30.000 Merges pro Tag und massivem CI-Verkehr wurde aus einem bewährten Werkzeug ein Engpass.

Der interessante Punkt ist nicht, dass Git „schlecht“ wäre. Das wäre eine billige Schlussfolgerung. Die eigentliche Lehre ist eine andere: Git wurde für verteilte Entwicklung gebaut, nicht für eine Infrastruktur, in der gigantische Mengen automatisierter Builds, Reads und Repository-Operationen auf wenigen zentralen Systemen aufschlagen. Packfiles sind stark, solange ihre Stärken zu den Zugriffsmustern passen. Wenn diese Muster kippen, wird aus Effizienz schnell Reibung.

Genau deshalb ist die Entscheidung für einen Ersatz technisch bemerkenswert. Mit Scion auf Cloud Spanner geht es offenbar nicht um ein kleines Tuning, sondern um einen Architekturwechsel. Weg von einem Dateiformat und Datenzugriff, der historisch für Source-Code-Verteilung optimiert wurde. Hin zu einem System, das hohe Parallelität, zentrale Konsistenz und extreme Last besser tragen soll.

Für Entwicklerteams ist das mehr als eine exotische Spezialgeschichte aus dem KI-Umfeld. Der Fall zeigt, wie sich Werkzeuge ändern müssen, wenn Softwareentwicklung selbst industrialisiert wird. Wer zehntausende Integrationen pro Tag fährt, betreibt Versionsverwaltung nicht mehr nur als Entwickler-Tool, sondern als Kern einer Produktionsplattform. Dann zählen andere Dinge: Latenz unter Dauerlast, verlässliche Skalierung, kontrollierbare Infrastrukturkosten und saubere Datenzugriffe für Automatisierung.

Cloud Spanner als Basis ist dabei ein klares Signal. Das Problem wurde offenbar nicht als lokales Git-Problem betrachtet, sondern als Datenbank- und Verteilungsproblem. Das ist ein harter Schnitt. Er zeigt auch, wie weit sich große KI- und Plattformfirmen inzwischen von Standard-Developer-Workflows entfernen. Was für normale Engineering-Teams ein Repository ist, wird dort zu einer global belasteten Datenebene.

Wichtig ist die Einordnung: Das ist kein Beleg dafür, dass Git vor dem Aus steht. Für fast alle Unternehmen bleibt Git das richtige Werkzeug. Aber der Fall markiert eine Grenze. Wenn Merge-Frequenz und CI-Verkehr in extreme Bereiche wachsen, reichen inkrementelle Optimierungen irgendwann nicht mehr. Dann hilft auch viel Git-Erfahrung wenig, weil das Grundmodell selbst zum Flaschenhals wird.

Genau darin liegt die eigentliche Nachricht. Nicht das Namedropping um Scion oder Spanner ist entscheidend, sondern die Erkenntnis, dass Versionsverwaltung unter KI- und Hyperscale-Bedingungen eine neue Klasse von Infrastruktur wird. Und sobald das passiert, wird aus einem Entwicklerwerkzeug ein verteiltes Datensystem.