Scion: Warum Anthropic Git hinter sich ließ und was der Bau eines eigenen Versionskontrollsystems über die Zukunft der Softwareentwicklung verrät

Von DerSchneider

Einleitung

Im Oktober 2026 veröffentlichte Anthropic einen Engineering-Blogbeitrag, der in der Entwicklerwelt erhebliche Aufmerksamkeit erregte: Das Unternehmen hatte sein gesamtes internes Monorepo von Git auf ein selbst entwickeltes Versionskontrollsystem namens Scion migriert . Der unmittelbare Auslöser war keine Unzufriedenheit mit Git als Werkzeug, sondern eine fundamentale Verschiebung der Nutzungsrealität: Die Hauptnutzer von Anthropics Code-Repository waren nicht mehr menschliche Entwickler, die gelegentlich offline arbeiteten, sondern eine große Zahl von KI-Agenten und Automatisierungsaufgaben, die kontinuierlich online sind und Code in hoher Frequenz committen .

Dieser Artikel analysiert, warum Git unter diesen Bedingungen strukturell an seine Grenzen stieß, wie Scion technisch funktioniert, welche messbaren Verbesserungen es erzielte und welche Erkenntnisse – einschließlich der Kontroverse um die Nichtnennung von Metas Mononoke – sich daraus für die breitere Softwareentwicklung ergeben.

Die Krise der Code-Integration: Warum Git nicht mehr ausreichte

Die Dimension des Monorepos

Anthropic betreibt einen einzigen, zentralen Monorepo für seinen gesamten Code. Die offiziell genannten Zahlen sind bemerkenswert: Die History des Main-Branches umfasst knapp 100 GB, eine komprimierte Arbeitskopie über 25 GB. Allein für CI führt das Unternehmen täglich rund 25 Millionen Checkouts durch – vor Berücksichtigung von Entwicklerumgebungen, Agent-Sandboxes und Forschungsjobs. Naiv berechnet würde dies über 600 Petabyte Git-Traffic pro Tag bedeuten .

Diese 600 Petabyte sind keine tatsächlich gemessene Last, sondern eine Hochrechnung: Würde jeder CI-Job einen vollständigen Klon oder auch nur einen komprimierten Arbeitsstand ziehen, käme diese Datenmenge zustande. In der Praxis behalf sich Anthropic mit einem Arsenal an Workarounds: Shallow Clones, Sparse Checkouts, Promisor-Remotes, Snapshots in Blob-Storage und – als ultimatives Mittel – mehrere hundert Git-Mirrors, die parallel betrieben wurden . Diese Maßnahmen kauften Zeit, aber sie skalierten nicht mit dem Wachstum der Merge-Rate. Die Mirror-Flotten mussten synchron gehalten werden, Seeds fielen zunehmend hinter den Main-Branch zurück, und historienabhängige Operationen wie diff und blame wurden auf den Teilklonen zunehmend unzuverlässig .

Die Merge-Explosion als direkter Auslöser

Die entscheidende Zahl ist nicht die Größe des Repos, sondern die Geschwindigkeit, mit der Änderungen eingebracht wurden. Anthropic nennt konkrete Daten: Im Mai 2026 lag der Durchschnitt bei etwa 2.500 Merges pro Tag. Bis September 2026 stieg diese Zahl auf über 30.000 pro Tag – eine Steigerung um mehr als das Zwölffache in nur vier Monaten . Anthropic erwartet laut Blog, dass sich diese Wachstumsrate „in nächster Zeit nicht verlangsamen wird“ .

Die entscheidende Erkenntnis: Nicht das Schreiben des Codes war zum Engpass geworden, sondern die Infrastruktur drumherum. Wie DevOps.com es formulierte: „Coding stopped being the bottleneck. Source control took its place.“

Die strukturelle Ursache: Git wurde für Menschen gebaut

Anthropic erkannte, dass Gits größte Stärke – die dezentrale Offline-Fähigkeit – unter seinen Arbeitslasten zur Belastung wurde. Fast alle Clients bei Anthropic sind KI-Agenten, CI-Aufgaben und Forschungsjobs, die von Natur aus immer online sind. Ein Scion-Ingenieur erklärte auf Hacker News: „Since Claude is by far the heaviest user of Scion and is necessarily online, this just wasn’t important to do“ . Die Offline-Unterstützung, jahrzehntelang ein Kernmerkmal von Git, war für Anthropics Workload schlicht irrelevant – und die damit verbundene Architektur (vollständige Klone, Packfiles, clientseitige Berechnungen) wurde zum Hindernis.

