Doppelt so viel Code, weniger Rücknahmen: Wie Anthropic aufhörte, alles zu lesen

Am 15. Oktober 2026 veröffentlichte das Team hinter Claude Code, Anthropics Programmierassistenten, einen Bericht über die Prüfung seines eigenen Codes. Der Ausgangspunkt ist ungewöhnlich: Claude schreibt ungefähr 90% des Codes von Claude Code. Zwischen Juni und September verdoppelte sich die Zahl integrierter Änderungen mehr als, während der Anteil später zurückzunehmender Änderungen um über 40% sank. Mehr Produktion bei niedrigerer Fehlerquote wurde möglich, weil das Team nicht mehr fragte: «Hat ein Mensch alles gelesen?» Stattdessen fragte es, welche automatisierte oder menschliche Kontrolle welchen Fehler auffangen sollte.

Doppelt so viele Änderungen, 40% niedrigerer Rücknahmeanteil

Ein Softwareteam ändert sein Produkt nicht unmittelbar. Jede Änderung durchläuft einen Pull Request: einen Vorschlag, der geprüft und anschliessend in den Hauptcode übernommen wird. Verursacht eine bereits integrierte Änderung einen Fehler und wird wieder entfernt, spricht man von einem Revert, einer Rücknahme. Das sind Anthropics zwei Kennzahlen.

Der Rückgang betrifft den Anteil zurückgenommener Änderungen, nicht ihre Anzahl. Rechnet man mit den genannten Schwellen, also doppeltem Volumen und einem Anteil zum Faktor 0.6, wäre die Zahl der Rücknahmen bei doppeltem Volumen um etwa 20% gestiegen. Diese Rechnung stammt von uns; Anthropic veröffentlicht die Zahl nicht. Der Befund lautet: Das Volumen verdoppelte sich, ohne dass die Rücknahmen im selben Tempo zunahmen.

Niemand kann mehr alles lesen: 30’000 Änderungen täglich

Anthropic hält den grössten Teil seines Codes in einem einzigen grossen Repository. Im Mai wurden dort täglich ungefähr 2’500 Änderungen integriert. Im September waren es mehr als 30’000.

Bei diesem Tempo liest kein Mensch jede Zeile. Das Team zog die Konsequenz: «Hat ein Mensch den Code gelesen?» ist aus seiner Sicht nur ein ungenauer Ersatzindikator. Die richtige Frage lautet: Was kann schiefgehen, und welche Kontrolle sollte es auffangen? Knapp ist nicht mehr Code, sondern menschliche Aufmerksamkeit. Das Ziel ist, die meisten Änderungen mit höchstens einem beteiligten Menschen zu integrieren. Dieser kann der Autor sein.

Die Leitplanke passt in einen Satz: Steigen Rücknahmen oder Vorfälle, wurde keine menschliche Zeit gespart, sondern nur von der Prüfung zur Fehlerbereinigung verlagert. Effizienz wird deshalb am Ende des Prozesses gemessen. Das Team erfasst menschliche Freigaben pro Änderung, Wartezeiten auf Personen sowie als Gegenkontrolle Rücknahmen und Vorfälle.

Sieben Kontrollebenen, die gegenseitig ihre Lücken auffangen

