Anthropic ersetzt git und mergt über 30.000 Codeänderungen pro Tag
Anthropic hat rund 30.000 Codeänderungen täglich in sein Monorepo integriert, Tendenz stark steigend. Weil git zum Flaschenhals wurde, entwickelte ein Sieben-Personen-Team ein eigenes Versionierungssystem.
Veröffentlicht am 15. Oktober • Zuerst erschienen auf reado.watermelon-studio.it
Am 13. Oktober hat Anthropic veröffentlicht, wie das Unternehmen git für sein Monorepo ersetzt hat. Die Zahlen sind die Schlagzeile: rund 2.500 täglich zusammengeführte Codeänderungen im Mai 2026, mehr als 30.000 pro Tag bis September. Bei diesem Tempo wurde git selbst zum Engpass, also baute ein siebenköpfiges Team ein neues Versionskontrollsystem namens Scion, dazu ein Code-Review-Tool und ein halbes Dutzend verwandter Systeme, und migrierte alles innerhalb von fünf Monaten.
Die meisten Reaktionen, die ich gesehen habe, verliefen in dieselbe Richtung: Wenn Agents dreißigtausend Änderungen pro Tag zusammenführen, was bleibt dann für einen Menschen zu tun? Das ist eine berechtigte Frage. Der Beitrag beantwortet sie, und die Antwort lautet nicht „nichts“.
Der Beitrag beginnt mit der Aussage, von der alles Übrige abhängt: Bei Anthropic ist das Schreiben von Code nicht mehr der Engpass. Die Infrastruktur ist es, die für menschliches Maß gebaut wurde: Quellcodeverwaltung, Builds, CI. Die Main-History ihres Monorepos umfasst fast 100 GB, der Code wird in der Größenordnung von 25 Millionen Mal pro Tag für CI ausgecheckt, und auf dem Höhepunkt betrieben sie mehrere hundert interne git-Mirrors, um Schritt zu halten.
Sie betonen ausdrücklich, dass dies ungewöhnlich ist. Scion ist „keineswegs ein geeigneter Ersatz für git für den allgemeinen Gebrauch“, es ergibt nur Sinn für enorme Monorepos, und Anthropic kann weit mehr Tokens in die eigene Arbeit investieren als jedes normale Unternehmen. Die meisten Teams sind so weit noch nicht. Die Autoren erwarten, dass andere innerhalb von sechs bis zwölf Monaten unter demselben Druck stehen werden.
Also gehört die Größenordnung ihnen. Die Verschiebung darunter gehört nicht ihnen allein. Code zu produzieren ist billig geworden.
Der Abschnitt, den ich zweimal lesen würde, ist der über die Menschen. Jeder, der an Scion gearbeitet hat, schätzt inzwischen Claude beim Schreiben von Code als besser als sich selbst ein. Und doch haben die Ingenieure die Teile beigetragen, die darüber entschieden, ob das System funktionieren würde: das Verständnis davon, wie Komponenten zusammenspielen, die Design-Trade-offs, die Entscheidung, welche Probleme gelöst werden sollen und in welcher Größenordnung.
Dann der Satz, der alles zusammenfasst: Sehr oft bestand die Rolle der Ingenieure darin, Claude „Nein“ zu sagen.
Die Beispiele sind konkret. Agents haben manchmal Kernbeschränkungen eines Systems gebrochen, um ein Muster zu erfüllen, das niemals hätte erlaubt sein dürfen: Einige Systeme versuchten herauszufinden, wann eine Änderung zusammengeführt worden war, indem sie das Commit-Log Zeile für Zeile lasen, statt das Code-Review-Tool zu fragen. Ihr adversariales Review, das sie intensiv nutzen und als wirksam bezeichnen, konnte auch kurzsichtig sein: Ein Review war so defensiv darin, einem anderen internen Dienst zu vertrauen, dass Claude Validierung und Komplexität hinzufügte, die niemand brauchte, und die Ingenieure mussten es von der zusätzlichen Komplexität wegführen.
Keines davon ist ein Fehler, den ein Test finden würde. Bei beidem handelt es sich um Code, der funktioniert und trotzdem nicht existieren sollte.
Der Satz, den ich erwartet hatte zu finden und nicht fand, war „wir haben das Review abgeschafft“. Stattdessen: Das Team prüft weiterhin jede Änderungsanfrage am System, aber die Reviewer schauen sich inzwischen die Absicht der Änderung an, statt jede Codezeile zu lesen.
Auch das Tooling ist um dieselbe Idee herum gebaut. Ihr Code-Review-Tool kann Regeln ausdrücken, welche Änderungen welche Freigaben benötigen, sodass eine rein kommentarbezogene Änderung und eine sensible Änderung an der Logik nicht gleich behandelt werden. Der Punkt sei, so ihre Worte, dass menschliche Reviewer sich auf die Folgenreichsten Änderungen konzentrieren können.
Setzt man das zusammen, ergibt sich eine andere Stellenbeschreibung. Der Mensch ist nicht derjenige, der den Code produziert, und auch kein Zeile-für-Zeile-Korrekturleser. Der Mensch entscheidet, wofür die Änderung gedacht ist, ob sie existieren sollte und welche Teile davon ausreichend riskant sind, um sie genauer anzusehen.
Das ist die Antwort auf die Frage, wozu die Menschen da sind, und ich denke, sie gilt weit unterhalb der Größenordnung von Anthropic.
Wenn ein Agent zehn Versionen einer Funktion schreiben kann, in der Zeit, in der du eine schreibst, liegt der Preis von Code nicht mehr in dessen Erstellung. Er liegt in allem, was kommt, nachdem man ihn behält: die nächste Person, die ihn verstehen muss, die Beschränkung, die er stillschweigend bricht, die Komplexität, die er hinzufügt und die jemand jahrelang warten wird. Code zu generieren ist billig. Zu entscheiden, welcher Code es wert ist, behalten zu werden, ist teuer, denn jedes „Ja“ ist eine Verpflichtung.
Anthropics Ingenieure investieren ihre Aufmerksamkeit genau in diese Entscheidung. Nicht ins Tippen und auch nicht ins Lesen jeder Zeile, sondern darin, der Änderung, die das falsche Problem löst, abzulehnen, und darin, die wenigen Stellen zu finden, an denen eine Änderung folgenreich genug ist, um sie genau anzusehen.
Genau für diese Aufgabe baue ich Reado, die IDE zum Lesen des Codes, den dein AI-Agent schreibt, allerdings auf einer viel kleineren Skala: ein Entwickler, ein Agent, ein Repository.
Reado entscheidet nicht für dich, welche Änderungen wichtig sind. Es gibt dieser Entscheidung einen Ort. In einem geführten Review plant der Agent eine Route durch die Änderung in der Reihenfolge, die sie verständlich macht, und du hinterlässt Kommentare genau an den Zeilen, die ein „Nein“ oder eine Frage brauchen. Jeder Kommentar ist entweder eine Aufgabe, die der Agent lösen muss, oder eine Notiz für den nächsten Leser, und er wird als Markdown in deinem Repository gespeichert, sodass der Grund, warum eine Zeile so aussieht, wie sie aussieht, die Sitzung überdauert. Wenn du möchtest, dass der Agent zuerst hinschaut, kommen seine Ergebnisse als Vorschläge an, und nichts wird zu einer Aufgabe, bis du sie akzeptierst.
Anthropic hat Scion wegen des Volumens gebaut. Du hast wahrscheinlich nicht ihr Volumen. Du hast aber dieselbe Entscheidung zu treffen, jedes Mal, wenn dir ein Agent einen Diff übergibt: Ist das es wert, behalten zu werden?
Die Reado-App ist kostenlos und MIT-lizenziert, wenn du sie ausprobieren möchtest: Lade sie hier herunter.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 15 • Originally published at reado.watermelon-studio.it
On 13 October, Anthropic published how it replaced git for its monorepo. The numbers are the headline: around 2,500 code changes merged per day in May 2026, more than 30,000 per day by September. At that rate git itself became the bottleneck, so a team of seven built a new version control system, Scion, plus a code review tool and half a dozen related systems, and migrated everything in five months.
Most of the reactions I saw took the same turn: if agents merge thirty thousand changes a day, what is left for a person to do? It's a fair question. The post answers it, and the answer isn't "nothing".
The post opens with the claim the rest depends on: at Anthropic, writing code is no longer the bottleneck. The infrastructure built for human scale is: source control, builds, CI. Their monorepo's main history is almost 100 GB, they check out code on the order of 25 million times a day for CI, and at their peak they were running several hundred internal git mirrors to keep up.
They're careful to say this is unusual. Scion is "by no means a suitable replacement for git for general use", it only makes sense for enormous monorepos, and Anthropic can spend far more tokens on its own work than any normal company would. Most teams aren't there yet. The authors expect others to start feeling the same pressure within six to twelve months.
So the scale is theirs. The shift underneath it isn't. Producing code got cheap.
The section I'd read twice is the one about people. Everyone who worked on Scion, the post says, now rates Claude as better at writing code than themselves. And yet the engineers supplied the parts that decided whether the system would work: the understanding of how components fit together, the design trade-offs, the choice of which problems to solve and at what scale.
Then the line that sums it up: very often the engineers' role was to tell Claude "no".
The examples are specific. Agents sometimes broke core system constraints to satisfy a pattern that should never have been allowed: some systems tried to find when a change had merged by reading the commit log line by line, instead of asking the code review tool. Their adversarial review, which they use heavily and call effective, could also be myopic: one review was so defensive about trusting another internal service that Claude added validation and complexity nobody needed, and engineers had to steer it away from the extra complexity.
Neither of those is a bug a test would catch. Both are code that works and shouldn't exist.
The sentence I expected to find, and didn't, was "we stopped reviewing". Instead: the team still reviews every change request to the system, but reviewers now look at the intent of the change rather than reading every line of code.
The tooling is built around the same idea. Their code review tool can express rules about which changes need which approvals, so a comment-only change and a sensitive change to the logic aren't treated alike. The point, in their words, is that human reviewers can focus on the most consequential changes.
Put those together and you get a different job description. The human isn't the one producing the code, and isn't a line-by-line proofreader either. The human decides what the change is for, whether it should exist, and which parts of it carry enough risk to look at closely.
That's the answer to "what are the humans for", and I think it holds well below Anthropic's scale.
When an agent can write ten versions of a function in the time it took you to write one, the cost of code isn't in producing it anymore. It's in everything that comes after you keep it: the next person who has to understand it, the constraint it quietly breaks, the complexity it adds that someone will maintain for years. Generating code is cheap. Choosing which code is worth keeping is expensive, because every "yes" is a commitment.
Anthropic's engineers spend their attention on exactly that choice. Not on typing, and not on reading every line, but on saying no to the change that solves the wrong problem, and on finding the few places where a change is consequential enough to look at closely.
This is the job I'm building Reado, the IDE for reading the code your AI agent writes, for, at a much smaller scale: one developer, one agent, one repository.
Reado doesn't decide for you which changes matter. It gives that decision a place to live. In a guided review the agent plans a route through the change in the order that makes it make sense, and you leave comments on the exact lines that need a "no" or a question. Each comment is either a task the agent has to resolve or a note for the next reader, and it's stored as Markdown in your repository, so the reason a line looks the way it does outlives the session. When you want the agent to look first, its findings arrive as proposals, and nothing becomes a task until you accept it.
Anthropic built Scion because of the volume. You probably don't have their volume. You do have the same choice to make, every time an agent hands you a diff: is this worth keeping?
The Reado app is free and MIT-licensed if you want to try it: download it here.