Die technische Lösung: Scion im Detail

Grundprinzip: Client-Server statt verteilter Klone

Scion dreht das Git-Modell um: Es ist eine strikt serverzentrierte Architektur mit permanent online verbundenen Clients . Der Server übernimmt die schweren Operationen – Commits, Merges, Rebases, History-Abfragen, Blame. Der Client hält nur einen begrenzten lokalen Cache und die Dateien, die er tatsächlich benötigt .

Diese Entscheidung ermöglicht einen entscheidenden Vorteil: CI-Jobs brauchen kein lokales Repository mehr. Ein Job, der nur einen Diff oder eine Blame-Information benötigt, fragt den Server per API. Anthropic betont, dass seine automatisierten Bisect- und Revert-Pipelines ohne diese programmatisch aufrufbare Quellcode-Zugriffsmöglichkeit bei der aktuellen Skalierung nicht praktikabel wären .

Changesets statt vollständiger Trees

Der fundamentale Unterschied zu Git liegt in der Dateneinheit. Ein Git-Commit zeigt auf einen Tree – eine vollständige Momentaufnahme des Verzeichnisbaums. Ein Scion-Changeset hingegen zeichnet nur die Änderungen relativ zum ersten Parent auf und referenziert die komprimierten Blobs per Content-Address . Die Kosten eines Commits skalieren damit mit der Größe der Änderung, nicht mit der Größe des Repositories. Packfiles, wie Git sie zur effizienten Speicherung und Übertragung nutzt, existieren in Scion nicht – was auch die Notwendigkeit von Repository-Wartung (git gc) auf Client- oder Cache-Seite eliminiert .

Derived Data: Der intelligente Umgang mit abgeleiteten Informationen

Ein besonders elegantes Konzept ist die rekursive Berechnung abgeleiteter Daten. Alles, was nicht direkt Teil des Changesets ist – Blame-Informationen, Pfad-History, der Commit-Graph, Copy-Detection-Indizes – wird als „derived data“ behandelt. Jede Art abgeleiteter Daten wird rekursiv aus den Werten der Parent-Changesets berechnet, wahlweise eifrig oder verzögert .

Dieser Mechanismus hat drei Vorteile: Neue Datentypen lassen sich einfach hinzufügen, ohne die Clients zu ändern; unnötige Materialisierung wird vermieden; und die internen Datenstrukturen können optimiert werden, ohne die API zu brechen . Das Konzept ist nicht neu – es stammt konzeptionell aus Metas Mononoke – aber Scions Umsetzung ist eng mit der serverzentrierten Architektur verzahnt.

Want-only Fetch und dreistufige Cache-Hierarchie

Gits Fetch-Protokoll verhandelt, was der Client bereits hat, und der Server generiert dann dynamisch ein Packfile mit den fehlenden Objekten. Scion macht das Gegenteil: Der Client fragt ausschließlich nach Objekten, die er haben will – ausgehend von einem Root-Tree rekursiv fehlende Trees, dann Blobs. Jede Anfrage gilt einem spezifischen, unveränderlichen Objekt, das jeder Cache beantworten kann .

Die Infrastruktur ist dreistufig: scion-daemon (pro Rechenknoten) speichert Objekte für den gesamten Node; scion-cache (regional) streamt Objekte direkt aus dem Speicher; scion-server (autoritativ) liest aus Google Spanner (Metadaten) und Cloud Storage (Blobs). Jede Ebene erreicht eine Cache-Trefferquote von über 99 % und benötigt keinen langlebigen Zustand, was horizontale Skalierung trivial macht .

Die konkreten Leistungsdaten

Die 200-fache Reduktion bezieht sich auf die Infrastruktur, nicht auf einzelne Operationen . Die Checkout-Beschleunigung um zwei Größenordnungen bedeutet, dass CI-Jobs nicht mehr Minuten auf das Materialisieren eines Arbeitsverzeichnisses warten, sondern in Sekunden starten können. Allein die CI gewann dadurch 25 % ihrer CPU-Kapazität zurück .

Die Kontroverse: Inspiration oder Aneignung?

Die Anschuldigung

Zwei Tage nach Veröffentlichung des Anthropic-Blogbeitrags erhob Rain, eine ehemalige Meta-Ingenieurin und Mitdesignerin von Mononoke, den Vorwurf, Anthropic habe das Design von Mononoke ohne ausreichende Nennung übernommen . Sie veröffentlichte Side-by-Side-Vergleiche ihrer Mononoke-Dokumentation von 2022 mit Anthropics Scion-Beschreibung und argumentierte, die Ähnlichkeit gehe „weit über ähnliche Einsichten hinaus“. Der Anthropic-Blog habe Sapling für „hard-won lessons“ gedankt, Mononoke aber nicht genannt – was sie als „an Plagiat grenzend“ kritisierte .

