Wie das Claude Code-Team Code-Reviews durchführt

Wir haben bereits gesagt, dass Claude etwa 90 Prozent des Codes von Claude Code selbst schreibt. Wie können wir also den Code in der Menge, die wir erzeugen, überprüfen? Liest jemand noch Code? Und wenn etwas kaputtgeht, wer bemerkt es?

Dieser Artikel beschreibt den Code-Review-Prozess im Claude Code-Team und wie dieser sich entwickelt hat. Von Juni bis September stiegen die zusammengeführten Pull Requests zum Codebase von Claude Code um mehr als das Doppelte, während der Anteil der Requests, die zurückgesetzt werden mussten, um mehr als 40 Prozent abnahm.

Wir haben die Überprüfung nicht entfernt. Aber wir haben den größten Teil des Lesens an Maschinen übergeben, diese so optimiert, dass sie den menschlichen Zeit und Aufmerksamkeitsbedarf berücksichtigen, und viel investiert, um es schnell und einfach zu machen, um Fehler rückgängig zu machen.

Überdenken des Zwecks der Code-Überprüfung

Wenn Agenten Code schreiben, steigt die Anzahl der Änderungen schnell an. Im monolithischen Repos von Anthropic stiegen die täglichen Änderungen im Mai von etwa 2.500 auf mehr als 30.000 im September dieses Jahres.

Claude Code lebt in seinem eigenen Repository, getrennt vom Monorepo, aber es erlebt auch viel Druck. Wenn man diesen schnellen, manuellen, Zeile für Zeile zu überprüfenden Code versendet, ist die Code-Review-Prozess unglaublich schwierig – wenn nicht sogar unmöglich.

Der Code-Review erfüllt zwei Aufgaben:

1. Finden und beheben Sie die Probleme, bevor sie veröffentlicht werden
2. Erstelle eine gemeinsame Kontext- und Codebase-Verständnis im gesamten Team

Dieser Artikel konzentriert sich hauptsächlich auf die Erkennung und Behebung von Problemen, aber wir werden am Ende wieder zum zweiten Aufgabe zurückkehren.

Wir glauben, dass „ein Mensch den Code gelesen hat?“ ein ungenauer Proxy für „was könnte mit dieser Änderung schiefgehen und welche Überprüfung – automatisch oder menschlich – ist die richtige, um das zu erkennen?“ ist.

Durch diese Frage änderte sich auch wann die Überprüfung stattfindet. Früher war die Überprüfung eine Tür am Ende des Weges: Schreiben Sie den Code, öffnen Sie einen PR und warten Sie auf Ihren Kollegen.

Jetzt werden die Texte kontinuierlich überprüft, ähnlich wie eine Rechtschreibprüfung während des Schreibens. Die meisten Änderungen wurden mindestens einmal von Claude überprüft und behoben, bevor ein Mensch hinzugezogen wird. Dadurch werden die meisten Routinefehler erkannt, und die Aufmerksamkeit der Teammitglieder kann auf höherer Ebene und weitere Überprüfungen verwendet werden.

Das knappe Ressourcenn: Menschliches Zeit und Aufmerksamkeit

Wir wollen die menschliche Zeit und Aufmerksamkeit für Probleme bewahren, die nur Menschen lösen können, und sicherstellen, dass automatisierte Überprüfungen den Rest erledigen. Bei unserem aktuellen Wandelstempo gibt es immer noch eine unglaubliche Menge Arbeit für Menschen zu erledigen, und unser Team stößt fast täglich auf neue und ungewöhnliche Herausforderungen.

Menschliche Zeit umfasst beide Seiten der Kosten der Überprüfung: die Zeit, die Menschen für die Überprüfung verwenden, und die Zeit, die sie für die Behebung der Fehler im Code aufwenden. Wenn man die erste Zeit wegnimmt, hilft das nicht, wenn die Zeit einfach in der zweiten Zeit auftritt.

