Anthropics Git-Ersatz: Wenn das Codevolumen die menschliche Prüfung überholt

Wenn ein Werkzeug für menschliches Tempo auf Maschinentempo trifft

Laut Berichten, die sich auf Simon Willsons Niederschrift dieser Änderung zurückverfolgen lassen, hat Anthropic einen eigenen Ersatz für Git gebaut. Der Auslöser war weder ein Bug noch ein Sicherheitsvorfall. Es war das Volumen. Die Rate der Änderungen, die in der Codebasis des Unternehmens landeten, stieg steil an, und bis Mai 2026 lag sie im Durchschnitt bei rund 2.500 Anfragen pro Zeitraum, eine Last, für die herkömmliche Versionskontrolle nicht ausgelegt war.

Es ist leicht, das unter interne Werkzeuge abzulegen und weiterzugehen. Das wäre ein Fehler. Git ist eines der folgenreichsten je geschriebenen Softwarestücke, und es beruht auf einer Reihe von Annahmen darüber, wie sich Code ändert, die in der Praxis nun verletzt werden.

Die Annahmen, auf denen Git gebaut wurde

Gits Entwurf kodiert eine Überzeugung über menschliches Verhalten. Änderungen treffen in einem Tempo ein, das eine Person ansehen kann. Ein Branch steht für eine Absicht, die lange genug dauert, um benannt zu werden. Die Historie ist kostbar, also wird nichts weggeworfen. Ein Maintainer kann einen Diff lesen und sich eine Meinung bilden, bevor er ihn zusammenführt.

Jede dieser Annahmen weicht auf, wenn Agents Code schreiben.

Agents werden nicht müde, also erzeugen sie Änderungen fortlaufend statt in arbeitsgroßen Paketen. Sie halten eine Absicht nicht tagelang, also werden Branches so kurzlebig, dass ihre Benennung nur noch Overhead ist. Sie erzeugen weit mehr Diffs, als ein menschlicher Prüfer sinnvoll lesen kann, was bedeutet, dass der Prüfschritt, um den Gits gesamter Arbeitsablauf herum organisiert ist, vom Schutzmechanismus zum Engpass wird.

Das Ergebnis ist ein System, das weit außerhalb seines Entwurfsrahmens läuft, während alle darauf beharren, dass sich nichts geändert hat. Das Repository funktioniert noch. Der Prozess darum herum bedeutet nicht mehr, was er einmal bedeutete.

Was tatsächlich zuerst bricht

Die naive Sorge gilt dem Speicher. Er erweist sich als das geringste Problem. Festplatten sind billig, und Git komprimiert gut.

Das erste echte Opfer ist die Prüfung. Ein Pull Request, dessen 4.000 Zeilen Diff von einem Agent erzeugt wurden, ist technisch prüfbar und praktisch nicht. Prüfer tun, was Menschen bei Überlast immer tun: Sie überfliegen, vertrauen der Zusammenfassung, genehmigen. Die Prüfung überlebt als Zeremonie und verliert ihre Funktion, was schlimmer ist als ihre Abschaffung, weil die Zeremonie falsches Vertrauen erzeugt.

Das zweite Opfer ist die Identität. Gits Historie ist eine Aufzeichnung dessen, wer wann was entschieden hat. Wenn die meisten Commits von einem Modell stammen, das auf einen Prompt reagiert, enthält die Historie zwar noch Namen, aber die Namen beantworten nicht mehr die Frage, für die die Historie existiert. Man kann einen Agent nicht fragen, warum er vor sechs Wochen einen Ansatz gewählt hat, denn er erinnert sich nicht, und die Commit-Nachricht wurde von demselben System erzeugt, das die Entscheidung getroffen hat.

Das dritte Opfer ist der Branch selbst. Branchen ist in Git billig und in menschlicher Aufmerksamkeit teuer. Wenn Branches schneller zunehmen, als jemand sie beachten kann, entsteht ein Rückstand an Absichten, die niemand mehr hält, und das ist ein anderer Fehler als ein Merge-Konflikt und schwerer zu sehen.

Warum ein Ersatz mehr ist als ein schnelleres Git

Wäre das Problem der Durchsatz, wäre die Lösung ein schnellerer Server. Dass Anthropic etwas Neues baut, legt nahe, dass das Problem strukturell ist.

Ein Versionskontrollsystem, das auf maschinentempo Veränderungen optimiert ist, sähe in konkreten Punkten anders aus. Es würde annehmen, dass die meisten Änderungen flüchtig sind und billig zu erzeugen wie zu verwerfen sein sollten. Es würde den Diff als Zusammenfassung statt als Artefakt behandeln und an jede Änderung eine maschinenlesbare Absicht hängen, damit ein Agent sie später finden kann, ohne den Code zu lesen. Es wäre für Abruf gebaut, nicht für Archäologie.