In einem Follow-up erklärte sie, sie habe private Bestätigung erhalten, dass die Übernahme intentional gewesen sei und es personelle Überschneidungen zwischen den Teams gegeben habe . Ihr Kernargument war jedoch nicht das Kopieren guter Ideen – Mononoke sei Open Source und in den Trainingsdaten praktisch aller großen Sprachmodelle enthalten – sondern das Entfernen der Attribution: „I am completely fine with good ideas being copied. I am not fine with the serial numbers being accidentally stripped off, and I am certainly not fine with them being intentionally stripped off.“

Die Reaktion von Anthropic

Nick G., Autor des Original-Blogposts, antwortete auf Hacker News: Man habe Sapling genannt, weil Meta selbst das Gesamtsystem extern so bezeichne, einschließlich des Mononoke-Servers. Man werde eine Fußnote ergänzen, um Mononoke explizit zu nennen. Man sei „von vielen Dingen inspiriert“ worden, darunter „die großartigen Ideen in Mononokes Bonsai-Datenmodell“, und habe nicht die Absicht gehabt, das zu verschleiern. Man habe Claude nicht einfach angewiesen, ein Versionskontrollsystem zu bauen; der Ausgangspunkt eines großen Git-Repos (statt Mercurial wie bei Mononoke) habe viele Neuentwicklungen erfordert. Viele Ex-Meta-Mitarbeiter bei Anthropic seien von der Nutzungserfahrung mit Mononoke inspiriert gewesen .

Was unbestritten bleibt

Es gab keine Anschuldigung wegen Code-Kopierens – nur wegen Design-Übernahme ohne ausreichende Attribution . Die Kontroverse ändert nichts an der technischen Leistung der Migration, verschiebt aber die Erzählung: Statt „Unser KI-Agent hat ein Versionskontrollsystem von Grund auf entworfen“ lautet die genauere Version: „Wir haben bewährte, unkonventionelle Designentscheidungen von Mononoke mit KI-Unterstützung effizient reimplementiert und an unsere Git-basierten Bedürfnisse angepasst.“ Beides ist beeindruckend – aber nur Letzteres ist ehrlich.

Die menschliche Dimension: Ingenieure bleiben unverzichtbar

Ein besonders aufschlussreicher Teil des Berichts betrifft die Rolle der Ingenieure. Scion wurde von einem siebenköpfigen Team in fünf Monaten entwickelt – unterstützt durch Claude. Alle beteiligten Ingenieure gaben laut Anthropic an, dass Claude inzwischen besser Code schreibe als sie selbst .

Und dennoch: Die Ingenieure blieben entscheidend. Ihre Rolle verschob sich von der Code-Produktion zur Architektur, Systemverständnis und Urteilsvermögen. Anthropic formuliert es so: „Sehr oft war die Rolle der Ingenieure, Claude ‚Nein‘ zu sagen.“ Agenten neigten dazu, durch übertrieben defensives Adversarial Review Teile des Systems zu überengineeren. Erfahrene Ingenieure mussten eingreifen und die Richtung vorgeben . Dieses Muster – KI beschleunigt die Implementierung, Menschen liefern das Urteilsvermögen – ist vielleicht die nachhaltigste Erkenntnis des gesamten Berichts.

Einordnung und Ausblick

Scion ist nicht das erste maßgeschneiderte Versionskontrollsystem für riesige Monorepos. Google betreibt Piper für rund zwei Milliarden Zeilen Code in neun Millionen Dateien (Stand 2016), Meta entwickelte Sapling über etwa ein Jahrzehnt . Was Scion unterscheidet, ist weniger die Architektur – Simon Willison merkt an, Scion wirke wie „eine Neuinterpretation zentralisierter Versionskontrolle im Stil von Subversion“ – als vielmehr die Geschwindigkeit und der Kontext der Entstehung: fünf Monate, sieben Personen, KI-gestützte Implementierung.