Das Ziel ist also, dass die meisten Pull-Requests im Claude Code-Repos (die CLI-, Desktop- und Web-Anwendungen sowie die Mobile-Anwendungen) mit höchstens einer Person im Prozess fusionieren können – diese kann der Autor sein – ohne dass die Anzahl der Rücknahmen oder Vorfälle zunimmt. Um die menschliche Zeit zu messen, verfolgen wir die menschlichen Genehmigungen pro PR (Mittelwert und 95. Perzentil), die menschlichen Kommentare sowie wie lange eine PR auf einer Person warten muss. Die Rate der Rücknahmen und Vorfälle sind das Maß für die menschliche Zeit: Wenn sie steigen, haben wir die menschliche Zeit nicht gesichert, sondern sie nur verschoben.

Das Leben einer Veränderung

Eine typische Änderung, die von einem Laptop eines Ingenieurs (oder einer Claude-Sitzung in Slack) kommt, durchläuft mehrere Schichten von Code-Review.

LAYER FÜR LAYER

1. Die Arbeit wird vor allen anderen überprüft

Die meisten Reviews finden jetzt statt, bevor ein PR existiert. Wir geben Claude etwas, was es ausführen kann – wie Tests, eine Build-Datei oder ein Screenshot, den man mit dem Design vergleichen kann – und bitten ihn, die Ausgabe anzuzeigen, anstatt zu sagen, dass es erledigt ist. Danach überprüft ein Subagent den Diff mit frischem Kontext. Beide Gewohnheiten stammen aus unserem Best-Practice-Leitfaden.

Bevor ein PR eröffnet wird, führen viele von uns auch einige interne Aufgaben durch: einer sucht nach Fehlern, einer vereinfacht den Diff und einer überprüft das Verhalten ausnahmslos. Die UI-Änderungen werden ebenfalls an unseren Designrichtlinien geprüft.

Boris Cherny, der Claude Code entwickelt hat, hat gesagt, dass es wahrscheinlich das Wichtigste ist, Claude eine Möglichkeit zu geben, seine Arbeit zu überprüfen, um gute Ergebnisse zu erzielen. Er schätzt, dass dies das Endresultat zwei bis drei Mal besser macht, und schreibt: „Die Überprüfung unterscheidet sich für jeden Bereich. Es kann so einfach sein, einen Bash-Befehl auszuführen, oder eine Test-Suite zu laufen, oder die App in einem Browser oder einem Telefon-Simulator zu testen.“

Wenn der automatische Überprüfer immer wieder dasselbe Problem anzeigt, korrigieren wir es am Quellcode: durch eine Lint-Regel oder durch Updates an Lehrbüchern, wie z. B.:

• CLAUDE.md gibt Claude an, worum es sich um das Projekt handelt: die Technologiebasis, die Konventionen, die Ziele und die Nichtziele. Jede Überprüfung lädt dieses Dokument herunter, sodass in einem großen Codekodex es kurz bleiben und auf andere Dokumente verwiesen wird. Der Überprüfer weist auch den Code markierend aus, der eine Konvention bricht, sowie die Änderungen, die eine Zeile unaktuell machen.
• REVIEW.md, verfasst von Code-Entwicklern, beschreibt dem Revisor, was in seinem Teil des Codes wichtig ist. Wir prüfen separat, ob der Revisor tatsächlich Folge leistet. Gute Reviews sind kurz. Sie beschreiben, wie ein Fehler im Repo aussieht (für Dokumente: „es lügt“, für Konfigurationen: „es leitet falsch ab“), begrenzen die Probleme, listen Pfade auf, die übersprungen werden sollen, und fordern eine Datei sowie eine Zeile als Beweis anstatt eine Vermutung basierend auf einem Namen. Sie verlangen auch eine Zusammenfassung, die mit einer Zahl beginnt, und sagen klar, wenn es nichts zu beheben gibt.

2. AI-Überprüfung bei jedem Pull-Request

