30.000 gemergte Code-Änderungen pro Tag, fast 100 Gigabyte Repository-Historie und 25 Millionen Checkouts täglich, mit diesen Zahlen hätte ein klassisches Git-Setup längst kapituliert. Genau das ist bei Anthropic passiert. Die Antwort des Unternehmens heißt Scion, ein komplett neu entwickeltes Versionskontrollsystem, das Git im internen Monorepo vollständig ersetzt hat. Die Einführung der Anthropic Scion Versionskontrolle markiert damit einen der bislang deutlichsten Belege dafür, wie stark autonom arbeitende KI-Agenten die Grundfesten klassischer Softwareentwicklung ins Wanken bringen können.
Der Fall ist deshalb bemerkenswert, weil er nicht aus einem akademischen Gedankenexperiment stammt, sondern aus der täglichen Praxis eines Unternehmens, dessen eigenes KI-Modell Claude in großem Stil selbst Code schreibt. Laut dem offiziellen Anthropic Engineering Blog vom 13. Oktober 2026 wuchs das Volumen der täglichen Code-Merges zwischen Mai und September 2026 von rund 2.500 auf über 30.000, eine Verzehnfachung innerhalb weniger Monate. Unabhängige Berichterstattung, unter anderem von dev.to und ai-tldr.dev, bestätigt diese Darstellung.
Inhaltsverzeichnis
Key Takeaways
- Anthropic hat sein internes Monorepo innerhalb von fünf Monaten vollständig von Git auf das selbst entwickelte System Scion migriert.
- Auslöser war ein durch Claude getriebenes Wachstum der täglichen Code-Merges von etwa 2.500 auf über 30.000.
- Scion setzt auf permanent verbundene Clients, eine starke Client-Server-Asymmetrie und horizontale Skalierbarkeit statt vollständiger lokaler Kopien.
- Der Infrastruktur-Footprint für Versionskontrolle sank laut Anthropic um das 200-fache gegenüber den vorherigen Git-Mirrors.
- Scion wird nicht als Open Source veröffentlicht und ist nicht als allgemeiner Git-Ersatz gedacht, sondern nur für extrem große Monorepos relevant.
Warum Git im KI-Zeitalter an seine Grenzen stößt
Git wurde ursprünglich für eine Welt entworfen, in der menschliche Entwickler gelegentlich offline arbeiten, lokale Kopien des gesamten Repositorys halten und Commits in überschaubarer Zahl erzeugen. Dieses Modell funktionierte über Jahrzehnte hinweg zuverlässig, auch bei sehr großen Projekten.
Bei Anthropic kippte dieses Gleichgewicht jedoch binnen weniger Monate. Der entscheidende Faktor war nicht mehr die Zahl menschlicher Entwickler, sondern die Menge an Code, die Claude selbst autonom produzierte. Agentensysteme arbeiten rund um die Uhr, erzeugen parallel unzählige Codeänderungen und benötigen dafür ständig neue, isolierte Arbeitsumgebungen. Jede dieser Sandboxes braucht einen eigenen Checkout des Repositorys.
Die daraus resultierende Last macht die Dimension des Problems deutlich:
- Die Historie des Haupt-Branches umfasst inzwischen fast 100 Gigabyte.
- Eine komprimierte Arbeitskopie liegt bei über 25 Gigabyte.
- Es gibt rund 25 Millionen Code-Checkouts pro Tag, verteilt auf Continuous-Integration-Systeme, Agenten-Sandboxes und Entwicklerumgebungen.
- Würde man diese Checkouts naiv per klassischem Git-Clone bedienen, entstünden daraus mehr als 600 Petabyte Traffic, pro Tag.
Um diese Last überhaupt zu bewältigen, betrieb Anthropic zuvor mehrere hundert interne Git-Mirrors. Dieses Modell wurde laut Unternehmensangaben zunehmend unpraktikabel: Der Betriebsaufwand, die Synchronisationsprobleme und die schiere Menge an redundanter Infrastruktur standen in keinem vernünftigen Verhältnis mehr zum Nutzen.
Die Architektur der Anthropic Scion Versionskontrolle im Detail
Statt Git weiter zu patchen, entschied sich das verantwortliche Team für einen radikalen Neuanfang. Die Grundannahmen von Scion unterscheiden sich fundamental von denen klassischer Versionskontrollsysteme.
Immer online statt Offline-First
Git wurde für Entwickler entworfen, die auch ohne Internetverbindung arbeiten können müssen. Diese Annahme ist in einer Welt, in der sowohl menschliche Entwickler als auch KI-Agenten praktisch durchgehend vernetzt arbeiten, nicht mehr zwingend notwendig. Scion geht deshalb davon aus, dass Clients permanent online sind, und kann dadurch auf viele der Mechanismen verzichten, die Git für Offline-Fähigkeit vorhält.
Client-Server-Asymmetrie statt Gleichverteilung
In Git tragen Client und Server im Prinzip dieselbe Last: Jeder Client hält eine vollständige Kopie der Historie und kann Commits, Merges und Rebases lokal durchführen. Scion bricht bewusst mit diesem Symmetrie-Prinzip. Die rechenintensiven Operationen, Commits, Merges, Rebases, übernimmt der Server. Der Client hält lediglich einen begrenzten lokalen Cache.
Horizontale Skalierbarkeit ohne vollständige Repo-Kopie
Ein zentrales Designziel war, dass nirgendwo im System eine vollständige Kopie des gesamten Repositorys vorgehalten werden muss. Stattdessen ist die gesamte Architektur horizontal skalierbar aufgebaut. Das erlaubt es, die Last auf viele kleinere, austauschbare Komponenten zu verteilen, anstatt auf wenige große Mirrors angewiesen zu sein.
Sparse Working Copies als Standard
Auch die Arbeitskopie selbst ist in Scion optional und "sparse" angelegt. Das bedeutet: Nur die tatsächlich benötigten Verzeichnisse werden auf der lokalen Festplatte materialisiert. Bei einem Monorepo dieser Größenordnung ist das ein entscheidender Unterschied, niemand benötigt für eine einzelne Aufgabe wirklich den kompletten Codebestand des Unternehmens lokal vorliegen.
"Scion ist für Clients gebaut, die immer online sind, und für Server, die die schwere Arbeit übernehmen, nicht umgekehrt." Diese Umkehrung des klassischen Git-Modells ist der Kern der gesamten Architektur.
Changesets statt klassischer Commits
Die fundamentale Dateneinheit in Scion heißt Changeset. Anders als ein klassischer Git-Commit, der oft implizit den gesamten Baumzustand referenziert, speichert ein Changeset nur die tatsächlich geänderten Dateien relativ zum ersten Parent.
Technisch handelt es sich dabei um einen Eintrag in einem Write-Ahead-Log. Jedes Changeset enthält inhaltsadressierte Zeiger auf einen separaten Blob-Storage. Dieser Ansatz hat mehrere Vorteile für ein System dieser Größenordnung:
| Merkmal | Klassisches Git | Scion-Changeset |
|---|---|---|
| Referenzierte Daten | Oft vollständiger Baumzustand | Nur geänderte Dateien zum ersten Parent |
| Speichermechanismus | Objektdatenbank lokal beim Client | Inhaltsadressierter Blob-Storage, serverseitig |
| Protokollstruktur | Verteilte Objekt-Historie | Write-Ahead-Log als Kernstruktur |
| Skalierungsrichtung | Vertikal, pro Repo-Kopie | Horizontal, über viele Server verteilt |
Durch diese Struktur lässt sich die Historie effizienter verwalten, ohne dass jeder Client oder Server die komplette Kette aller jemals vorgenommenen Änderungen physisch vorhalten muss.
Mehr als nur Versionskontrolle: Das gesamte Toolkit
Interessant ist, dass Scion nicht als isoliertes Projekt entstand. Im selben Fünf-Monats-Zeitraum baute das Team parallel drei weitere Komponenten, die eng mit der neuen Versionskontrolle zusammenspielen:
- Antique: ein Code-Review-Tool, das speziell für die Prüfung KI-generierter Änderungen im großen Maßstab konzipiert wurde. Bei zehntausenden täglichen Merges reicht ein klassischer Pull-Request-Workflow nicht mehr aus. Ein verwandtes Beispiel für agentenfreundliche Entwicklerwerkzeuge bei Anthropic sind Claude Code Mods, Anthropics TypeScript-Erweiterungssystem für den eigenen KI-Coding-Agenten.
- Eine neue Code-Suche: notwendig, weil klassische Suchindizes bei einem derart schnell wachsenden Monorepo schnell veralten oder zu langsam werden.
- Ein IAM-System für Source Control: zur granularen Steuerung, wer, ob Mensch oder Agent, welche Zugriffsrechte auf welche Teile des Repositorys hat.
Diese vier Komponenten zusammen bilden das, was Anthropic als neue Grundlage für Softwareentwicklung im Zeitalter großflächiger KI-Codegenerierung versteht.
Wer hat Scion gebaut?
Bemerkenswert ist auch der Umfang des Teams im Verhältnis zur Tragweite des Projekts. Die komplette Migration von Git zu Scion, inklusive der drei Zusatztools, wurde von lediglich sieben Ingenieuren realisiert. Als Hauptautor wird Nick G. genannt, das übrige Team bestand aus S.G., R.K., Dan C., Garrett H., Ben L., Colin M. und Joe P.
Dass ein derart kleines Team innerhalb von fünf Monaten ein produktionsreifes Versionskontrollsystem für ein Unternehmen dieser Größe bauen konnte, wird von Anthropic selbst auch als Beleg für die Produktivitätssteigerung durch KI-gestützte Entwicklung verstanden, wenngleich der Blogbeitrag hierzu keine zusätzlichen quantitativen Angaben macht, die über die genannten Fakten hinausgehen.
Der gemessene Effekt: 200-facher Effizienzgewinn
Der wohl greifbarste Fakt aus der Ankündigung betrifft die Infrastrukturkosten. Anthropic gibt an, dass Scion den Infrastruktur-Footprint für Versionskontrolle um das 200-fache gegenüber dem vorherigen Setup mit mehreren hundert Git-Mirrors reduziert. Diese Zahl verdeutlicht, wie ineffizient das alte Mirror-basierte Modell im Verhältnis zu den tatsächlichen Anforderungen eines KI-getriebenen Entwicklungsprozesses geworden war.
Scion im Vergleich: Piper, Sapling und die Grenzen der Übertragbarkeit
Anthropic ist nicht das erste Unternehmen, das an den Grenzen von Git für extrem große Monorepos gearbeitet hat. Google betreibt seit Langem sein eigenes System namens Piper, Meta hat mit Sapling eine vergleichbare Eigenentwicklung für seine Monorepo-Struktur geschaffen. Beide Systeme folgen einem ähnlichen Grundgedanken: Bei Repositorys mit zehntausenden Entwicklern und Millionen Dateien stößt das klassische, dezentrale Git-Modell an strukturelle Grenzen.
Anthropic reiht sich mit Scion also in eine bestehende Tradition großer Technologieunternehmen ein, die eigene Versionskontrollsysteme für ihre spezifischen Skalierungsanforderungen entwickelt haben. Der entscheidende neue Faktor bei Anthropic ist jedoch, dass nicht primär das Wachstum menschlicher Entwicklerteams der Auslöser war, sondern das Wachstum autonom arbeitender KI-Agenten.
Wichtig für die Einordnung: Anthropic stellt ausdrücklich klar, dass Scion nicht als Open Source veröffentlicht wird und auch nicht als allgemeiner Git-Ersatz für normale Unternehmen gedacht ist. Die Anthropic Scion Versionskontrolle lohnt sich laut eigener Aussage nur für extrem große Monorepos mit zehntausenden Entwicklern oder mit Schwärmen von KI-Agenten, die in vergleichbarem Umfang Code erzeugen. Für den Großteil der Softwarebranche bleibt Git also weiterhin die sinnvolle Wahl.
Gleichzeitig kündigt Anthropic an, gewonnene Erkenntnisse mit der breiteren Git-Community sowie mit Anbietern wie GitHub und GitLab teilen zu wollen. Konkret genannt werden dabei Ideen wie serverseitige RPCs und generell bessere Skalierungsmechanismen für Git-Server. Das deutet darauf hin, dass zumindest Teilaspekte der Scion-Architektur mittelfristig auch in bestehende, weit verbreitete Werkzeuge einfließen könnten, ohne dass Scion selbst als eigenständiges Produkt am Markt erscheinen wird.
Warum das für andere Unternehmen relevant werden könnte
Auch wenn Scion selbst kein Produkt für den breiten Markt wird, ist die zugrunde liegende Entwicklung für viele technisch orientierte Organisationen von Bedeutung. Immer mehr Unternehmen setzen KI-Agenten nicht mehr nur als Autovervollständigung ein, sondern lassen sie eigenständig Pull Requests erstellen, Tests schreiben und Code refaktorieren. Sobald diese Agenten in größerer Zahl parallel arbeiten, steigt die Zahl der Commits, Branches und Checkouts in einem Tempo, das klassische Versionskontroll-Infrastruktur nicht ohne Weiteres mittragen kann.
Relevante Lehren aus dem Anthropic-Fall für andere Teams:
- Die Belastung durch CI-Systeme und automatisierte Checkouts wächst oft schneller als die Belastung durch menschliche Nutzer, das sollte frühzeitig in der Kapazitätsplanung berücksichtigt werden.
- Mirror-basierte Skalierungsansätze stoßen bei exponentiellem Wachstum schnell an wirtschaftliche und betriebliche Grenzen.
- Sparse Checkouts und serverseitige Verarbeitung können schon innerhalb des bestehenden Git-Ökosystems helfen, bevor ein komplett neues System notwendig wird.
- Code-Review-Prozesse müssen überdacht werden, sobald ein erheblicher Teil der Änderungen nicht mehr von Menschen, sondern von Agenten stammt.
Fazit und nächste Schritte
Der Fall der Anthropic Scion Versionskontrolle zeigt exemplarisch, wie grundlegend sich Entwicklungsprozesse verändern können, sobald KI-Agenten nicht nur unterstützend, sondern in großem Stil selbst Code produzieren. Innerhalb von fünf Monaten und mit einem vergleichsweise kleinen Team von sieben Ingenieuren hat Anthropic nicht nur ein neues Versionskontrollsystem gebaut, sondern gleich ein ganzes begleitendes Toolkit aus Code-Review, Code-Suche und Zugriffsverwaltung.
Für die meisten Unternehmen besteht aktuell kein Anlass, Git zu ersetzen. Für technische Entscheidungsträger lohnt es sich dennoch, die eigene Infrastruktur kritisch zu prüfen: Wie würde das bestehende Versionskontrollsystem reagieren, wenn die Zahl der täglichen Code-Änderungen innerhalb weniger Monate um das Zehnfache steigen würde? Wer diese Frage nicht zuverlässig beantworten kann, sollte frühzeitig Skalierungsreserven einplanen, serverseitige Verarbeitung und sparse Checkouts evaluieren und die eigenen CI- und Review-Prozesse auf ein mögliches Wachstum durch KI-Agenten vorbereiten, lange bevor ein Umbau wie bei Anthropic überhaupt notwendig wird.