Anthropic stellt Scion nicht als Open Source bereit, weil es „zu eng an die firmeninternen Strukturen geknüpft“ sei . Der Blogbeitrag ist daher kein Produktlaunch, sondern ein Erfahrungsbericht – eine Einladung an andere Organisationen, aus den Designentscheidungen zu lernen. Die Empfehlung an die Industrie ist pragmatisch: Bestehende Git-Plattformen sollten serverseitige RPC-Schnittstellen und bessere Kombinationen aus Sparse- und Shallow-Checkouts anbieten, um agentische Workloads besser zu unterstützen .

Die tiefere Botschaft ist jedoch unbequemer: Die Geschwindigkeit, mit der KI Code produziert, verschiebt den Engpass von der Code-Erstellung zur Code-Integration. Wer agentische Workflows einführt, ohne die umgebende Infrastruktur anzupassen, wird früher oder später dieselbe Wand erreichen. Scion selbst werden die meisten nie nutzen. Aber die Prinzipien dahinter – serverzentrierte Berechnung, Changesets statt vollständiger Trees, abgeleitete Daten als rekursive Berechnung, want-only Fetch – sind übertragbar. Und sie markieren einen Wendepunkt: Zum ersten Mal hat ein Unternehmen ein grundlegendes Stück Entwicklerinfrastruktur primär deshalb neu gebaut, weil Maschinen die Hauptnutzer sind.

Fazit

Anthropics Scion ist eine technisch beeindruckende, konsequent zu Ende gedachte Antwort auf ein Problem, das erst durch agentische KI entstanden ist: Git wurde für Menschen gebaut, die gelegentlich offline arbeiten, vollständige Klone halten und in menschlichem Tempo committen. Als diese Annahmen nicht mehr zutrafen, wurde Gits größte Stärke zur Last. Scion löst das durch radikale Zentralisierung: Der Server tut die Arbeit, der Client hält nur, was er braucht. Die Ergebnisse – 200× weniger Infrastruktur, Checkouts in Sekunden statt Minuten, 12× mehr Merges – sind beeindruckend, aber nicht direkt übertragbar. Was übertragbar ist, sind die Designprinzipien und die Erkenntnis, dass Ingenieure in einer von Agenten dominierten Entwicklungsumgebung nicht an Bedeutung verlieren, sondern ihre Rolle sich verschiebt: vom Code-Schreiben zum System-Denken und zum souveränen „Nein“-Sagen, wenn Agenten über das Ziel hinausschießen. Die Mononoke-Kontroverse mahnt zugleich, dass die Attribution von Ideen in einer Welt, in der KI bestehende Designs reproduziert, wichtiger wird, nicht weniger.

Quellen

1. Anthropic Engineering: „Redesigning source control at Anthropic“, 12.10.2026. https://www.anthropic.com/engineering/redesigning-source-control
2. Simon Willison’s Weblog: „Redesigning source control at Anthropic“, 13.10.2026. https://simonwillison.net/2026/Oct/13/redesigning-source-control-at-anthropic/
3. Hacker News Diskussion: „More on Anthropic’s Scion ripping off Mononoke“, 15.10.2026. https://hn.nuxt.dev/item/50106738
4. iThome: „Anthropic自建Scion取代Git，CI取出程式碼時間從數分鐘縮至數秒“, 15.10.2026. https://www.ithome.com.tw/news/179733
5. explainx.ai: „Anthropic Scion and Meta’s Mononoke: The Attribution Dispute, Claimed vs Verified“, 14.10.2026. https://explainx.ai/blog/anthropic-scion-mononoke-attribution-dispute-bonsai-sapling-credit-claimed-vs-verified-2026
6. HTX Insights: „7 People, 5 Months: Anthropic Built a Git Replacement“, 13.10.2026. https://www.htx.com/uk-ua/news/7-people-5-months-anthropic-built-a-git-replacement-VgtzsUTR/
7. DEV Community: „When AI Rebuilds Your Work Without Credit: The Scion-Mononoke Story“, 15.10.2026. https://dev.to/gabby_six/when-ai-rebuilds-your-work-without-credit-the-scion-mononoke-story-268f
8. DevOps.com: „Anthropic Builds Its Own Source Control After AI Agents Outgrow Git“, 13.10.2026. https://devops.com/anthropic-builds-its-own-source-control-after-ai-agents-outgrow-git
9. heise online: „Scion: Anthropic’s lean Git alternative for agentic workflows“, 14.10.2026. https://www.heise.de/en/news/Scion-Anthropic-s-lean-Git-alternative-for-agentic-workflows-11489274.html
10. 36Kr: „Anthropic Develops Innovative Git Alternative with 7-Person Team in Just 5 Months“, 13.10.2026. https://eu.36kr.com/en/p/4025436652425094