Jeder Pull Request erhält eine Überprüfung durch Claude, bevor eine Person sie betrachtet. Er liest den Diff gegen das gesamte Repo und die angegebene Absicht des PRs und fragt: Löst die Änderung das Problem, passt sie zum System oder schadet sie etwas anderem?

Bei einer Fehlerbehebung wird die Wurzelursache gefunden. Die öffentliche Version Code Review für Claude Code ist jetzt allgemein verfügbar für Team- und Enterprise-Pakete, und /code-review läuft eine leichtere Version lokal.

Als wir die Forschungsvorlage veröffentlichten, stieg der Anteil der internen PRs, die eine substantielle Überprüfung erhielten, von 16% auf 54%. Die meisten PRs mit mehr als 1.000 Zeilen erhalten Ergebnisse, und die meisten kleinen PRs kommen wieder sauber zurück. Die Admins setzen jeden Repo auf Quick, Standard oder Deep. Deep ist es wert, wenn ein vergessener Bug mehr kostet als die zusätzliche Überprüfungszeit.

Die Erkenntnisse werden von anderen Agenten überprüft, bevor sie von Menschen überprüft werden. Mehrere Agenten suchen gleichzeitig nach Fehlern. Dann stimmt eine separate Gruppe jedes Erkennens ab, und es wird nur veröffentlicht, wenn genügend Stimmen dafür sind, dass es real ist. Erkenntnisse, die nur um Stil, Diagnosen oder Aufräumungen gehen, werden ignoriert. Wir haben diese Filter in unseren eigenen PRs A/B getestet, bevor wir sie veröffentlichen. Was übrig bleibt, erscheint als Inline-Kommentare, sortiert nach Schweregrad. Jeder Kommentar ist mit „Wichtig“, „Nit“ oder „Vorhanden“ gekennzeichnet, sodass ein Fehler, den die PR nicht verursacht hat, nicht als Schuld des Autors erscheint.

Jede Feststellung muss beantwortet werden. Entweder wird das Problem behoben oder die Angelegenheit mit einer Erklärung gelöst. Oft übernimmt ein Agent die Behebung des Problems über Nacht, sodass der Autor auf eine PR zurückkommt, die bereits eine weitere Runde durchlaufen hat.

3. Sicherheitsüberprüfung, die Blockieren kann

Die Sicherheit erhält ebenfalls eine automatisierte Überprüfung. Ein PR kann nicht zusammengeführt werden, solange einige Erkenntnisse aus der Fehlerüberprüfung oder der Sicherheitsüberprüfung noch offen sind. Man muss entweder das Problem beheben oder den Thread mit einer kurzen Begründung schließen – so wird ein falscher Positivbeweis beseitigt.

Wenn eine spätere Commit-Datei das Problem behebt, wird die Erkenntnis von selbst gelöscht. Sie können dasselbe mit der open-source Sicherheitsüberprüfungs-GitHub-Action oder dem /security-review-Befehl einrichten. Die Einrichtung ist in automatisierte Sicherheitsüberprüfungen in Claude Code beschrieben.

4. Automatisierte Prüfungen, die blockieren

Die üblichen Aufgaben: Linting, Typüberprüfungen, Tests auf allen Plattformen und eine Build-Prozess. (Wir haben bereits über die Skalierung von CI für dieses Thema geschrieben hier.) Ein typischer CLI-Pull-Request durchläuft vor dem Betrachten von vielen Checks. Das PR-Template fragt nach der Art und Weise, wie der Änderungsvorschlag getestet wurde, sowie nach der Art und Weise, wie er rückgängig gemacht werden kann. Claude kann diese Informationen ergänzen, aber die Person, die den Vorschlag eingereicht hat, muss das Dokument unterzeichnen.

5. Menschliche Genehmigung, angepasst an das Risiko

Eine Dokumentäufe-Reparatur und eine Auto-Updateer-Änderung haben unterschiedliche Risiken, daher erhalten sie unterschiedliche Überprüfungen.

