Scion soll Anthrophics Codeflut beherrschbar machen
Anthropic hat sein bisheriges Versionskontrollsystem durch eine maßgeschneiderte Infrastruktur namens Scion ergänzt. Auslöser war ein massiver Anstieg der intern produzierten Softwareänderungen. Zwischen Mai und September 2026 wuchs die Zahl der täglich zusammengeführten Änderungen von rund 2.500 auf mehr als 30.000.
Damit verschob sich der Engpass. Nicht mehr das Schreiben von Code begrenzte die Produktivität, sondern dessen Verwaltung, Prüfung und Integration. Versionskontrolle, Build-Systeme und CI/CD, also die automatisierte Prüfung und Auslieferung von Software, mussten mit der Leistung der Coding-Agenten Schritt halten.
| Kennzahl | Wert |
|---|---|
| Gemergte Änderungen im Mai 2026 | rund 2.500 pro Tag |
| Gemergte Änderungen im September 2026 | mehr als 30.000 pro Tag |
| Wachstum | Faktor 12 |
| Größe des Main Branch | rund 100 GB |
| Komprimierte Arbeitskopie | mehr als 25 GB |
| CI-Checkouts | rund 25 Millionen pro Tag |
| Theoretischer Git-Datenverkehr | mehr als 600 PB pro Tag |
Im Mai 2026 wurden bei Anthropic durchschnittlich rund 2.500 Codeänderungen pro Tag zusammengeführt. Im September waren es bereits mehr als 30.000, so das Unternehmen sinngemäß.
Warum Git bei Anthropic an Grenzen stieß
Git ist dezentral aufgebaut und legt üblicherweise umfangreiche lokale Kopien eines Repositorys an. Dieses Prinzip eignet sich nach Einschätzung von Anthropic weiterhin für die meisten Projekte. Bei einem Main Branch von rund 100 GB und Millionen automatisierten Arbeitsumgebungen pro Tag entsteht jedoch eine ungewöhnlich hohe Synchronisationslast.
Anthropic führt täglich etwa 25 Millionen Checkouts allein für seine CI-Systeme aus. Entwicklerumgebungen, Agenten-Sandboxes und Forschungsaufgaben sind darin noch nicht enthalten. Ohne Optimierungen hätte das vollständige Abrufen der Daten theoretisch mehr als 600 PB Git-Datenverkehr pro Tag verursacht.
Auch andere Plattformen müssen ihre Infrastruktur an automatisch erzeugte Änderungen anpassen. GitHub baut beispielsweise seinen Git-Speicher für KI-Agenten um. Bereits im April 2026 hatte die Plattform Verfügbarkeitsprobleme mit dem exponentiellen Wachstum von Commits und Pull Requests in Verbindung gebracht.
Scion verlagert die Arbeit auf zentrale Server
Die Entwicklung von Scion begann im Januar 2026, die Migration dauerte fünf Monate. Das System verwaltet den Code in einem zentralen Monorepo und ähnelt damit strukturell klassischen zentralen Versionskontrollsystemen wie Subversion. Ergänzend entstanden Antique für Code-Reviews sowie eigene Werkzeuge für Codesuche und Identitäts- und Zugriffsverwaltung.
Scion ist auf die Arbeitsweise von KI-Agenten zugeschnitten. Statt vollständige Repositorys lokal zu klonen, greifen interne Werkzeuge über serverzentrierte APIs auf die benötigten Informationen zu. Dadurch sinkt der Synchronisationsaufwand, während Leistungsfähigkeit und Verfügbarkeit der zentralen Server wichtiger werden.
Die Arbeitseinheit von Scion ist ein Changeset. Es wird in einem Write-Ahead Log gespeichert, einem Änderungsprotokoll, das neue Operationen vor ihrer endgültigen Verarbeitung festhält. Anders als ein Git-Commit verweist ein Changeset nicht auf einen vollständigen Dateibaum, sondern enthält die geänderten Dateien und Verweise auf komprimierte Inhalte im Objektspeicher.
Claude optimierte seine eigene Infrastruktur
Ein internes Modell namens Claude Mythos Preview schrieb zentrale Teile einer frühen Datenpipeline für die Übernahme von Git-Daten in Scion eigenständig um. Laut Anthropic benötigte die neue Fassung 20-mal weniger Arbeitsspeicher und lief viermal schneller.
| Optimierung | Ergebnis |
|---|---|
| Arbeitsspeicher | 20-mal geringerer Bedarf |
| Verarbeitungsgeschwindigkeit | 4-mal höher |
Was technisch hinter Claude Mythos Preview steckt, ist nicht bekannt. Ebenso gibt es keine bestätigten Angaben dazu, ob das Modell öffentlich angeboten wird. Anthropic nennt auch keine Kosten für Entwicklung, Modellnutzung oder laufenden Betrieb von Scion.
Der Vorgang zeigt dennoch einen wichtigen Kreislauf. Coding-Agenten erzeugen so viel Software, dass neue Werkzeuge für deren Verwaltung notwendig werden. Anschließend entwickeln und optimieren dieselben Modelle Teile dieser Werkzeugkette. Die Frage nach der Wirtschaftlichkeit lässt sich ohne Angaben zum Rechenaufwand allerdings nicht beantworten.
Entwickler werden zu Architektur-Gatekeepern
Die menschliche Arbeit verschob sich bei Scion vor allem auf Architekturkontrolle und Qualitätssicherung. Entwickler mussten prüfen, ob ein Vorschlag zu den grundlegenden Systemregeln passt. Anthropic beschreibt ihre Rolle deshalb teilweise als die eines Neinsagers.
Sehr oft bestand die Rolle der Entwickler darin, Claude mit einem Nein zu stoppen. Agenten verletzen mitunter zentrale Systemvorgaben, um ein Muster umzusetzen, das nie hätte zugelassen werden dürfen, erklärte Anthropic sinngemäß.
Dieser Befund passt zur breiteren Entwicklung beim Vertrauen in KI-generierten Code. Eine hohe Produktionsgeschwindigkeit ersetzt weder Architekturentscheidungen noch belastbare Reviews. Im Gegenteil steigt der Prüfaufwand, wenn Agenten parallel große Mengen plausibel wirkenden Codes liefern.
Was Scion für Unternehmen im DACH-Raum bedeutet
Die meisten Unternehmen verwalten weder einen 100 GB großen Hauptzweig noch 25 Millionen CI-Checkouts pro Tag. Der grundlegende Effekt tritt jedoch deutlich früher ein. Sobald mehrere Coding-Agenten dauerhaft Änderungen erzeugen, verlagern sich Kosten und Engpässe in Reviews, Tests, Build-Systeme und Zugriffssteuerung.
Für Eigenentwicklungen bedeutet das, dass klassische Git- und CI/CD-Prozesse nicht automatisch mit der Codeproduktion skalieren. Sinnvoll sind klare Architekturregeln, begrenzte Agentenrechte, automatisierte Tests und verbindliche Freigaben. Andernfalls wird günstiger erzeugter Code durch hohe Integrations- und Betriebskosten relativiert.
Scion selbst wird dabei keine unmittelbar verfügbare Alternative zu Git. Anthropic plant keine Open-Source-Veröffentlichung, weil das System stark auf die eigenen Abläufe zugeschnitten ist. Unternehmen bleiben damit entweder bei bestehenden Werkzeugen, skalieren diese gezielt oder entwickeln Teile der Infrastruktur selbst.
Der Fall stärkt zwar das Argument für KI-gestützte Eigenentwicklung statt zusätzlicher Standard-SaaS-Abos. Gleichzeitig zeigt er deren organisatorischen Preis. Weniger Aufwand beim Schreiben von Software bedeutet nicht automatisch weniger Aufwand insgesamt, sondern verschiebt ihn zu Architektur, Kontrolle und Plattformbetrieb.