Es müsste zudem eine Frage beantworten, die Git nie beantworten musste. Git nimmt an, dass das interessante Artefakt der Endzustand des Codes ist. In einem agentgesteuerten Arbeitsablauf ist das interessante Artefakt oft die Begründung, die eine Änderung hervorbrachte, und die Prüfungen, die sie validierten. Wenn diese außerhalb der Versionskontrolle liegen, dann zeichnet die Versionskontrolle nur die Hälfte der Historie auf.

Die Aufzeichnung, an die niemand denkt, bis er sie braucht

Versionskontrolle ist nicht nur ein Ablagesystem. Sie ist das Substrat für Abrechnung, Compliance und Incident-Response. Auditoren wollen wissen, wer wann was geändert hat. Regulierte Branchen wollen eine belastbare Aufzeichnung, die einer Prüfung standhält. Sicherheitsteams rekonstruieren Zeitlinien aus Commits.

Wenn die ehrliche Antwort auf diese Fragen lautet: „Ein Agent hat es getan, auf einem Branch, der nicht mehr existiert, und die Begründung lebte in einem Kontextfenster, das seither verworfen wurde“, dann hat die Aufzeichnung ein Loch. Löcher in Aufzeichnungen sind genau das, was Audits finden sollen, und ein Werkzeug, das sie erzeugt, ohne dass es jemand bemerkt, wäre lange vor einem Skandal ein ernstes Problem.

Das weitere Signal

Anthropic ist nicht allein mit diesem Druck, und die kleineren Versionen derselben Geschichte sind anderswo bereits sichtbar. GitHub hat kürzlich seine Repo-Star-Verlauf-API umgearbeitet, sodass Trenddaten in 24 Anfragen statt in etwa 2.500 zurückkommen, ohne unbegrenzte Datenbankarbeit zu erfordern oder einzelne Star-Nutzer offenzulegen. GitHub lieferte außerdem einen kontextbewussten Klassifikator zur Erkennung von Secrets aus, der die Akzeptanzrate echter Funde um 11,5 Prozent erhöhte und zugleich die mittlere Scan-Zeit um 86 Prozent senkte.

Beides sind Antworten auf dieselbe zugrunde liegende Lage: Die Menge an Code in der Welt steigt, und die Werkzeuge, die entstanden, als Menschen die einzigen Autoren waren, beginnen zu altern. Die Secret-Erkennung ist ein gutes Beispiel. Das Risiko eines geleakten Schlüssels skaliert mit der Menge des geschriebenen Codes, also wird ein System, das bei menschlichen Ausgaberaten ausreichte, bei Agent-Ausgaberaten unzureichend, selbst wenn sich an seinem Entwurf nichts geändert hat.

Der Teil, den niemand laut sagen will

Es gibt eine Version dieser Geschichte, in der KI Softwareteams drastisch produktiver macht und die Werkzeuge aufholen, und alle sind zufrieden.

Es gibt eine andere Version, in der die Menge des generierten Codes die menschliche Fähigkeit, ihn zu verstehen, überholt und die Branche am Ende Repositories hat, die kein einzelner Mensch mehr begreift, zusammengehalten von Tests, die niemand geschrieben hat, und Prüfungen, die niemand durchgeführt hat. Das Erkennungszeichen dieser Version ist kein Absturz. Es ist eine langsame Drift, bei der die Codebasis weiter funktioniert und die Zahl der Menschen, die verstehen, warum, weiter sinkt.

Git zu ersetzen ist in diesem Licht ein Symptom, das Beachtung verdient. Es bedeutet, dass eines der sorgfältigsten Unternehmen der Branche entschieden hat, dass das Standardwerkzeug genau auf der Ebene, auf der Korrektheit verfolgt wird, zur Belastung geworden ist. Das ist kein kleines Eingeständnis. Es ist ein Signal, dass die Infrastruktur der Software schneller verändert werden soll, als ihre Annahmen folgen können.

Die praktische Antwort für alle anderen ist unromantisch. Miss, wie viel deines Codes von Maschinen stammt. Beobachte, ob dein Prüfschritt noch etwas ändert. Achte darauf, ob deine Historie noch das Warum beantworten kann. Das sind billige Fragen, und die Antworten sagen dir, ob du ein neues Werkzeug brauchst oder nur eine neue Gewohnheit.