Der Wandel bestimmt die Kategorie, nicht den Autor. Ein Klassifizierer liest den Wandel und wählt seine Risikokategorie aus. Ein zweiter Klassifizierer fragt, ob diese spezielle Änderung noch eine weitere Person benötigt, auch wenn die Kategorie dies nicht vorsieht. Einige Pfade benötigen immer eine Person – alles, was die Eigentümer als sensibel eingestuft haben, sowie alle CI-Werkzeugwerkzeuge.

Nur vertrauenswürdige Autoren erhalten die leichteren Pfade. Nur Autoren, die auf der vertrauenswürdigen Liste des Repos stehen, erhalten die leichteren Pfade – meist die Personen, die das Projekt betreuen. Alle anderen benötigen die Zustimmung einer zweiten Person. Auch die Zustimmung eines Agenten zählt nicht als Zustimmung einer Person. Die automatische Überprüfung kann eine risikoarme Änderung freigeben, aber sie kann keinen Platz füllen, der eine menschliche Zustimmung erfordert.

Jeder, der den Wandel auslöst, ist dafür verantwortlich. Bei einer von einem Agent erstellten PR gilt die Person, die den Agent leitet, als einer der erforderlichen Überprüfer – genauso wie wenn sie das Code selbst geschrieben hätte.

Eine Genehmigung gilt für einen bestimmten Commit. Wenn neue Commits hinzukommen, für die das System keine Garantie bietet – wie zum Beispiel ein Push des Agents oder eine manuell gelöste Fusion – muss die Genehmigung erneut erteilt werden.

6. Verschmelzen der Warteschlange, Flaggen und eine schrittweise Freigabe

Die Merge-Queue wiederholt jede Überprüfung gegen das Hauptmodul mit der angewandten Änderung, sodass zwei PRs, die separat erfolgreich sind, nicht zu einem kaputten Hauptmodul zusammengeführt werden können. Das neue Verhalten wird normalerweise erst hinter einer Flagge für die Mitarbeiter von Anthropic veröffentlicht, und unsere intensive Nutzung zeigt oft Regressionsen vor den Benutzern. Die öffentlichen Veröffentlichungen gehen zuerst in den latest-Kanal. Der stable-Kanal folgt danach.

7. Schnelle Erkennung, schnelles Rückrollen

Einige Fehler werden trotzdem durchkommen, daher geht es in der letzten Schicht darum, sie schnell zu erkennen. Flaggen schalten sich ohne Deployment aus. Claude Code hat eine wöchentliche Einsatzrotation, und bei Incident-Reviews wird geklärt, welche Schicht das Problem hätte erkennen sollen.

Es hängt noch davon ab, wie der Autor und der zuständige Mitarbeiter reagieren sowie von den Revert- und Incident-Panelen. Wir haben noch keine Schutzmechanismen, die die Genehmigung verstärken, wenn diese Zahlen sich ändern; die Ingenieure hier wünschen sie, bevor weitere Code-Änderungen zu den „Zero-Human-Merges“ führen.

Einer meiner Kollegen sagte, dass das Verlangsamen die Fehlerquote verringert, aber hauptsächlich deshalb, weil man nicht mehr alles tut. Wir würden lieber schneller auf Probleme erkennen und beheben können.

WIE WIR DEN REVIEWER BESSER MACHEN

Unser Code-Review-Prozess verbessert sich ständig im Kreislauf.

Jeder Vorfall ist jetzt eine Bewertung. Das Team sammelte vergangene PRs, die Vorfälle verursachten, zusammen mit ihren Fix-Forwarden und Reverten, und hatte Ingenieure, die den Code kennen und bestätigen, wo sich jeder Bug befindet. Der Überprüfer führt täglich gegen dieses Set von Daten aus.

