Aktualisiert am Oktober 15, um weitere Details zu den Projekten hinzuzufügen, die viele der Techniken, die wir in Scion verwenden, pioneershaft eingeführt haben.
Bei Anthropic ist Programmieren nicht mehr der Engpass beim Bauen von Systemen oder beim Betreiben von Forschung. Claude kann autonom Forschungsschleifen durchlaufen, komplexe Programme mikrooptimieren und neue Dienste von Grund auf mit einer Geschwindigkeit und in einem Maßstab aufbauen, die wir so noch nicht gesehen haben. Der Engpass ist heute die gesamte Entwickler-Infrastruktur, die für menschlichen Maßstab gebaut wurde: Quellcodeverwaltung, Builds und CI.
Im Mai 2026 lag der Durchschnitt bei Anthropic bei rund 2,500 zusammengeführten Codeänderungen pro Tag; Stand September haben wir über 30,000 pro Tag zusammengeführt. Wir erwarten nicht, dass diese Wachstumsrate so bald nachlassen wird; die latente Nachfrage nach dem Zusammenführen von Code ist praktisch unendlich, und jeder Engpass, den wir beseitigen, führt sofort zu einem weiteren Anstieg der Menge an Code, die wir produzieren.
Um dieses Wachstum zu unterstützen, haben wir Scion gebaut, ein selbst entwickeltes Versionsverwaltungssystem, und unser Monorepo in fünf Monaten vollständig von git migriert. Wir haben außerdem in derselben Zeitspanne eine Code-Review-Oberfläche (genannt Antique), Codesuche, ein umfangreiches Quellcodeverwaltungs-IAM-System, neuartige Wege zur Verwaltung und zum Einbringen großer Mengen an reviewtem Code und mehr gebaut und ausgeliefert. In diesem Beitrag konzentrieren wir uns darauf, wie wir speziell Scion gebaut haben. Es ergibt eine interessante Fallstudie: Claudes Fähigkeit, Code zu schreiben, war sowohl das, was uns zunächst in diese Lage gebracht hat, als auch die Art und Weise, wie wir schnell ein hochwertiges, skalierbares System zur Bewältigung davon bauen konnten.
Unser Monorepo wächst
Bevor wir untersuchen, was wir gebaut haben, sollten wir anerkennen, wie ungewöhnlich unsere Arbeitslast ist. Es überrascht nicht, dass Anthropic Claude zum Schreiben von Software weit mehr nutzt als fast jedes andere Unternehmen, daher sind wir oft die Ersten, die erleben, wo Werkzeuge für menschlichen Maßstab an ihre Grenzen stoßen. Quellcodeverwaltung ist nur ein Beispiel dafür. Während wir nicht erwarten, dass viele Organisationen diese Probleme in sehr naher Zukunft haben werden, vermuten wir, dass es nicht mehr lange dauern wird, bis andere, die KI-Codierungswerkzeuge verwenden, dieselben Druckpunkte erleben – deshalb wollten wir teilen, was wir gebaut haben und was wir gelernt haben.
Git ist ein dezentrales System: Jeder Klon ist ein vollständiges, in sich geschlossenes Repository, das Diffs berechnen, Verlauf und Blame lesen und jede Revision auschecken kann, während es vollständig offline ist. Für die allermeisten Repositorys ist dies das richtige Design, und es ist ein großer Teil des Grundes, warum git zum Standard wurde.
Während unser Monorepo wächst, passt es zunehmend nicht mehr in diesen Designraum. Allein der Verlauf unseres Haupt-Zweigs ist fast 100 GB groß, und eine komprimierte Arbeitskopie ist über 25 GB groß. Wir führen in der Größenordnung von 25 Millionen Code-Checkouts pro Tag für CI durch, noch ohne Entwicklerumgebungen, Agent-Sandboxes und Forschungsjobs zu zählen. Naiv abgerufen wären das über 600 PB an git-Traffic pro Tag.
Git bietet Werkzeuge für die Arbeit mit einem Ausschnitt eines Repositorys, wie shallow clones, sparse checkouts und promisor remotes. Darüber hinaus gibt es Standard-Workarounds für große Monorepos, wie interne git-Mirrors und Repository-Snapshots (Seeds) im Blob-Speicher. Wir haben alle verwendet – auf unserem Höhepunkt betrieben wir mehrere hundert interne git-Mirrors, um die Last zu bewältigen. Das verschaffte uns Zeit, aber sie wurden mit steigender Merge-Rate schwieriger zu betreiben. Seeds gerieten zwischen Aktualisierungen weiter von der Spitze von main entfernt, und es erforderte immer mehr Sorgfalt, um Vorgänge, die vom Verlauf abhängen, wie diff und blame, auf Teilklonen funktionsfähig zu halten.
Wenn man einen Schritt zurücktritt, fällt auf: Wie die meisten Unternehmen nutzten wir git als zentrales System mit einer autoritativen Kopie, aber nahezu alle unsere Clients waren Agenten und Jobs, die per Definition online sind. Die Eigenschaften, die git hervorragend für verteilte, Offline-Arbeit machen, untergruben aktiv unsere Fähigkeit zu skalieren, während das Repo wuchs. Also fragten wir uns: Wenn wir Quellcodeverwaltung von Anfang an mit der Tatsache entwerfen würden, dass Agenten immer online sind, wie würde sie aussehen?
Prinzipien für Quellcodeverwaltung in Agenten-Größenordnung
Mit agentic coding entwickeln sich viele gängige Annahmen darüber, wie Software entwickelt wird, weiter. Wir haben diese Veränderungen beim Bau von Scion angenommen, was uns ermöglichte, einen grundlegend anderen Ansatz als git bei mehreren Kernprinzipien zu verfolgen. Quellcodeverwaltung für riesige Monorepos hat Vorbilder, insbesondere Googles Piper und Metas Sapling,2 so dass wir Scion mit deren hart erkämpften Erkenntnissen im Hinterkopf bauen konnten. Unsere Prinzipien sind:
Clients sind immer online. Git geht davon aus, dass Clients offline arbeiten und eine vollständige Kopie des Repositorys benötigen. Da nahezu alle unsere Clients Agenten und Jobs sind, haben wir Scions Client und Protokolle um einen Server entworfen, der immer erreichbar ist, und lassen Clients Daten abrufen, wenn sie sie benötigen.
Client-Server-Asymmetrie. In git ist jeder Client in der Lage, ein vollwertiger Server zu sein. In Scion beantwortet der Server Fragen zum Dateiverlauf und Blame, erstellt Commits, führt Merges und Rebases durch und so weiter. Der Client unterhält einen begrenzten lokalen Objekt-Cache, legt die Arbeitskopien-Dateien auf der Festplatte ab, überwacht Dateisystemänderungen und gibt Benutzern eine ergonomische Möglichkeit, mit dem Server zu arbeiten. Er kann selbst sehr wenig berechnen, benötigt dafür aber viel weniger Daten lokal.
Ein umfassender Source-Control-Dienst kann viele neuartige Anwendungen ermöglichen. Bei git muss ein CI-Job oder Tool, das eine Frage zum Repository stellen möchte – etwa wer zuletzt eine Zeile geändert hat oder wie zwei Commits zusammenhängen – eine lokale Kopie des Repos pflegen oder darauf hoffen, dass herstellerspezifische APIs die Antwort liefern. Bei Scion werden alle vom Client genutzten Source-Control-Abfragen ebenfalls über eine API bereitgestellt, sodass Jobs in vielen Fällen gar kein lokales Repository benötigen. Viele interne Tools, wie unsere automatisierten Bisect- und Revert-Pipelines, wären ohne diesen billigen, programmatischen Zugriff auf die Quellcodeverwaltung in großem Maßstab nicht praktikabel.
Alles muss horizontal skalierbar sein. Auf unserem Höhepunkt betrieben wir mehrere hundert git-Mirrors, was die Kapazität erheblich belastete und nicht mehr skalierte, sobald das Repo die Festplatten- oder Speicherlimits der Mirrors überschritt. In Scion sind die Daten des Repositories verteilt, und jede Komponente ist unabhängig skalierbar; es gibt nirgendwo eine vollständig materialisierte Kopie des Repos, nicht einmal auf dem Server. Es gibt kein Äquivalent zu Packfiles (gits komprimierte Objektbündel), daher ist keine Repository-Wartung erforderlich.
Commits müssen günstig, inkrementell und ohne Sperren sein. Bei git committet man lokal und pusht dann, um die Arbeit zu teilen. Bei Scion findet jeder Commit, Rebase oder Merge auf dem Server statt, es gibt also nichts zu pushen, aber jede dieser Operationen muss schnell sein. Die Kosten für das Erstellen eines Commits und das Aktualisieren seiner nachgelagerten Datenstrukturen müssen mit der Größe der Änderung skalieren, nicht mit der Gesamtgröße des Repos, sonst kommt der Server nicht hinterher. Der Entwicklungslebenszyklus in Scion rät von refs (Zeigern auf Commits, wie Branches und Tags) ab, mit Ausnahme des main-refs oder von Release-Branches, weil globaler Zustand, auf den sich jeder Server einigen muss, ein drohendes Skalierungsproblem darstellt.
Die Working Copy ist optional und von Natur aus spärlich (sparse). Da unser Monorepo so groß ist und wir Code zig Millionen Mal täglich für CI auschecken, wollten wir Checkouts wann immer möglich vermeiden. Mit Scion kann ein CI-Job, der beispielsweise das Diff zwischen einem Commit und seiner Merge-Basis benötigt, diese beim Server anfragen. Dasselbe gilt für Schreibvorgänge: Viele Schreib-Workloads können den Checkout ebenfalls überspringen und vollständig über die API funktionieren. Scions Protokoll ist auf Sparse-Checkouts zentriert, die nur die Verzeichnisse enthalten, die der Client anfordert, sowie auf virtualisierte Checkouts, die Dateien bei Bedarf materialisieren, sodass ein Job, der Dateien auf der Festplatte benötigt, nur für das bezahlt, was er tatsächlich liest.
Wie Scion funktioniert
Es ist hilfreich zu verstehen, wie diese Prinzipien beim Bau von Scion in der Praxis zusammenkamen. Diese Erkenntnisse können auf andere Source-Control-Systeme oder, allgemeiner, auf andere Phasen des Softwareentwicklungszyklus angewendet werden.
Datenstrukturen
In Scion ist die Arbeitseinheit ein „Changeset“, ein Eintrag in einem Write-Ahead-Log. Ein Changeset speichert das meiste, was man von einem Commit in git erwarten würde. Aber während ein git-Commit einen Zeiger auf den Tree speichert, speichert ein Changeset eine Liste der Dateien, die sich relativ zu seinem ersten Parent geändert haben,1 zusammen mit inhaltsadressierten Zeigern auf die komprimierten Dateiinhalte im Blob-Speicher. Changesets werden serverseitig erstellt und sind überall sofort verfügbar.
Diese Struktur ermöglicht es uns, Changesets mit sehr hohem Durchsatz zu akzeptieren, weil es keine Packfiles zu akzeptieren gibt, keine Sperren oder serverübergreifende Koordination und keine refs zu verschieben. Scion unterstützt technisch gesehen refs, aber da weder das Erstellen noch das Abrufen von Commits diese einbezieht, ist das Verschieben einer ref ein Compare-and-Swap auf einer einzelnen Spanner-Zeile, die getrennt vom Erstellen von Changesets erfolgt.
Ein Changeset zeichnet nur auf, was sich geändert hat, kann also allein Fragen wie „wer hat zuletzt eine Zeile bearbeitet“ oder „welche Commits haben eine Datei beeinflusst“ nicht schnell beantworten. Um solche Fragen zu beantworten, baut Scion zusätzliche Datenstrukturen aus den Changesets auf, darunter dedizierte Strukturen für File-Blame und Pfadhistorie sowie Skip-Listen für den Commit-Graphen. Wir nennen alles, was nicht direkt Teil des Changesets ist, „abgeleitete Daten“, und wir berechnen sie alle über einen generischen Mechanismus. Jeder Typ abgeleiteter Daten ist rekursiv definiert, sodass sein Wert für ein Changeset aus seinen Werten für die Parents dieses Changesets berechnet wird.
Dieser Mechanismus hat drei Vorteile. Erstens können wir leicht einen neuen Typ abgeleiteter Daten hinzufügen, wenn eine neue Datenstruktur eine Operation beschleunigen würde. Zweitens können wir für jeden Typ wählen, ob wir ihn eifrig berechnen oder die Arbeit aufschieben, sodass wir vermeiden, Daten zu materialisieren, die wir nicht benötigen. Und drittens können wir diese Datenstrukturen optimieren, ohne den Client zu ändern, weil der Client die Interna dieser Datenstrukturen nie sieht. Wir haben neue Typen abgeleiteter Daten mehrfach hinzugefügt, während das System gewachsen ist, etwa neue Indizes für Copy-Detection oder pfadbasierte Dateisuche.
Skalierung von Scion
Eine kleine Flotte von Scion-Servern stellt Source-Control-APIs für jede Operation bereit, die ein Client benötigt, wie etwa das Abrufen von Changesets, das Berechnen von Diffs, das Finden von Merge-Basen und das Laden von Blobs. Alle Source-Control-Daten sind inhaltsadressiert, sodass sich ein Datenelement nach der Speicherung nie mehr ändert und jeder Server es zwischenspeichern kann, ohne die anderen zu fragen. Dadurch sind die Server horizontal skalierbar und erfordern nur wenig Koordination. Sie sind im Wesentlichen große Caches, die zusätzlich abgeleitete Daten on-the-fly berechnen und die Ergebnisse zurück in Spanner schreiben können.
Scions vielen Nutzerinnen und Nutzer müssen keine eigenen lokalen Repositorien mehr pflegen. Das Abrufen und Pflegen des Repositorien war früher eine erhebliche Wartungslast für CI-Jobs oder Tools, die Fragen an die Quellcodeverwaltung stellen mussten, insbesondere zu Commit-Abstammung und Blame. Zu Beginn der Migration, bevor wir einen eigenen Client, ein eigenes Repo-Format oder eigene Protokolle hatten, beantwortete Scion nur diese „Metadaten“-Anfragen. Das Abrufen von Dateiinhalten und das Materialisieren von Working Copies sind deutlich datenintensivere Vorgänge und erforderten einen eigenen Entwurf.
Scions scn-Client weicht in mehreren wichtigen Punkten von gits Fetch-Protokollen ab und eignet sich dadurch für eine hochskalierbare Architektur, die deutlich weniger CPU als git-Server benötigt. Scions Verhandlung teilt dem Server nicht mit, was der Client bereits hat; stattdessen arbeitet sie ausschließlich mit den Trees und Blobs, die der Client haben möchte. Ausgehend von einem Root-Tree prüft der Client seinen lokalen Speicher auf fehlende Trees und fordert diese rekursiv an, dann wiederholt er den Prozess für Blobs. Jede Anfrage gilt für ein bestimmtes Objekt, das sich nie ändert, sodass jeder Cache sie beantworten kann, und die Architektur ähnelt stark herkömmlichen gestuften Caches. Der Prozess ist außerdem effizient und fortsetzbar, da es keine einzige mehr-Gigabyte-Packfile-Antwort gibt. Sparse- und sogar virtualisierte Checkouts benötigen keine spezielle Unterstützung, weil der Client einfach keine Trees anfordert, die er nicht will.
In der Flotte kommuniziert der Client über einen Socket mit einem Daemon, scion-daemon, der Objekte für den gesamten Knoten speichert. Die meisten unserer Knoten benötigen Zugriff auf das Monorepo, und Jobs auf demselben Knoten nutzen größtenteils dieselben Objekte wieder. Jeder Daemon startet von einem periodisch aktualisierten Snapshot und spricht danach nur mit den Tree- und Blob-Cache-Servern in seiner Region, die scion-cache heißen. Diese Cache-Server streamen Objekte direkt aus dem Speicher, im Festplattenformat, das der Daemon verarbeitet, sodass sie keine Zeit damit verbringen müssen, die fehlenden Objekte des Clients zu berechnen oder Delta-Kompression durchzuführen. Wenn einem Cache ein Objekt fehlt, fragt er die autoritativen scion-server, die bei Bedarf aus Spanner oder Cloud-Storage lesen.
Der scion-daemon, scion-cache und scion-server antworten alle auf identische RPCs für dieses Protokoll, sodass der Client die Cache-Topologie nicht kennen muss. Theoretisch könnte jede Stufe mit jeder anderen kommunizieren, aber wir erzwingen die Staffelung streng, um Fehlerdomänen zu isolieren. Wir wollen eine Situation vermeiden, in der ein Fehler in einem regionalen scion-cache die vorgelagerten scion-server überlastet und das gesamte System herunterbringt.
Jede Stufe dieses Systems hält eine Cache-Trefferquote von über 99% und benötigt keinen langlebigen Zustand, sodass es bei Bedarf leicht hochskaliert werden kann. Unser Scion-Infrastruktur-Fußabdruck ist nun 200x kleiner als unsere frühere Git-Mirroring-Infrastruktur in Bezug auf CPU- und Speicherbedarf. CI- und Forschungs-Jobs checken Code zwei Größenordnungen schneller aus (in Sekunden statt Minuten), was eine beträchtliche Kapazität in der gesamten Flotte freisetzt; allein die CI erzielte einen CPU-Kapazitätsgewinn von 25%. Weder Clients noch Caches müssen Repository-Wartung durchführen, was das Lifecycle-Management unserer Jobs vereinfacht.
Was wir beim Bau von Scion gelernt haben
Wir begannen etwa zur gleichen Zeit mit dem Bau von Scion, als Claude Mythos Preview und Claude Tag intern verfügbar wurden. Beide Veröffentlichungen verstärkten gleichzeitig den Bedarf an Scion und beschleunigten erheblich, wie schnell wir es bauen konnten.
Hier ist ein besonders eindrucksvolles Beispiel. Anfang des Jahres hatten wir die erste Version der Git-zu-Scion-Ingestion-Pipeline größtenteils als Prototyp von Hand geschrieben. Wir hielten sie für gut – bis wir eine frühe interne Momentaufnahme von Claude Mythos Preview in die Hände bekamen. Wir baten es, das Ganze neu zu schreiben, und ohne weitere Anweisungen entstand eine Version, die 20x weniger Speicher verbrauchte und 4x schneller war, während alle impliziten Invarianten rund um die Ingestion-Reihenfolge und Datenstrukturen erhalten blieben.
Was wir beim Bauen und Betreiben von Scion gelernt haben, bietet einige interessante Lehren dafür, wie der Bau von Software in Agenten-Skalierung aussehen könnte.
Schnelle Entwicklung mit einem kleinen Team wird häufiger werden. Ein Team von sieben Personen baute sowohl Scion als auch Antique (unser Code-Review-Tool, über das wir problemlos einen ganzen weiteren Blogbeitrag schreiben könnten), ganz zu schweigen von einem halben Dutzend verwandter Systeme, und migrierte innerhalb von fünf Monaten vollständig zu ihnen. Wir haben all das getan, während sich das Volumen des pro Tag zusammengeführten Codes um das 10x-Fache erhöhte. Früher hätte die Entwicklung und Einführung eines solchen Quellcodeverwaltungssystems ein Unternehmen Jahre iterativer Migration mit deutlich mehr Ingenieuren gekostet. Wir glauben, dass diese Art schneller, wendiger Migration in Zukunft häufiger werden wird.
Ingenieure sind nicht weniger wertvoll, aber ihre Arbeit verändert sich. Alle Ingenieure, die an diesem System gearbeitet haben, würden Claude inzwischen als besser bewerten als sich selbst beim Schreiben von Code. Aber unsere Ingenieure steuerten weiterhin das unschätzbare Verständnis der übergeordneten Systemkomponenten und der designbezogenen Abwägungen bei und trafen fundierte Entscheidungen hinsichtlich der Probleme, die wir lösen wollten, und der Größenordnung, die wir zu erreichen wussten. Sehr oft bestand die Rolle der Ingenieure darin, Claude „Nein“ zu sagen. Agenten verletzen manchmal grundlegende Systembeschränkungen, um ein Muster zu erfüllen, das eigentlich nie zugelassen hätte werden dürfen. Das war in unserer Migration besonders häufig. Beispielsweise gab es mehrere Systeme, die versuchten, durch lineares Lesen des Commit-Protokolls herauszufinden, wann eine Änderung in main gemergt wurde, anstatt unser Code-Review-Tool zu fragen. Anthropic setzt außerdem ausgiebig adversarielles Review ein, und obwohl dies in vielerlei Hinsicht äußerst effektiv ist, kann es auch kurzsichtig sein, sodass erfahrene Ingenieure Claude davon abhalten mussten, Teile des Systems als Reaktion auf hypothetische Bedenken zu überkonstruieren. Zum Beispiel war ein solches Review übermäßig defensiv beim Vertrauen in einen anderen internen Dienst, was dazu führte, dass Claude übermäßige Validierung und Komplexität hinzufügte. Unsere Teammitglieder prüfen weiterhin jede Änderungsanforderung für das System, betrachten nun aber die Absicht der Änderung, anstatt jede einzelne Codezeile zu lesen.
Wir waren in der Lage, Optimierung und Qualität erheblich zu verbessern. Dank Claudes Fähigkeit, immense Code-Mengen viel schneller zu schreiben, als wir es selbst könnten, gehört Scion zu den am besten getesteten und am besten abgesicherten Codebasen, an denen wir je gearbeitet haben. Selbst bei unserem engen Zeitplan konnten wir hermetische Simulationen jeder nicht-trivialen Infrastruktur- und Source-Control-Interaktion entwickeln, auf die wir je gestoßen sind, ebenso wie Fuzzing und ausgefeiltes Rate Limiting. Claude fand auch beiläufig bedeutende Optimierungen – zum Beispiel eine algorithmische Optimierung für Ancestry-Abfragen, die einen unserer Indizes verfehlte –, die einen Experten Tage oder Wochen der Analyse und Feinabstimmung gekostet hätten … und am nächsten Tag machte es das alles noch einmal.
Wir legten den Grundstein für neue Formen der Monorepo-Sicherheit. Die Verwaltung von Sicherheit, Security und Compliance in einem massiven Monorepo ist genauso wichtig wie die Verwaltung der Größe und des Umfangs. Wir haben Scion von Anfang an mit diesen Aspekten im Blick gebaut. Es unterstützt eine umfassende Zugriffskontrolle auf Repositories sowie die Möglichkeit, Berechtigungen auf einzelne Verzeichnisse anzuwenden, um den sensibelsten Code zu schützen, ohne die Vorteile eines Monorepos zu verlieren. Darüber hinaus kann das von uns gebaute Code-Review-Tooling komplexe semantische Beschränkungen für Genehmigungen ausdrücken, wodurch wir einfache Dinge wie rein kommentarbasierte Änderungen von sensiblen logischen Änderungen unterscheiden können, damit menschliche Reviewer sich auf die folgenreichsten Änderungen konzentrieren können.
Ein neues Niveau operativer Exzellenz ist möglich. Unser Team nutzt Claude Tag intensiv, was uns geholfen hat, jede Komponente des Systems zu überwachen. Beispielsweise haben wir Slack-Kanäle erstellt, in denen wir Claude beauftragt haben, obsessiv auf die Gesundheit einer einzelnen Komponente zu achten. Wir nennen diese Claudes „Superfans“. Wir haben einen scion-daemon-Superfan, einen scion-cache-Superfan, einen Antique-Merge-Queue-Superfan und so weiter. Sie haben Zugriff auf unsere Telemetrie und Logs und verhalten sich wie ein erfahrener Ingenieur, der nichts Besseres zu tun hat, als Diagramme zu aktualisieren und nach allem Ungewöhnlichen zu suchen. Wir haben auch traditionelle Alerts für alle unsere Systeme, aber unsere Superfans können subtile und neuartige Probleme erkennen, die diese Alerts im Vergleich eindimensional wirken lassen.
Wir überdenken unsere Annahmen vollständig. Dieses Projekt veranlasste uns, andere Workflows, die auf menschliche Größenordnungen ausgelegt sind, sehr genau zu betrachten. Eine ordentliche Merge Queue ergibt beispielsweise auf Agenten-Größenordnung wenig Sinn. Was bedeutet CI überhaupt, wenn hunderte oder sogar tausende Änderungen gemergt werden können, während Tests laufen? Wir konnten den Branchenstandard einer globalen Repository-Sperre auf der Merge Queue nicht effektiv nachbilden, deshalb haben wir stattdessen in automatisiertes Post-Merge- und Pre-Deploy-Testing investiert. Das bedeutet zwar, dass gleichzeitige Änderungen in Konflikt geraten können, aber Claude kann diese Konflikte in der Regel schneller beheben, als Menschen sie überhaupt identifizieren können.
Beitrag zum weiteren Ökosystem
Wir sehen Scion als nur einen Teil der Antwort auf die Skalierungsbedenken, die zunehmend fähige KI-Agenten aufgeworfen haben. Wir teilen diese Details als Beispiel dafür, wie Teams ähnliche Herausforderungen angehen können, obwohl wir nicht erwarten, dass unsere Lösung oder unsere Überlegungen für jeden Fall geeignet sind.
Scion ist keineswegs ein geeigneter Ersatz für git für den allgemeinen Gebrauch. Die hier skizzierten Konzepte ergaben wirklich nur Sinn für wahrhaft enorme Monorepos, mit entweder zehntausenden Ingenieuren oder Schwärmen von Agenten, die produktiv Code schreiben. Außerdem ist Anthropic einzigartig darin, dass unsere Fähigkeit, Tokens für den internen Gebrauch auszugeben, weit über das hinausgeht, was jedes andere Unternehmen realistisch ausgeben würde. Wir tun dies sowohl, um unsere eigenen Softwareentwicklungsbedürfnisse zu adressieren, als auch um Claudes Fähigkeiten zu testen.
Praktisch gesehen ist es schwierig, Scion in einer Form anzubieten, die für andere Organisationen breit nützlich wäre. Es weicht erheblich von git ab, was bedeutet, dass Unternehmen jeden Teil des Entwicklungslebenszyklus migrieren müssten, und es erfordert sein eigenes Code-Review, Codesuche und CI. Unsere internen Versionen dieser Komponenten sind stark maßgeschneidert, sodass sie für andere Organisationen schwer zu übernehmen wären, und wir befürchten, dass der Versuch, eine öffentliche Version zu bauen, die es allen recht machen will, nicht wirklich sehr nützlich wäre.
Wir erwarten jedoch, dass diese Klasse von Problemen in den nächsten sechs bis 12 Monaten häufiger auftreten wird, und es wäre eine ineffiziente Verwendung von Engineering-Ressourcen, wenn jedes Unternehmen, das git verwendet, ähnlichen Herausforderungen alleine gegenüberstünde. Vor diesem Hintergrund denken wir, dass das Wirkungsvollste, was wir tun können, darin besteht, unsere Gedanken zu teilen, damit andere Entwickler einige der erfolgreichsten Teile von Scion auf git anwenden können, ohne vom Gesamtmodell abzuweichen. Ein git-Server muss nicht auf dieselbe Weise funktionieren wie ein git-Client; es existieren neuartige Serverarchitekturen, die erhebliche Skalierungsverbesserungen bieten. Git-Plattformen können umfassende serverseitige RPCs wie Scion bereitstellen, vielleicht sogar auf standardisierte Weise über Forges hinweg, mit denen der git-Client lernen kann zu kommunizieren. Das Aushandlungsprotokoll muss auch nicht genau so aussehen wie heute, und die verschiedenen Sparse- und Shallow-Funktionen in git können so gestaltet werden, dass sie gut zusammenwirken.
Schließlich möchten wir anerkennen, dass die git-Community fast zwei Jahrzehnte daran gearbeitet hat, die Plattform für Millionen von Entwicklern zu skalieren. Unser Beitrag ist weit schmaler: den Austausch unserer frühen Sicht darauf, wie agentische Softwareentwicklung mit diesen Systemen interagiert, damit wir mit GitHub, GitLab und der OSS-Community zusammenarbeiten können, um die sich ändernden Bedürfnisse von Entwicklern zu unterstützen. Wir sitzen alle im selben Boot, wenn sich der Softwareentwicklungslebenszyklus mit der KI-Exponentialkurve kreuzt.
Fußnoten
01Geänderte Dateien relativ zum ersten Eltern-Commit eines Merges zu speichern ist eine stilistische Entscheidung; in der Praxis haben wir festgestellt, dass Menschen in einem Monorepo mit trunk-basierter Entwicklung sich nur für die History oder das Blame von Commits auf der Hauptlinie interessieren.
02Konkret die Server-Komponente von Sapling, Mononoke. Sie hat viele der Techniken, die wir in Scion verwenden, wegweisend entwickelt, insbesondere das Bonsai -Datenmodell.
Autoren & Danksagungen
Danksagungen
Geschrieben von Nick G. und dem Source-Control-Team: S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P. Wir sind Vilas J. und Sergiu D. dankbar für die Unterstützung des Source-Control-Teams auf diesem ehrgeizigen Weg und Amir O. für frühe Beiträge zu Antique.