90 % des Codes wird von KI geschrieben, wer überprüft ihn? Claude Code stellt 6 Prüfstufen vor!
Claude Code hat etwa 90 % seines eigenen Codes bereits Claude zum Schreiben überlassen.
Da KI nun das Schreiben von Code übernimmt, ist die Anzahl der Änderungen sprunghaft angestiegen: Von Juni bis September hat sich die Anzahl der PRs, die in das Code-Repository zusammengeführt wurden, mehr als verdoppelt.
Bei Anthropic insgesamt ist die Anzahl der täglich im Haupt-Repository zusammengeführten Änderungen von etwa 2500 im Mai auf über 30.000 im September gestiegen.
Kann der Mensch bei so viel Code überhaupt noch nachkommen, alles zu lesen? Und wenn auch die Prüfung an KI übergeben wird, wer beurteilt dann, ob sie Fehler macht?
Am 15. Oktober hat das Claude-Code-Team seinen internen Code-Prüfprozess offengelegt und mitgeteilt, dass der Anteil der PRs, die zurückgerollt werden müssen, trotz der Verdopplung der PR-Anzahl um mehr als 40 % gesunken ist.
Um dies zu erreichen, setzen sie auf sechs Prüfstufen plus ein Sicherheitsnetz zur schnellen Fehlererkennung und sofortigen Rückrollung.
Die Einschätzung des Claude-Code-Teams lautet:
Bei diesem Umfang ist eine zeilenweise manuelle Prüfung nicht mehr praktikabel.
Aber sie haben die Prüfung nicht abgeschafft, sondern den Großteil der Arbeit des Code-Lesens an Maschinen übergeben.
Ein von KI geschriebener Code muss vor der Veröffentlichung zuerst Tests durchlaufen, eine KI- und Sicherheitsprüfung bestehen und dann je nach Risiko entscheiden, ob eine menschliche Genehmigung erforderlich ist.
Aus Sicht des Claude-Code-Teams ist die Frage „Hat jemand diesen Code gelesen?“ nicht präzise genug.
Die eigentliche Frage sollte lauten:
Welche Fehler können bei dieser Änderung auftreten und durch welche Prüfstufe sollen sie aufgehalten werden, falls sie auftreten?
Vor der manuellen Prüfung legt die KI zuerst die Prüfergebnisse vor
Jede Änderung durchläuft sechs Prüfstufen und hat am Ende noch ein Sicherheitsnetz.
Die erste Stufe findet vor der Erstellung des Merge-Requests (PR) statt.
Claude muss Tests ausführen und den Build abschließen; bei Änderungen, die die Benutzeroberfläche betreffen, müssen Screenshots mit dem Designentwurf verglichen werden.
Anschließend wird ein Sub-Agent mit völlig neuem Kontext beauftragt, die Code-Differenz zu prüfen – er war nicht am Schreiben des Codes beteiligt und ist ausschließlich dafür zuständig, Fehler zu finden.
Die offizielle Anforderung ist klar formuliert:
Claude muss die ausgeführten Befehle und deren Ausgaben vorlegen – eine bloße Antwort „Alle Tests bestanden“ reicht nicht aus.
Normale Entwickler können dies nachahmen: Wenn Sie der KI Aufgaben zuweisen, erklären Sie gleichzeitig klar, wie die Ergebnisse zu prüfen sind.
Die zweite Stufe ist die KI-Prüfung auf der PR selbst.
Mehrere Agenten suchen parallel nach Bugs, eine weitere Gruppe stimmt dann über die Ergebnisse ab. Erst wenn genügend Stimmen vorliegen, werden die Probleme auf der PR angezeigt.
Hinweise, die sich nur auf Codestil, Diagnosehinweise oder Code-Bereinigung beziehen, werden nicht an die PR übermittelt, sondern direkt herausgefiltert.
Als diese Prüfung im März dieses Jahres eingeführt wurde, stieg der Anteil der internen PRs mit substanziellen Prüfhinweisen von 16 % auf 54 %.
Die dritte Stufe ist die Sicherheitsprüfung.
Im Team kann eine PR nicht zusammengeführt werden, solange Feststellungen aus der Code- oder Sicherheitsprüfung nicht abgeschlossen sind: Entweder wird der Fehler behoben, oder es wird ein Grund angegeben, um die Prüfhinweise zu schließen.
Die vierte Stufe ist die CI-Prüfung (Continuous Integration), die Codestandards, Typenprüfungen, plattformspezifische Tests und Build-Pakete umfasst.
Eine gewöhnliche Änderung an einem Kommandozeilentool (CLI) durchläuft möglicherweise Dutzende von Prüfungen, bevor sie zur menschlichen Prüfung übergeben wird.
Wiederholt auftretende Probleme werden zudem als Grundlage für zukünftige Prüfungen aufgenommen.
CLAUDE.md dokumentiert Projektvereinbarungen, REVIEW.md teilt dem Prüfer mit, worauf besonders zu achten ist und was übersprungen werden kann – so werden die bei dieser Prüfung gefundenen Probleme zu Erfahrungen für zukünftige Prüfungen.
Wenn derselbe Hinweis zum dritten Mal auftaucht, sollte er in die Regeln aufgenommen werden.
Die fünfte Stufe ist die manuelle Genehmigung, diese Stufe ist am wichtigsten und wird im nächsten Abschnitt ausführlich erläutert.
Die sechste Stufe ist Zusammenführung und Veröffentlichung.
Nachdem die Änderung die vorherigen Stufen bestanden hat, wird sie in die Merge-Warteschlange gestellt.
Wenn sie an der Reihe ist, platziert das System sie auf der neuesten Version des Hauptzweigs und führt alle Prüfungen erneut aus.
Dieser Schritt verhindert das Szenario „Jeder Teil funktioniert für sich, aber zusammen treten Fehler auf“.
Nach der Zusammenführung wird die neue Funktion nicht sofort allen Benutzern bereitgestellt.
Sie ist zunächst hinter einem Funktionsschalter verborgen und nur für interne Mitarbeiter von Anthropic zugänglich. Die Mitarbeiter nutzen sie täglich intensiv und stoßen oft früher auf Probleme als externe Benutzer.
Der Funktionsschalter fungiert wie ein Hauptschalter: Ohne Code zu ändern oder eine neue Version zu veröffentlichen, kann entschieden werden, ob die Funktion aktiviert oder deaktiviert wird.
Zuletzt kommt das Sicherheitsnetz zum Einsatz.
Wenn ein Problem auftritt, wird zuerst der Hauptschalter gezogen.
Das Team arbeitet wöchentlich im Schichtdienst, und bei jedem Unfall wird in der Nachbereitung gefragt: In welcher Stufe hätte dieses Problem eigentlich aufgehalten werden müssen?
Die Prüfung ist also nicht verschwunden, sondern wurde zu einer schichtweisen Kontrolle, die Entwicklung, Zusammenführung und Veröffentlichung durchzieht.
Wo liegt die Grenze der vollständig automatisierten Genehmigung ohne menschliche Beteiligung?
Nachdem die ersten vier Stufen alle grünes Licht gegeben haben, entscheidet die fünfte Stufe je nach Risikostufe, wie viele Personen diese Änderung genehmigen müssen.
Dokumente, Texte, nur intern sichtbare Funktionen und neue Änderungen, die hinter dem Schalter verborgen sind, gelten als niedrigrisikig: Nach bestandener automatischer Prüfung und Sicherheitsprüfung können sie ohne manuelle Genehmigung freigegeben werden.
Für gewöhnliche Produktänderungen sowie sensible Bereiche wie Cache, automatische Updater und System-Prompts ist eine Person erforderlich.
Für den Code mit dem höchsten Risiko sowie einige wenige festgelegte Pfade sind zwei Personen erforderlich.
Sieht es so aus, als würden niedrigrisikige Änderungen bereits „autonom fahren“?
So einfach ist es nicht.
Die Risikostufe wird durch die Änderung selbst bestimmt: Der erste Klassifikator liest den Code und legt das Risiko fest, der zweite beurteilt, ob eine zusätzliche manuelle Genehmigung erforderlich ist.
Vom Code-Eigentümer markierte sensible Pfade sowie alle CI-Workflow-Dateien müssen von einer Person geprüft werden.
Der leichte Genehmigungsweg hat ebenfalls Zugangsvoraussetzungen: Er steht nur Personen auf der Liste der „vertrauenswürdigen Autoren“ des Repositorys offen, Personen außerhalb der Liste müssen zusätzlich eine weitere Person zur Genehmigung hinzuziehen.
Die Person, die die KI zum Schreiben von Code anweist, gilt selbst als Prüfer und muss wie beim manuellen Schreiben von Code für diese Änderung verantwortlich sein.
Eine vollständig automatisierte Genehmigung ohne menschliche Beteiligung bedeutet nicht, dass niemand verantwortlich ist.
Der Mensch muss entscheiden, ob die Funktion umgesetzt werden soll, ob die Architektur sinnvoll ist und ob die vorhandenen Prüfungen das Risiko dieser Änderung abdecken können.
Daher gibt es im Claude-Code-Team eine Regel: Wenn der Code, den Sie zusammengeführt haben, Probleme verursacht, sind Sie normalerweise dafür verantwortlich, ihn zu beheben.
Bevor Sie die Genehmigung erteilen, muss der Prüfer klarstellen, was diese Prüfungen validiert haben und welche Risiken noch nicht abgedeckt sind.
Wenn Sie es nicht klar erklären können, sollten Sie nicht eilig die Freigabe erteilen, sondern zuerst die erforderlichen Prüfungen ergänzen.
Auch KI-Prüfungen können versagen
Automatisierte Prüfungen können sich auch selbst blockieren.
Eine PR für ein CLI-Projekt durchlief über Nacht mehr als fünfzig Prüf- und Reparaturrunden, bis der Autor sie manuell stoppte.
Ein Mensch kann eine Kleinigkeit in einer Sekunde übersehen, aber die KI tut das nicht: Sie wird gewissenhaft versuchen, den Fehler zu beheben, danach folgt ein neuer Commit und eine neue Prüfrunde.
Das Team hat mit git blame zurückverfolgt und festgestellt, dass etwa 59 % der von dem Prüfer wiederholt markierten Probleme alter Code waren, der bereits vor der ersten Prüfung existierte. Er hat selten neue Bugs gefunden, sondern nur in jeder Runde einige alte ausgegraben.
Später haben sie vier Regeln geändert:
Wenn nach drei Runden noch keine Freigabe erfolgt ist, wird der Autor daran erinnert, einen Schritt zurückzutreten und den Lösungsansatz neu zu überdenken;
Nach den ersten Runden wird nur noch die neu hinzugefügte Änderung geprüft;
Gleichartige Probleme werden auf einmal aufgeführt;
Bereits genannte Probleme werden nicht wiederholt.
Die Wirkung war sofort sichtbar.
Der Anteil der internen PRs, die nach einer einzigen Prüf- und Reparaturrunde bestanden wurden, stieg von 65 % auf 78 %; der Anteil der PRs, die fünf oder mehr Runden benötigten, sank von 8,9 % auf 1,5 %; die durchschnittliche Anzahl der Prüfungen sank von 2,08 auf 1,32.
Nach der Anpassung der Regeln für erneute Prüfungen stieg die Bestehensrate nach einer Prüf- und Reparaturrunde von 65 % auf 78 %, die durchschnittliche Anzahl der Prüfungen sank von 2,08 auf 1,32.
Die Kunst der Prüfung besteht zur Hälfte darin, Probleme zu finden, und zur Hälfte darin, zu wissen, wann man aufhören muss.
Ist eine mehrschichtige Prüfung absolut narrensicher?
Anthropic selbst hat ein Gegenbeispiel geliefert.
Am 26. März hat Claude Code eine Optimierung eingeführt: Wenn eine Sitzung länger als eine Stunde inaktiv ist, werden alte Inferenzaufzeichnungen bereinigt.
Aber ein Bug führte dazu, dass dieser Bereinigungsvorgang in jeder Runde nach der Wiederaufnahme des Gesprächs ausgeführt wurde. Infolgedessen wurde Claude vergesslich, begann sich zu wiederholen und nutzte Tools auf ungewöhnliche Weise. Dieser Bug wurde erst am 10. April behoben.
Nach der Inaktivität sollte der alte Inferenzcode nur einmal bereinigt werden, tatsächlich wurde er in jeder Runde fortlaufend gelöscht; der rote Rahmen markiert die versehentlich gelöschten Inhalte.
Die offizielle Nachbereitung vom 23. April bestätigt:
Diese Änderung durchlief mehrere manuelle und automatische Prüfungen, Unit-Tests, End-to-End-Tests und interne Erprobungen konnten sie nicht aufhalten – allein die Bestätigung der Ursache dauerte mehr als eine Woche.
Der Wendepunkt lag in der Nachbereitung.
Das Team hat die fehlerhafte PR mit Code Review erneut geprüft: Wenn der volle Kontext der relevanten Repositorys bereitgestellt wurde, fand Opus 4.7 diesen Bug, Opus 4.6 jedoch nicht.
Dieser Rücktest zeigt, dass sowohl die Fähigkeit des Modells als auch die Vollständigkeit des Kontexts das Prüfergebnis beeinflussen. Daher haben sie die Prüfung so angepasst, dass sie auf mehr Repositorys zugreifen kann.
Heute wird jeder Unfall zu einer Prüfungsaufgabe.
Das Team sammelt die PRs, lässt die mit dem Code vertrauten Ingenieure jeden Bug darin bestätigen und fasst sie zu einem Satz von Prüfungsaufgaben zusammen.
Der Prüfer führt täglich Leistungstests mit diesem Satz von Aufgaben durch. Jede Anpassung von Prompts, Tools oder Modellen wird damit auf ihre Wirkung überprüft: Wenn die Leistung nicht verbessert wird, wird diese Anpassung nicht übernommen.
Das Team hat die Erwartungen auch nicht zu hoch gesteckt.
Nach der Veröffentlichung der Änderung müssen Entwickler und Schichtdienstmitarbeiter anhand von Daten-Dashboards weiterhin Anomalien erkennen.
Ein „Sicherungsmechanismus“, der die Genehmigung automatisch anhand von Kennzahlen wie der Rückrollrate verschärft, ist noch nicht fertiggestellt. Die Ingenieure hoffen, zuerst diese zusätzliche Sicherheit zu ergänzen, bevor mehr Änderungen über die vollständig automatisierte Genehmigung laufen.
<