Wir messen den Lärm, indem wir beobachten, was die Leute mit den Kommentaren machen. Es ist einfach, mehr Fehler zu entdecken, wenn man es darf, viele nicht-Fehler anzuzeigen. Deshalb brauchen wir eine Überprüfung dazu. Wir sortieren jeden Kommentar, den der Revisor hinterlässt, nach der Reaktion der Person im PR: Sie hat etwas korrigiert, sagte, es sei falsch, sagte, das Verhalten sei beabsichtigt oder entschied, dass es nicht wichtig sei. Wir setzen den Revisor auch auf PRs, die wir für sauber halten, und zählen, wie oft er etwas berichtet, das dazu führen könnte, dass jemand eine schädliche Änderung vornehmen würde. Unsere Priorität, festgelegt, ist es, erstmal echte Fehler zu finden und danach die Überprüfungen abzubauen.

Die Kosten für Lärm sind höher, wenn der Autor ein Agent ist. Eine Person kann einen Fehler in Sekunden erledigen. Ein Agent behebt ihn, was bedeutet, dass weitere Commits und eine weitere Überprüfung notwendig sind.

Die Überprüfung muss sich konvergieren lassen. Ein Autor des Agenten und ein Revisor des Agenten können sich gegenseitig unendlich lange beschäftigen. Ein CLI-PR durchlief mehr als fünfzig Runden von Überprüfungen und Korrekturen in einer Nacht, bevor der Autor ihn stoppte.

Als wir mit git blame auf das herumforschten, worauf der Revisor immer wieder hingewiesen hatte, war etwa 59% davon Code, der seit der ersten Überprüfung des Revisors bereits vorhanden war. Der Revisor fand selten neue Fehler, sondern nur einige alte Fehler in jeder Runde.

Wir haben es selbst noch schlimmer gemacht. Wir waren daran gewöhnt, standardmäßig mehrere Runden zu laufen, da jede Runde etwas Neues bietet. Das kann bei einer riskanten Änderung sinnvoll sein, aber nicht für jeden PR. Das Team verfolgt jetzt sowohl die Anzahl der Runden als auch die Wiederholungen, und die Wiederprüfung wurde geändert:

• Ein Kreiskappe. Nach drei Runden fordert der Rezensent den Autor auf, zurückzutreten und die Vorgehensweise neu zu überdenken.
• Re-Prüfung nur von Diff-Änderungen nach den ersten paar Durchgängen.
• Markieren Sie die Klasse des Bugs, damit der Autor alle Instanzen korrigiert, nicht nur eine Zeile.
• Keine Wiederholungen der bereits veröffentlichten Erkenntnisse.

Überprüfungsagenten durchlaufen außerdem jede Nacht den bestehenden Code, um uns dabei zu helfen, alte Fehler vor dem Auftreten an anderer Stelle zu erkennen.

WO MENSCHEN IN DER KETTENLEINE BLEiben

Das Abhalten eines Senior-Engineers von der tiefen Arbeit, um einen Routinefehler zu entdecken, kostet viel mehr als eine automatisierte Überprüfung. Bei Anthropic haben unsere Aufgaben von der Lektüre jedes Diffs auf die Entscheidungen übergegangen, bei denen die Maschinen schlecht sind:

• Sollten wir das überhaupt bauen? Ausrichtung, Geschmack und Umfang. Eine Teamgruppe, die den Engpass bei der Überprüfung angegeben hatte, behielt weiterhin die menschliche Überprüfung für Änderungen von außerhalb des Teams bei, sodass jemand fragt: „Sollten wir das überhaupt tun?“
• Riskante Code-Teile, wie der Berechnungsprozess, der Auto-Updateer und die CI-Werkzeuge.
• Architektur, die ein Muster setzt, das andere nachahmen werden.
• Die Beweise lesen. Die Testausgabe, der Befehl, der ausgeführt wurde und was er zurückließ, ein Screenshot, die Erkenntnisse des Revisors. Wenn Sie nicht sagen können, was die Tests übersehen würden, fragen Sie nach einer echten Überprüfung anstatt nach einer schnellen Genehmigung.
• Die Verantwortung für das Ergebnis. Eine Person ist für jeden Wechsel verantwortlich, der umgesetzt wird – egal wer ihn eingetippt hat.

