Kurzantwort: Anthropic Scion ist das hauseigene Versionskontrollsystem, das Anthropic entwickelte, nachdem Coding-Agents die täglichen Merges im Monorepo von etwa 2.500 im Mai 2026 auf über 30.000 im September ansteigen ließen. Scion führt Commits, Merges und Rebases serverseitig aus. Es wird ausschließlich intern genutzt, und Anthropic betont, dass es kein allgemeiner Ersatz für Git ist.
Was Anthropic mit Scion gemacht hat – und warum
Am 13. Oktober 2026 veröffentlichte das Engineering-Team von Anthropic den Artikel Redesigning source control at Anthropic. Die zentrale These zu Beginn ist unmissverständlich: „Das Schreiben von Code ist nicht länger der Engpass beim Aufbau von Systemen oder in der Forschung.“ Der eigentliche Engpass sei vielmehr „die gesamte Entwickler-Infrastruktur, die für menschliche Maßstäbe gebaut wurde: Versionskontrolle, Builds und CI.“
Die Zahlen verdeutlichen das Problem: Im Mai 2026 führte das Unternehmen rund 2.500 Code-Merges pro Tag durch. Bis September stieg diese Zahl auf über 30.000. Das entspricht einer Verzwölffachung innerhalb von nur vier Monaten – ein Zuwachs, den Anthropic direkt auf den Einsatz autonomer Coding-Agents zurückführt.
Für menschliche Dimensionen reichte Git völlig aus. Bei der Skalierung durch Agents geriet es jedoch an seine Grenzen. Anthropic berichtet von rund 25 Millionen CI-Checkouts pro Tag, einer Historie des Main-Branch von knapp 100 GB und in Spitzenzeiten mehreren Hundert internen Git-Mirrors. Eine naive Fetch-Strategie hätte täglich über 600 PB an Git-Traffic verursacht.
Ein siebenköpfiges Team entwickelte daher Scion, ein Code-Review-Tool namens Antique, eine Code-Suche sowie ein Zugriffssteuerungssystem auf Verzeichnisebene. Innerhalb von fünf Monaten migrierten sie das Monorepo weg von Git. Anthropic ließ sogar Claude Mythos Preview die Ingestion-Pipeline von Git zu Scion neu schreiben – die Neufassung verbrauchte 20-mal weniger Speicher und lief viermal schneller.
Wenn Sie Claude Code, Codex oder andere Coding-Agents im Team einsetzen, gibt dieser Beitrag einen Vorgeschmack auf Ihren nächsten Engpass. Sharkly wurde genau für dieses Problem entwickelt: Es bündelt die Arbeit, Ergebnisse und Reviews von Agents in gemeinsamen Tasks, statt sie über verstreute Terminals zu verteilen.
Wie sich Scion von Git unterscheidet
Git geht davon aus, dass jeder Klon eine vollständige, autarke Kopie der Historie ist, die offline funktioniert. Scion setzt auf das genaue Gegenteil: Clients sind permanent online und führen lokal kaum Rechenoperationen aus.
| Git | Anthropic Scion | |
|---|---|---|
| Wo Commits, Merges und Rebases ausgeführt werden | Lokal auf dem eigenen Rechner | Auf dem Server |
| Lokale Daten | Vollständige Historie | Ein begrenzter Objekt-Cache, Sparse- oder virtualisierter Checkout |
| Arbeitseinheit | Commit, der auf einen Tree verweist | Changeset in einem Write-Ahead-Log mit Auflistung der geänderten Dateien |
| Branches und Refs | Günstig und empfohlen | Nicht empfohlen (außer Main- und Release-Branches) |
| Fetch | Packfiles | Pro Objekt (erst Trees, dann Blobs), keine Repository-Wartung |
| Offline-Arbeit | Ja | Nein |
| Haupt-Clients | Menschen | Agents, CI- und Forschungs-Jobs |
Die Architektur besteht aus drei Ebenen: scion-daemon auf jedem Node, scion-cache pro Region und einem autoritativen scion-server. Das Client-CLI lautet scn. Die Cache-Hit-Rate liegt auf jeder Ebene bei über 99 %.
Der Nutzen ist enorm: Der CPU- und Speicherbedarf ist 200-mal geringer als beim bisherigen Git-Mirroring-Setup. Checkouts für CI und Forschungs-Jobs dauern nur noch Sekunden statt Minuten, und die CI gewann 25 % an CPU-Kapazität hinzu.
Worauf man bei serverseitigen Commits verzichten muss
Mit serverseitigen Commits gibt man genau die Eigenschaft auf, die Git einst zum Durchbruch verhalf: eine vollständige lokale Historie, mit der man selbst im Flugzeug offline arbeiten kann. Anthropic spricht das ganz offen an: Scion sei „keineswegs ein geeigneter Ersatz für Git im allgemeinen Gebrauch“, und es in einer Form bereitzustellen, die andere Organisationen nutzen könnten, wäre extrem schwierig. Es ist nicht veröffentlicht, und der Beitrag beschreibt es auch nicht als Open Source.
Auch das Konzept für Nebenläufigkeit unterscheidet sich von den üblichen Erwartungen: Anthropic serialisiert Merges nicht hinter einem globalen Lock. Gleichzeitige Änderungen können durchaus kollidieren – das Team fängt solche Konflikte jedoch durch automatisierte Tests nach dem Merge und vor dem Deployment ab.
Git für KI-Agents: Was Teams ohne Scion daraus lernen können
Sie werden Scion nicht bekommen – und Sie brauchen es auch nicht. Ihr Repository ist keine 100 GB groß, und Sie führen keine 25 Millionen Checkouts am Tag durch. Der entscheidende Erkenntnisgewinn des Beitrags liegt in der Struktur des Problems, denn diese zeigt sich in jedem Maßstab.
Wenn Agents den Code schreiben, verlagert sich der Engpass nach hinten im Prozess: zuerst auf das Mergen, dann auf das Review. Sowohl der Bericht auf DevOps.com als auch der Artikel auf TechSpot beschreiben Scion als den Versuch der Infrastruktur, mit dem rasanten Output der Agents Schritt zu halten. Ein fünfköpfiges Team, das zehn Agents parallel laufen lässt, stößt im kleineren Rahmen auf genau dieselbe Wand.
Die Symptome dürften Ihnen bekannt vorkommen:
- Zwei Agents bearbeiten am selben Nachmittag dieselbe Datei, und Sie müssen den Konflikt manuell lösen.
- Pull-Requests stapeln sich schneller, als jemand sie lesen kann.
- Die CI-Warteschlangen werden von Woche zu Woche länger, während die Agents unvermindert schnell bleiben.
- Niemand kann mehr nachvollziehen, welcher Agent was oder warum geändert hat.
- Ein Branch vom Dienstag wird beim Rebase am Freitag zum reinen Chaos.
Anthropic ist die Punkte 1 und 3 mit neuer Infrastruktur angegangen. Sie können alle fünf Punkte mit besseren Prozessen und bereits vorhandenen Git-Bordmitteln lösen.
Merge-Konflikte bei Coding-Agents: Warum sie sich vervielfachen
Merge-Konflikte skalieren mit Überschneidungen, nicht mit der Teamgröße. Zehn Agents, die an einem weit gefassten Ziel arbeiten, greifen ständig auf dieselben Dateien zu. Zehn Agents, die an zehn klar abgegrenzten Aufgaben arbeiten, geraten sich selten in die Quere. Der Zuschnitt einer Aufgabe ist entscheidender als die reine Anzahl der Agents.
Langlebige Branches verschärfen die Situation zusätzlich: Mit jeder Stunde, die ein Branch offen bleibt, entwickelt sich der Main-Branch weiter. Durch Agents wird dieser Effekt noch verstärkt, da sie neue Branches schneller eröffnen, als Menschen sie abschließen können. Unser früherer Artikel darüber, wie viele Agent-Arbeitstage ein menschlicher Arbeitstag im Review bewältigen kann, belegt diese Diskrepanz mit konkreten Zahlen.
Was Sie heute schon ohne Scion tun können
Die folgenden fünf Best Practices decken den Großteil dessen ab, was ein typisches Team benötigt – ganz ohne ein neues Versionskontrollsystem einführen zu müssen.
Geben Sie jeder Aufgabe einen eigenen Worktree
Ein Git-Worktree ist ein zusätzliches Arbeitsverzeichnis, das mit demselben Repository verknüpft ist. Ein Worktree pro Aufgabe stellt sicher, dass niemals zwei Agents gleichzeitig in dasselbe Verzeichnis schreiben.
git worktree add ../tasks/COIN-212 -b agent/COIN-212 origin/main
cd ../tasks/COIN-212
# run the agent here, commit, push, open a PR
git worktree remove ../tasks/COIN-212
Die Einrichtung erläutern wir in Git-Worktrees für KI-Coding-Agents und das spätere Aufräumen in Worktrees verwalten ohne lästigen Cleanup-Aufwand.
Aufgaben klein und fokussiert halten
Formulieren Sie jede Aufgabe so, dass klar benannt ist, welche Dateien oder Module verändert werden dürfen und mit welchem Test der Abschluss nachgewiesen wird. Eine Aufgabe, die in einen überschaubaren, prüfbaren Diff passt, lässt sich reibungslos mergen. Ein Auftrag wie „Authentifizierung refaktorisieren“ garantiert dagegen Probleme.
Eine Merge-Queue vor dem Main-Branch vorschalten
Eine Merge-Queue testet jeden Pull-Request gegen den aktuellen Stand von Main sowie alle davor eingereihten Änderungen und merged sie anschließend der Reihe nach. Die Merge-Queue von GitHub übernimmt dies für geschützte Branches. Für kleinere Teams ist das das Äquivalent zu Anthropics Post-Merge-Testing: Man bemerkt inkompatible Kombinationen nicht erst dann, wenn sie bereits im Main-Branch gelandet sind.
Reviews mit der Aufgabe und klaren Nachweisen verknüpfen
Ein Diff allein verrät dem Reviewer weder den genauen Auftrag des Agents noch, was dieser überprüft hat. Reviews laufen deutlich schneller ab, wenn Prompt, Ausführung, Testausgaben und Diff an einem zentralen Ort gebündelt sind. Siehe dazu wie man KI-generierten Code mit Nachweisen auf Task-Ebene prüft und warum menschliche Reviews zum Engpass werden.
Agents auf Freigaben warten lassen
Lassen Sie Agents recherchieren, Code schreiben, testen und Berichte erstellen. Die Richtungsentscheidungen, die Freigabe riskanter Schritte und die Abnahme des Endergebnisses sollten jedoch beim Menschen bleiben. Ein Agent, der vor dem Mergen innehält und auf menschliche Freigabe wartet, kostet wenige Minuten. Ein Agent, der ungeprüften Code in den Main-Branch merged, kostet einen ganzen Tag. Unser Leitfaden zu Freigabe-Schranken für Coding-Agents zeigt, an welchen Stellen Stopps sinnvoll sind.
Wo Sharkly ins Spiel kommt
Sharkly ersetzt Git nicht und löst auch keine Merge-Konflikte. Ihre Agents committen weiterhin über Ihren gewohnten Git-Host in Ihr Repository. Was Sharkly organisiert, ist der gesamte Arbeitsablauf rund um diese Commits.
Jeder Arbeitsschritt eines Agents ist eine Aufgabe („Task“) mit einem zugewiesenen Bearbeiter („Assignee“), einem Status und einem Ausführungsprotokoll. Die Agents laufen auf Ihren eigenen Rechnern („Computers“) unter Verwendung von Claude Code, Codex oder einer anderen bereits genutzten Runtime. Im Temporary-Modus erhält jeder Task ein isoliertes Verzeichnis, und Repository-basierte Läufe können einen separaten Worktree vorbereiten, sodass parallele Tasks niemals in denselben gemeinsamen Ordner schreiben.
Sobald ein Agent fertig ist, kann er den Task in den Status für menschliche Reviews versetzen. Dieses Signal erscheint im Posteingang („Inbox“), wo die zuständige Person den Task öffnet, das Ergebnis im Kontext prüft und entscheidet, ob es akzeptiert, wiederholt oder neu zugewiesen wird. Die Task-Ausführung und weiterführende Diskussionen fließen direkt in die Task-Timeline zurück – so wird das Board zu Ihrer Review-Queue.
Diese Kombination verbindet die oben beschriebenen Git-Best-Practices mit einem zentralen Ort für Anforderungen, Ausführung, Nachweise und Entscheidungen. Wenn Sie verschiedene Optionen vergleichen möchten: Unsere Übersicht über Tools zur Verwaltung paralleler KI-Coding-Agents gibt einen umfassenden Marktüberblick.
Wer jetzt handeln sollte
Teams mit drei oder mehr täglich aktiven Agents: Sie stehen kurz vor dem Merge-Engpass. Führen Sie noch diese Woche Worktrees und eine Merge-Queue ein.
Solo-Entwickler, die Agents parallel betreiben: Ihr Engpass ist das Review, nicht das Mergen. Teilen Sie Aufgaben so klein ein, dass jeder Diff in unter zehn Minuten geprüft werden kann.
Plattform- und Infrastruktur-Leads: Behalten Sie Ihre CI-Wartezeiten und das Alter offener PRs im Auge. Anthropics Bericht zeigt, dass Versionskontrolle und CI vor allem anderen kapitulierten – rechnen Sie damit, dass dies bei Ihnen in derselben Reihenfolge geschieht. Das Setup für parallele Agents mit isolierten Worktrees verschafft Ihnen wertvolle Zeit.
Fazit
Anthropic Scion ist ein Warnsignal, kein Produkt, das man einfach einführen kann. Anthropics Merge-Volumen verzwölffachte sich innerhalb von vier Monaten, Gits Offline-First-Architektur stieß an ihre Grenzen, und ein siebenköpfiges Team baute die Versionskontrolle von Grund auf für Clients neu, die größtenteils Agents sind. Die allermeisten Teams werden so etwas nie benötigen.
Dennoch wird jedes Team, das Coding-Agents einsetzt, dieselbe Verschiebung erleben: Das Schreiben von Code wird spottbillig, während Mergen und Reviews teuer werden. Isolieren Sie einzelne Aufgaben, halten Sie Tasks klein, staffeln Sie Ihre Merges über Queues und prüfen Sie Code anhand konkreter Nachweise.
Um den Review-Teil an einem zentralen Ort zu bündeln, verbinden Sie einfach einen Computer mit Sharkly, erstellen Sie einen Agent und weisen Sie ihm eine kleine Aufgabe mit geringem Risiko zu. Beobachten Sie, wie das Ergebnis aufbereitet wird, und entscheiden Sie auf dieser Basis über die nächsten Schritte.
FAQ
Was ist Anthropic Scion?
Scion ist Anthropics internes Versionskontrollsystem. Es löste 2026 Git für das Monorepo des Unternehmens ab. Der Server übernimmt Commits, Merges sowie Rebases, während die Clients lediglich einen begrenzten lokalen Cache vorhalten.
Warum hat Anthropic Git ersetzt?
Coding-Agents ließen die täglichen Merges von rund 2.500 im Mai 2026 auf über 30.000 im September ansteigen. Git-Mirroring, Checkouts und CI konnten bei diesem Volumen nicht mehr mithalten, wodurch die Versionskontrolle zum zentralen Engpass wurde.
Ist Scion Open Source oder frei verfügbar?
Es gibt keine öffentliche Veröffentlichung. Anthropic erklärt, dass Scion kein geeigneter allgemeiner Ersatz für Git sei und es schwierig wäre, es für andere Organisationen bereitzustellen. Das Design wurde veröffentlicht, damit andere Entwickler die Konzepte auf Git übertragen können.
Wie lassen sich Merge-Konflikte zwischen Coding-Agents reduzieren?
Weisen Sie jeder Aufgabe einen eigenen Worktree zu, halten Sie Tasks so fokussiert, dass sie in einen überschaubaren Diff passen, mergen Sie häufig und schalten Sie eine Merge-Queue vor den Main-Branch. Konflikte entstehen durch Dateiüberschneidungen – der Zuschnitt der Aufgaben ist daher wichtiger als die schiere Anzahl der Agents.
Benötigen kleine Teams ein neues Versionskontrollsystem?
So gut wie nie. Anthropics Probleme resultierten aus einer 100-GB-Historie und 25 Millionen Checkouts pro Tag. Bei normalem Arbeitsaufkommen genügen Worktrees, Merge-Queues und Reviews auf Task-Ebene vollkommen, um das Volumen zu bewältigen.
