Anthropic hat Git verlassen. Lehrreich ist der Grund.

Anthropic arbeitet im eigenen Haupt-Repository nicht mehr mit Git. Das neue System heisst Scion, sieben Leute haben es in fünf Monaten gebaut, und der Bericht dazu sagt deutlich, dass du es mit ziemlicher Sicherheit nicht brauchst.

Lies ihn trotzdem. Nicht wegen des Werkzeugs, sondern wegen dem, was es nötig gemacht hat: Sobald Code billig zu schreiben war, wurde jedes System dahinter zum Engpass, und die Versionsverwaltung ist als Erstes gebrochen.

Was bei Anthropic tatsächlich passiert ist

Die Zahlen sind das Argument, also hier so, wie sie veröffentlicht wurden. Die Merges ins Monorepo stiegen von rund 2500 pro Tag im Mai 2026 auf über 30’000 pro Tag im September. Der Hauptbranch trägt fast 100 GB Historie, eine komprimierte Arbeitskopie über 25 GB. Die CI checkt das Repository rund 25 Millionen Mal am Tag aus, Entwicklerrechner, Agenten-Sandboxes und Forschungsjobs nicht mitgezählt. Naiv geholt wären das über 600 PB Git-Verkehr pro Tag.

Die meisten dieser Clients sind keine Menschen. Es sind Agenten und Jobs, ständig online, und jeder will eine frische Kopie eines Repositorys, das sich alle paar Sekunden ändert.

Das Team hat zuerst versucht, was alle zuerst versuchen: Shallow Clones, Sparse Checkouts, Promisor Remotes, interne Mirrors (zu Spitzenzeiten mehrere hundert) und vorgefertigte Seeds im Blob-Speicher. Jedes davon half eine Weile. Die Seeds lagen zwischen zwei Aktualisierungen immer weiter hinter dem Hauptbranch, und die Mirrors wurden mit jedem Anstieg der Merge-Rate schwerer zu betreiben.

Warum ausgerechnet Git gebrochen ist

Git ist absichtlich dezentral. Jeder Clone ist ein vollständiges Repository, was für die meisten Projekte genau richtig ist und für dieses genau falsch. Die Beobachtung im Bericht, die am meisten trägt, ist eine unscheinbare: Sie haben Git längst zentral benutzt. Fast jeder Client war dauernd online und sprach mit einem einzigen Server. Sie bezahlten für die Dezentralität und nutzten nichts davon.

Scion dreht die Verhältnisse deshalb um. Der Server führt Historie, Blame, Commits, Merges und Rebases. Der Client hält einen begrenzten Cache und holt Trees und Blobs erst, wenn er sie braucht. Ein Commit entsteht auf dem Server und existiert sofort, es gibt also nichts zu pushen. Viele Jobs checken gar nichts aus und fragen den Server per API nach einem Diff. Eine vollständige Kopie des Repositorys gibt es nirgends, auch nicht auf dem Server.

Die berichteten Ergebnisse: Checkouts in Sekunden statt Minuten, ein 200-mal kleinerer Ressourcenbedarf als die abgelöste Mirror-Flotte und 25 Prozent CPU-Kapazität, die in der CI frei wurden. Das sind Zahlen eines Anbieters über sein eigenes System, gemessen an einer Infrastruktur, der dasselbe Team entwachsen war. An der Richtung zweifelt niemand, die Faktoren sind ihre.

Ist Git zu langsam für KI-Agenten?

Nicht in einer Grösse, die die meisten Teams je erreichen. DriveFlow, unsere Plattform für Schweizer Fahrschulen, hat 515 Commits auf main und ist gepackt kleiner als 9 MB. Im letzten Monat haben wir zu zweit 124 Commits gepusht, 38 davon an einem einzigen Tag, mit rund 27’500 neuen Zeilen. Für unsere Verhältnisse ein dichter Monat, und ein vollständiger Clone ist trotzdem fertig, bevor du das Fenster gewechselt hast. Nichts, was Scion löst, existiert dort.

Die Autoren sagen das selbst: Scion passt zu sehr grossen Monorepos, in der Grössenordnung von Zehntausenden Entwicklern oder ganzen Schwärmen von Agenten, und wer es einführt, muss Code-Review, Suche und CI mitmigrieren, weil bei Anthropic jedes Werkzeug darum herum eine Eigenentwicklung ist. Sie halten auch fest, dass ihr interner Token-Verbrauch ungewöhnlich hoch ist. Höflicher lässt sich kaum sagen, dass wenige Firmen Agenten in dieser Dichte laufen lassen.