Teilen des Kontexts innerhalb der Teammitglieder

Die zweite Aufgabe der Code-Review ist immer gewesen, das Verständnis des Codebases zu verbreiten. Das Lesen des Diff-Dokuments eines Teammitglieds zeigt, was sich geändert hat und wie die Teile zusammenpassen. Wenn Maschinen den größten Teil des Lesens übernimmt, wie lernt dann jemand den Code?

Wir haben keine formale Prozessweise dafür. Niemand im Team hat eine vollständige mentale Vorstellung von Claude Code im Kopf, und wir glauben auch nicht, dass das notwendig ist. Wenn jemand einen Teil des Codebodens verstehen möchte, bittet er Claude, eine Erklärung für genau diesen Teil zu schreiben. Das dauert nur wenige Minuten und berücksichtigt den Code so, wie er heute ist.

Einige von uns gehen noch einen Schritt weiter und lassen Claude ein kleines Artefakt erstellen, das diesen Teil des Codes visualisiert, sowie eine Methode anbietet, wie die jeweilige Person lernt.

Wenn das Ziel ist, die menschliche Aufmerksamkeit richtig zu nutzen, ist das besser als das Lesen trivialer Diff-Dateien Zeile für Zeile. Eine einzeilige Kopieränderung lehrt einen fast nichts. Eine Erklärung für das Modul, das man ändern will, lehrt einen viel. Unsere Kultur, sich auf offene Slack-Kanäle zu stürzen, hilft ebenfalls, denn man sieht, was andere entwickeln, während sie es erstellen.

„Du besitzt es, du gehört es.“

Wenn Sie eine kleine oder mittlere Störung erleben und es immer noch nicht funktioniert, ist es eine typische Teamregel, dass man das meist behandelt. Einige Dinge verhindern, dass die Situation schlimm wird:

• Die Änderungen sind klein, sodass sie leicht überprüft, debuggt und zurückgesetzt werden können.
• Alles ist umkehrbar. Flaggen, Rückkehr und gestellte Veröffentlichungen rückgängig machen die meisten Fehler in wenigen Minuten.
• Der Explosionsradius bestimmt die Grenze. Kostspielige Code-Implementierungen erhalten mehr Nutzer und mehr Überprüfungen.
• Regressionen treten schnell auf durch Telemetrie und interne Nutzung.
• Es ist keine Schuld. Die Verantwortung für eine Lösung bedeutet, dass man den größten Kontext hat; Unfallüberprüfungen betrachten das System.

Die Eigentumsverhältnisse werden ebenfalls geteilt. Ein Großteil des Teams arbeitet in offenen Kanälen, in denen jeder sehen kann, was andere entwickeln, einen Thread ergreifen oder einen Claude auf ein Problem hinweisen kann. Die Rückmeldungen kommen auch von Personen, die nicht das Code-Entwicklungsrecht besitzen. Diese Offenheit ist ein wichtiger Faktor dafür, dass die Qualität hoch bleibt, ohne dass jede Zeile gesperrt werden muss.

WENN WIR DIE RICHTUNG ÄNDERN

Die Agenten machen es günstig, etwas zu beginnen, sodass einige Arbeiten nicht realisiert werden. Normalerweise fragt jemand im Kanal, warum, weist auf eine frühere Entscheidung hin oder schlägt einen einfachereren Weg vor, und der Autor schließt oder verändert die PR.

Da der Code leicht zu schreiben war, fühlt es sich nicht wie ein Verlust an, den PR zu schließen. Der Trick besteht darin, frühzeitig eine andere Richtung in der Thread zu erwähnen, und nicht als blockierendes Kommentar auf einem abgeschlossenen PR.

WIE Sie diesen Prozess übernehmen können

