Scion: schlanke Git-Alternative von Anthropic für agentische Workflows

In einem Blogbeitrag beschreibt das KI-Unternehmen Anthropic ein selbst entwickeltes Versionskontrollsystem mit Client-Server-Architektur, da das gängige Git bei der Firma an seine Grenzen gekommen war. Veröffentlichen will Anthropic das Tool jedoch nicht, da es zu eng an die firmeninternen Strukturen geknüpft sei. Die Beschreibung soll eher als Erfahrungsbericht dienen.

Als Grund für die Eigenentwicklung nennt Anthropic den gestiegenen Bedarf an Beiträgen zum Code (Merges) durch die Tätigkeit von Agenten. Das für die Offline-Entwicklung konzipierte Git konnte hier nicht mehr ausreichend skalieren. Die Architektur des neuen Systems mit Namen Scion ist hingegen speziell für automatisierte und agentische Clients ausgelegt, die immer online sind.

Die Scion-Infrastruktur benötigt laut dem Blog 200-mal weniger CPU-Leistung und Arbeitsspeicher als die vorherige Git-Mirror-Infrastruktur. CI- und Forschungsjobs checken Code um zwei Größenordnungen schneller aus, in Sekunden statt Minuten (siehe Abbildung 1).

Die Zahl an Merges konnte die Firma von durchschnittlich rund 2500 täglich im Mai auf mehr als 30.000 täglich im September steigern (Abbildung 2). „Wir erwarten nicht, dass sich diese Wachstumsrate in nächster Zeit verlangsamen wird“, heißt es im Blog.

Neben dem Kern der Versionskontrolle hat die KI-Firma eine Review-Oberfläche, Antique, und weitere Hilfstools geschaffen.

Git kommt mit Agenten an seine Grenzen

Ein Git-System besteht aus verschiedenen, dezentralisierten und unabhängigen Klonen. Die Arbeit mit dem Monorepository von Anthropic war in dieser Struktur immer schwerer handhabbar. Die History des Main-Zweigs umfasste knapp 100 Gigabyte und eine komprimierte Arbeitskopie mehr als 25 Gigabyte. Hinzu kamen rund 25 Millionen Checkouts täglich allein für CI, was theoretisch mehr als 600 Petabyte (ca. 600.000 Terabyte) an täglichem Datentransfer mit Git bedeutet hätte.

Spezielle Tools und Workarounds minderten diese Last: Anthropic betrieb beispielsweise mehrere hundert Git-Mirrors, wodurch Funktionen wie diff und blame aber schwieriger zu koordinieren waren (Abbildung 3).

Das Grundkonzept von Scion trennt sich von den vollwertigen Clients bei Git und wechselt zu einer Client-Server-Struktur, wobei die Verbindung immer online ist. Clients sind stetig synchron und brauchen nicht das komplette Repo als Basis. Auch CI-Systeme brauchen keine Kopie des Repos, sondern holen sich die nötigen Informationen per API (Abbildung 4).

Wichtiges Merkmal von Scion ist die verteilte Datenhaltung auf Serverseite. Es gibt kein materialisiertes Repository an einem Ort, alle Daten sind verteilt und horizontal skalierbar. Packfiles wie bei Git existieren nicht. Eine kleine Anzahl von Servern reicht, die ihre Funktionen per API in alle Richtungen anbieten.

Commits, Rebases oder Merges erfolgen auf den Servern und es gibt keine große Push-Last im Netzverkehr. Commits haben die Form von Change Sets, die nur die Änderungen an bestimmten Dateien aufzeichnen, statt die kompletten geänderten Dateien auszuliefern (Abbildung 5).

Ingenieure bleiben wertvoll

Scion wurde von einem siebenköpfigen Team mithilfe von Claude in fünf Monaten entwickelt. Eine Erfahrung, über die Anthropic berichtet, ist, dass Migrationen mit LLMs weniger Personal in kleinen Teams erfordern. Ingenieure werden dabei nicht weniger wertvoll: „Dennoch lieferten unsere Ingenieure ein unschätzbares Verständnis für die höherrangigen, systemübergreifenden Komponenten und die Abwägungen beim Design. Sie trafen fundierte Entscheidungen zu den Problemen, die wir lösen wollten, und zu der Größenordnung, die wir erreichen mussten.“ Oft hatten sie die Arbeit der Agenten zu korrigieren.

Jede Änderung wurde von KI (Adversarial LLMs) und Menschen geprüft, aber hinsichtlich der Intention der Änderung, und nicht jede Codezeile einzeln.

Keine Veröffentlichung als Open Source

Anthropic will Scion nicht veröffentlichen, da es laut der Firma eng mit den internen Strukturen des Unternehmens verknüpft und daher nicht übertragbar sei. Intention des Berichts ist vielmehr, die prinzipiellen Erkenntnisse mit anderen Unternehmen mit großen Entwicklungsabteilungen zu teilen. Die nötigen Anpassungen seien dann individuell umzusetzen.

Auch andere Unternehmen haben eigene Versionskontrollsysteme gebaut, zum Beispiel Google mit Piper und Meta mit Sapling, wobei bei Letzterem grundlegende Teile sogar Open Source sind, wenn auch nicht das komplette System.