Ihre Prognose ist, dass derselbe Druck alle anderen in sechs bis zwölf Monaten erreicht. Die Richtung ist plausibel, der Zeitpunkt nicht überprüfbar. Praktisch heisst das: Die günstigen Funktionen, die Git schon hat, lohnen sich einzuschalten, bevor du sie brauchst.

Was ein kleines Team heute schon mit Git nutzen kann

Zu jedem Prinzip von Scion gibt es eine schwächere Fassung, die Git, GitHub und GitLab bereits mitbringen. Gratis ist keine davon.

Die eine Idee von Scion, die ein kleines Team nicht übernehmen sollte, ist der Verzicht auf die Merge Queue. Anthropic hat eine global gesperrte Queue durch Tests nach dem Merge und vor dem Deployment ersetzt, weil eine Sperre 30’000 Merges am Tag nicht überlebt, und Konflikte behebt Claude meistens, bevor ein Mensch sie bemerken würde. Bei zehn Merges am Tag kostet dich eine Merge Queue nichts und fängt genau die Änderung ab, die auf ihrem Branch grün ist und auf dem Hauptbranch bricht. Behalte sie.

Die kleine Fassung dieser Lektion haben wir im September an DriveFlow gelernt. Die CI ist dort der einzige Weg zum Deployment, und der Prüfjob brach jeden Lauf ab, den ein neuerer Push überholt hatte, auf main genauso wie bei Pull Requests. Das Deployment hängt am Prüfjob, also wurde es bei einem abgebrochenen Lauf nicht verzögert, sondern übersprungen. Solange eine Person pushte, fiel das nie auf. Zu zweit, am Tag nach einem Tag mit 38 Commits, hatten vier der letzten fünf Pushes auf main nichts ausgeliefert, und nichts war rot geworden: Ein abgebrochener Lauf und ein übersprungener Job sehen nicht wie Fehler aus. Die Korrektur waren ein paar Zeilen im Workflow: überholte Läufe nur bei Pull Requests abbrechen und Pushes auf main in die Warteschlange stellen. Das ist eine Merge Queue in ihrer kleinsten Form, und genau sie hat gefehlt, nicht ein schnellerer Checkout.

Was in jeder Grösse übertragbar ist

Der nützlichste Teil des Berichts handelt nicht von Speicher. Er handelt davon, was die sieben Leute den ganzen Tag gemacht haben.

Den grössten Teil des Codes haben sie nicht selbst geschrieben. Ein Claude-Modell hat die von Hand geschriebene Ingestion-Pipeline von Git nach Scion ohne weitere Anweisungen neu geschrieben, mit 20-mal weniger Speicher und viermal schneller, und dabei die Invarianten zur Reihenfolge eingehalten. Bei den Leuten blieben die Designentscheide und das Nein-Sagen. Agenten lasen das Commit-Log mit roher Gewalt. Sie bauten Validierungen ein, die niemand brauchte. Adversariales Review wurde manchmal kurzsichtig. Das Team prüft inzwischen die Absicht statt jede Zeile.

Zwei Mechanismen machen das sicher und nicht bloss schnell. Scion kennt Berechtigungen pro Verzeichnis, und das Review-Werkzeug kann semantische Freigaberegeln ausdrücken: Eine Änderung, die nur Kommentare anfasst, braucht nicht dieselbe Freigabe wie eine an der Berechtigungslogik. Und sie haben, mit Hilfe von Claude, hermetische Simulationen und Fuzzing gebaut, damit “auf Absicht geprüft” auf etwas aufsetzt, das tatsächlich gelaufen ist.

Das ist dieselbe Unterscheidung wie in was wir prüfen, bevor ein Betrieb damit arbeitet: Ein grünes Licht zählt nur, wenn du weisst, was es erzeugt hat.

Was du damit anfängst

Miss, wo deine Zeit zwischen “die Änderung ist geschrieben” und “die Änderung ist live” bleibt. Ist Schreiben immer noch der längste Schritt, betrifft dich nichts davon. Ist es der CI-Checkout, das Review oder das Warten auf den Hauptbranch, dann schalte zuerst die Git-Funktionen aus der Tabelle ein und steck die gewonnene Zeit ins Review, den einen Schritt, den noch kein Werkzeug billiger gemacht hat.

Und wenn du überlegst, wie Agenten überhaupt in den Ablauf eines Teams kommen, ist das die Frage, mit der wir in der Produktentwicklung anfangen: nicht, wie schnell der Code ankommt, sondern was das Team damit macht, wenn er da ist.