Die meisten Tools, die für diese Aufgabe mit Ihrem Team benötigt werden, gibt es heute bereits.

Vor dem Pull-Request

• Gebe Ihrem Agenten die Checks an, die ausgeführt werden können, aufgelistet in einem kurzen CLAUDE.md, sowie Hooks für Formatierungs- und Linter-Tools.
• Führen Sie /code-review und /security-review lokally aus, oder eine Überprüfung durch den subagenten „fresh-context“.
• Füge ein REVIEW.md hinzu und verschiebe die wiederholten Überprüfungskommentare dorthin.

In jeder Pull-Request

• Erfordert CI, und fügen „Testing“, „Risk“ und „Wie man zurückkehrt“ in das PR-Template hinzu.
• Fügen Sie einen AI-Überprüfungserwerfer (Code Review für Claude Code oder die Claude Code GitHub Action) zu einem Repo hinzu, passen Sie REVIEW.md einige Wochen lang an und erweitern Sie ihn anschließend.
• Fügen Sie eine automatische Sicherheitsüberprüfung hinzu und verlangen Sie, dass jeder Überprüfungsthread gelöst ist, bevor die Verschmelzung stattfindet.
• Passt die Anstrengung des Code-Review mit dem Risiko überein: Schnelle Überprüfungen für Routineänderungen, tiefgehende Überprüfungen, bei denen ein verpasster Bug teuer ist (Schnell, Standard oder Tief in Code Review).
• Runde der Cap-Überprüfungen; nach den ersten paar Runden wird nur der neue Diff verglichen.

Anerkennung

• Schreiben Sie die Risikotypen auf, basierend auf den Veränderungen, nicht auf dem Autor; beginnen Sie streng und lockern Sie nachweislich ab.
• Behalten Sie die leichtere Genehmigungswege für Autoren, denen Sie vertrauen.
• Verwenden Sie CODEOWNERS und Branch-Protection, damit die Workflows für Authentifizierung, Abrechnung, CI und Veröffentlichung sowie die Installer immer eine Person erfordern.
• Lassen Sie niemals die Genehmigung eines Bots die Genehmigung eines menschlichen Personals ersetzen; ignorieren Sie Genehmigungen für neue Commits.

Zusammenführen und danach

• Verwenden Sie eine Merge-Kette, Feature-Flaggen, erstmal interne Verwendung, gestufte Veröffentlichungen und einen Schritt-Rückfahren.
• Überführen Sie die Vorfälle und Rückkehrungen in eine Evaluationsdatei und bewerten Sie den Überprüfer erneut, sobald seine Anweisungen, Werkzeuge oder Modell verändert werden.
• Messen den menschlichen Zeitaufwand, mit Rückkehr- und Vorfallraten als Schutzmaßnahme.

WOHIN dies führt

Code Review’s Ankündigung besagt, dass die Genehmigung eines Pull-Requests immer noch eine menschliche Entscheidung ist; das Produkt publiziert Erkenntnisse, nicht Genehmigungen. Unsere eigenen Repos gehen noch weiter und ermöglichen den Besitzern, selbst zu entscheiden, welche geringrisikenhaften Änderungen allein durch automatische Überprüfungen integriert werden – und diese Linie entwickelt sich ständig weiter.

Wenn eine Überprüfung etwas verpasst, fragen wir, was das Modell nicht vor sich hatte, und fügen die Lösung in einen CLAUDE.md ein – eine Fähigkeit oder eine neue Prüfung. Das Ziel hat sich nicht geändert: weniger menschliches Zeitaufwand pro Änderung und keine mehr als zuvor Rücknahmen.

Wenn Ihr Team es zulässt, dass Agenten Pull-Requests öffnen, möchten wir wissen, welche Überprüfungen Sie automatisiert haben, welche noch von einer Person erledigt werden müssen und was Sie für Fehler in unserer Arbeit halten.

Mit Dank an Emma Webb, Michael Segner und Amie Rotherham für ihre Rezensionen.