1. Prüfung vor dem Änderungsvorschlag. Claude erhält eine Möglichkeit, seinen Code auszuführen: Tests, einen Build oder einen Screenshot zum Vergleich mit dem Entwurf. Es muss das Ergebnis zeigen, statt bloss die Fertigstellung zu verkünden. Boris Cherny, der Claude Code entwickelt hat, schätzt die Verbesserung des Endergebnisses dadurch auf den Faktor zwei bis drei. Ein zweiter Agent prüft die Änderung mit frischem Kontext.
2. Agentenprüfung bei jeder Änderung. Mehrere Agenten suchen parallel nach Fehlern. Eine weitere Gruppe stimmt über jeden Befund ab. Nur Befunde, bei denen Einigkeit besteht, werden veröffentlicht. Jeder muss behoben oder begründet geschlossen werden.
3. Eine blockierende Sicherheitsprüfung. Solange ein Befund offen ist, wird die Änderung nicht integriert.
4. Verpflichtende automatisierte Prüfungen. Codestil, Typen, plattformübergreifende Tests und Build. Das Formular jeder Änderung fragt, wie sie getestet wurde und wie sie rückgängig gemacht werden kann.
5. Dem Risiko angepasste menschliche Freigabe, wie nachfolgend beschrieben.
6. Eine Integrationswarteschlange, dann schrittweise Veröffentlichung. Die Warteschlange führt alle Prüfungen erneut auf dem neuesten Code aus. Neue Funktionen erreichen zuerst Anthropics eigene Beschäftigte, hinter einem Schalter zum Aktivieren oder Deaktivieren.
7. Schnelle Erkennung und Rücknahme. Der Schalter deaktiviert eine Funktion ohne neue Veröffentlichung. Das Bereitschaftsteam prüft jede Woche, welche Ebene den jeweiligen Vorfall hätte auffangen müssen.

Risiko	Beispiele	Menschliche Freigaben
Niedrig	Dokumentation, Texte, interne Funktionen, Ergänzungen hinter einem Schalter	Keine, sobald automatisierte und Sicherheitsprüfungen bestanden sind
Mittel	Übliche Produktänderungen, sensible Bereiche wie Cache, automatischer Updater und Modellanweisungen	Eine Person
Hoch	Code mit den höchsten Risiken	Zwei Personen

Ein Klassifikator bestimmt die Stufe anhand der Änderung selbst, nicht anhand ihres Autors. Einige Dateien, etwa jene zur Steuerung automatisierter Prüfungen, verlangen immer eine menschliche Freigabe.

Zwei Regeln, die zuerst übernommen werden sollten

Erstens: Die Freigabe eines Agenten zählt nie als menschliche Freigabe. Eine automatisierte Prüfung kann eine Änderung mit niedrigem Risiko freigeben. Sie ersetzt aber keine vorgeschriebene Person. Zweitens: Wer die Änderung beauftragt hat, trägt die Verantwortung dafür, als hätte er den Code selbst geschrieben. Bei agentengeschriebenem Code zählt die steuernde Person als erforderlicher Prüfer. Eine Freigabe gilt ausserdem für genau eine Version. Eine Ergänzung, die der Prüfer nicht gesehen hat, braucht eine neue Freigabe.

Auch der Prüfer wird geprüft

Der automatisierte Prüfer verbessert sich in einer Rückkopplungsschleife. Jeder frühere Vorfall wird zu einem von Experten bestätigten Testfall. Täglich wird der Prüfer an allen diesen Fällen gemessen. Dabei entstand ein neues Problem: Ein schreibender und ein prüfender Agent können sich endlos gegenseitig beschäftigen. Der Prüfer meldet einen Fehler, der Agent behebt ihn, der Prüfer findet den nächsten. Eine Änderung durchlief über Nacht mehr als 50 Runden, bis ein Mensch manuell eingriff. Inzwischen fordert der Prüfer den Autor nach drei Runden auf, Abstand zu nehmen und den Ansatz zu überdenken.

Kennzahl (Anthropic)	Vorher	Nachher
Änderungen mit inhaltlich relevanten Kommentaren	16%	54%
Änderungen, die nach einer Prüfrunde bestehen	65%	78%
Änderungen mit mindestens fünf Prüfrunden	8.9%	1.5%
Durchschnittliche Prüfungen bis zur Freigabe	2.08	1.32

Menschen sind nicht verschwunden. Sie entscheiden, ob eine Funktion überhaupt gebaut werden soll, prüfen riskanten Code wie Abrechnung, automatischen Updater und Steuerungsdateien, beurteilen Architekturentscheidungen, die andere übernehmen werden, lesen die Nachweise wie Testergebnisse, Screenshots und Prüfbefunde und verantworten die Folgen.

Keine neue Idee: Maschinen prüfen seit Langem Maschinen

Niemand kontrolliert jedes Internetpaket von Hand. Das TCP-Protokoll versieht Pakete mit einer Prüfsumme und fordert beschädigte oder ausgebliebene Pakete erneut an. Serverspeicher korrigiert ein gekipptes Bit selbst durch fehlerkorrigierende Codes. Eine Datenbank protokolliert jede Änderung, ein Bereitschaftsserver spielt sie nach, weitere Prozesse überwachen ihn. Die mehr als fünf Jahrhunderte alte doppelte Buchführung erfasst jede Transaktion im Soll und im Haben, damit die Bücher aufgehen müssen. 1948 zeigte Claude Shannon, dass Nachrichten über einen gestörten Kanal verlässlich übermittelt werden können, wenn man die richtige Redundanz hinzufügt.

Verlässlich wurden diese Systeme nie dadurch, dass ein Mensch jeden Schritt kontrollierte. Verlässlich wurden sie, weil Maschinen andere Maschinen prüfen, anhand von Menschen entworfener Kontrollen. Agentengeschriebener Code schliesst an diese Tradition an.

Der Engpass hat sich verschoben

Schnelleres Schreiben verschiebt den Engpass zum Lesen. 2025 analysierte Faros AI Daten von mehr als 10’000 Entwicklern in 1’255 Teams. Intensive KI-Nutzer integrierten 98% mehr Pull Requests, doch die Prüfzeit stieg um 91%, die Fehlerzahl pro Entwickler um 9% und die durchschnittliche Änderungsgrösse um 154%. Auf Unternehmensebene fand die Studie keine signifikante Verbesserung bei Auslieferungsdurchsatz oder Qualität. Faros verkauft Messwerkzeuge und misst Aktivität, nicht gelieferten Wert. Es handelt sich um Korrelationen. Dennoch beschreiben sie die Grenze, auf die Teams stossen, wenn sie beschleunigen, ohne die Prüfung neu zu gestalten.

Anthropics Methode setzt eine Grundlage voraus. Das Team kann die menschliche Prüfung reduzieren, weil dort fast alles reversibel ist: ausführbare Tests für Agenten, Funktionsschalter, schrittweise Einführung und Rücknahmen binnen Minuten. Ohne diese Grundlage ist weniger Prüfung keine Option. Das Team räumt zudem eine Lücke ein: Noch gibt es keinen automatischen Schutzmechanismus, der bei steigenden Rücknahmen oder Vorfällen strengere Freigaben verlangt. Die Ingenieure wollen ihn einrichten, bevor mehr Code ohne menschlichen Prüfer integriert wird.

Was wir daraus für eine Organisation ableiten

• Wartezeiten messen, nicht Codezeilen. Die produzierte Codemenge sagt nichts über Effizienz. Die Wartezeit einer Änderung auf eine Person, die Freigaben pro Änderung und die Rücknahmequote tun es.
• Erst die Grundlage schaffen, dann den Hahn öffnen. Tests, die ein Agent ausführen kann, Funktionsschalter, schrittweise Einführung und schnelle Rücknahme. Streng beginnen und erst lockern, wenn die Nachweise es rechtfertigen.
• Jede wiederkehrende Prüfung in eine Regel, einen Test oder ein Werkzeug überführen. Den automatisierten Prüfer täglich am schlimmsten Vorfall der eigenen Organisation testen: Niemand sonst besitzt genau diesen Testfall.
• Eine Person in der Verantwortung halten. In einer regulierten Institution lautet die nützliche Frage, wer jede Änderung freigibt und wer dafür einsteht. Das ist das Vieraugenprinzip, angewendet auf einen Prüfer, der nie schläft.

Alle können Zugang zu denselben Modellen kaufen. Organisationen unterscheiden sich darin, ob sie ihre Abläufe um diese Modelle herum neu aufbauen und Menschen dort behalten, wo Urteil, Vertrauen und Verantwortung nicht delegiert werden können.