Claude Code Review: Was es erkennt und was es übersieht

Kann Claude Code Code zuverlässig überprüfen? Ja, das kann es, und es ist wirklich gut in einem bestimmten Teil dieser Aufgabe. Anthropic bietet Claude Code Review in zwei Formen an: eine verwaltete GitHub App, die Pull Requests in der Cloud überprüft, und einen /code-review-Befehl, den Sie lokal in jeder Claude Code Sitzung ausführen können. Beide setzen mehrere Agenten gleichzeitig ein, die jeweils nach einer anderen Klasse von Fehlern suchen, und führen anschließend einen Verifizierungsschritt aus, der versucht, jeden Befund zu widerlegen, bevor er Sie erreicht. Was keines von beiden tut: Ihren Code ausführen, nach durchgesickerten Geheimnissen suchen oder Ihnen sagen, dass die Funktion, die Sie gebaut haben, das falsche Problem löst.

Wir entwickeln Claude Code Automatisierung kommerziell für Kunden. Als Claude Code Review erschien, haben wir also das Naheliegende getan: Wir haben es auf unsere eigenen Repositories angesetzt und Notizen gemacht. Die eigentliche Frage war nicht, ob die Reviews gut sind. Sie ist, welche Reviews Sie jetzt abgeben können und welche noch nicht. Im Folgenden erfahren Sie, was es erkennt, was es übersieht, was der Betrieb kostet und an welchem Punkt ein menschlicher Reviewer wieder eingreifen muss.

Was ist Claude Code Review?

Claude Code Review ist ein automatisierter Pull-Request-Reviewer, der auf mehreren spezialisierten Agenten basiert. Wenn eine Review startet, untersuchen mehrere Agenten gleichzeitig den geänderten Code und die umgebende Codebasis, wobei jedem eine andere Fehlerkategorie zugewiesen ist. Ein Verifizierungsschritt prüft dann jeden Kandidatenbefund anhand des tatsächlichen Verhaltens des Codes und verwirft die, die er nicht belegen kann.

Die Agenten suchen nach:

• Logikfehlern
• Sicherheitslücken
• Defekten Grenzfällen
• Subtilen Regressionen

Der Verifizierungsschritt macht die Ergebnisse erst lesenswert. Ohne ihn tendiert eine KI-Review dazu, Sie mit Kommentaren zu überschütten, die plausibel klingen, sich aber als falsch herausstellen, und das Aussortieren kostet mehr Zeit, als es spart.

Die berichteten Ergebnisse untermauern dieses Design. Nach der internen Einführung gibt Anthropic an, dass der Anteil der Pull Requests mit inhaltlichen Kommentaren von 16% auf 54% gestiegen ist, wobei weniger als 1% der Befunde von den eigenen Entwicklern als falsch markiert wurden. Bei Pull Requests mit 1,000 Zeilen oder mehr berichtet Anthropic, dass 84% Befunde erhalten, im Schnitt 7.5 Probleme pro Pull Request. Das sind Herstellerzahlen, gemessen an einer Herstellercodebasis, weshalb die genauen Werte mit angemessener Vorsicht zu behandeln sind, auch wenn sich das Muster in der Praxis bestätigt.

Zwei Möglichkeiten, Claude Code Review auszuführen

Die erste Option ist ein gehosteter Dienst, den Anthropic für Sie betreibt, sodass Sie in Ihrer Pipeline nichts installieren müssen. Ein Admin des Claude-Kontos Ihres Unternehmens, jemand mit Zugriff auf Abrechnung und Einstellungen, verbindet die Claude GitHub App und legt fest, welche Repositories sie überprüfen darf. Von da an laufen Reviews automatisch, wenn ein Pull Request geöffnet wird, bei jedem Push, oder nur wenn ein Entwickler eine anfordert, je nachdem, wie das jeweilige Repository eingestellt ist. Befunde erscheinen als Kommentare an den konkreten Codezeilen, auf die sie sich beziehen, jeweils mit einem Schweregrad versehen, und sie hindern Sie nie am Mergen.

Die zweite Option ist der lokale /code-review-Befehl, der auf jedem Plan funktioniert und überhaupt keine Admin-Einrichtung benötigt. Er überprüft Ihren aktuellen Branch plus alle nicht committeten Änderungen, läuft im Hintergrund, sodass er nicht stört, was Sie gerade tun, und kann auf Wunsch eigene Korrekturen an Ihrer Arbeitskopie vornehmen. Entwickler nutzen ihn vor dem Push, was weit günstiger ist, als denselben Fehler 20 Minuten nach dem Öffnen eines Pull Requests zu finden.

Sie können beide Versionen steuern, indem Sie zwei Dateien in Ihrem Repository pflegen: CLAUDE.md, die den allgemeinen Projektkontext enthält, und REVIEW.md, die reine Review-Regeln enthält und mehr Gewicht hat. Für alles andere in Ihrer Claude-Toolchain behandelt unsere Übersicht der besten Claude Code Plugins, was gut dazu passt.

Warum der Zugriff auf die Codebasis wichtiger ist als die Modellwahl

Teams, die KI-Reviews bewerten, konzentrieren sich meist darauf, welches Modell dahintersteckt. Das ist die weniger interessante Variable. Was eine nützliche Review tatsächlich von einer lauten unterscheidet, ist, wie viel der überprüfende Agent sehen kann: Ihr gesamtes Repository oder nur die geänderten Zeilen, und ob er die Konventionen Ihres Teams kennt oder aus Funktionsnamen rät.

Ein Agent, der einen Diff isoliert liest, kann Ihnen sagen, dass der Code intern konsistent ist. Ein Agent, der den Diff plus die zwölf Dateien liest, die ihn aufrufen, kann Ihnen sagen, dass die Änderung etwas zwei Verzeichnisse weiter entfernt zerbricht. Das ist der Unterschied, den Käufer testen sollten, und es ist eine Frage von Kontext und Konfiguration, nicht von Modell-Benchmarks.

Was Claude Code Review erkennt

Die stärksten Ergebnisse konzentrieren sich an einer Stelle: Fehler, für deren Erkennung mehr von der Codebasis gelesen werden muss, als ein menschlicher Reviewer normalerweise öffnet. Menschliche Reviewer schauen sich den Diff an, weil es zu langsam wäre, alles zu öffnen, was der Diff berührt. Ein Agent hat diese Einschränkung nicht.

Vertragsabweichungen zwischen Dateien. Eine Änderung an einer Datenstruktur, die still und heimlich eine Annahme in einem Verbraucher mehrere Verzeichnisse weiter entfernt bricht. Das ist die wertvollste Kategorie, weil es genau der Fehler ist, den eine diff-fokussierte menschliche Review strukturell übersieht.

Fehlende await– und Fire-and-Forget-Async-Aufrufe. Keine neuartige Fehlerklasse, aber konsistent erkannt, auch innerhalb von Fehlerbehandlungsblöcken, in denen eine verschluckte Ausnahme bedeutet, dass der Fehler nie in den Logs auftaucht.

Regeln, die Sie tatsächlich festgehalten haben. Geben Sie ihm eine Regel wie „jede Datenbankabfrage muss auf den aufrufenden Mandanten beschränkt sein“, und es setzt diese Regel bei jedem Pull Request durch. Statische Analysetools kennen Ihr Mandantenmodell nicht. Ein Review-Agent kennt es, sobald Sie es ihm mitteilen. Das ist die eine Maßnahme mit dem höchsten Hebel, die die meisten Teams auslassen.

Grenz- und Off-by-One-Fehler. Paginierungsgrenzen, Array-Grenzen, inklusive versus exklusive Bereiche, meist gemeldet mit der konkreten Eingabe, die das Problem reproduziert.

Dokumentation, die nicht mehr zum Code passt. Das funktioniert in beide Richtungen. Wenn ein Pull Request eine dokumentierte Aussage veraltet macht, markiert es die Dokumentation als aktualisierungsbedürftig, statt nur den Code zu überprüfen.

Fehler, die schon vorher da waren. Probleme im Code in der Nähe der Änderung werden als bereits vorher vorhanden gekennzeichnet, statt dem Autor zugeschrieben zu werden, was die richtige Einordnung und für die Priorisierung von technischen Schulden wirklich nützlich ist.

Die umfassendere Forschung erklärt, warum das jetzt wichtig ist. Der DORA-Report 2025 von Google fand heraus, dass die KI-Einführung sowohl den Durchsatz der Softwarebereitstellung als auch deren Instabilität erhöht, weil die Systeme zur Codeverifizierung nicht mit dem Tempo mitgehalten haben, in dem heute Code geschrieben wird. Ein Agent, der Ihre gesamte Codebasis liest, ist eines der wenigen verfügbaren Gegengewichte zur Instabilitätshälfte dieses Kompromisses.

Was Claude Code Review übersieht

Die Lücken sind struktureller Natur und keine Frage der Reifung des Tools, was sie zum entscheidenden Faktor dafür macht, wie viel menschliche Review Sie sicher entfernen können. Jeder Befund entsteht durch Nachdenken über den Code, nicht durch dessen Ausführung. Diese eine Tatsache bestimmt das Meiste, was folgt.

Alles, was die Ausführung des Codes erfordert. Performance-Einbrüche, die erst bei Produktionsdatenvolumen auftreten. Abfragemuster, die sich erst unter einer echten Datenbanksitzung vervielfachen. Race Conditions, die echte Nebenläufigkeit brauchen, um sichtbar zu werden. Speicherverhalten unter anhaltender Last. Nichts davon ist für einen Reviewer sichtbar, der liest, statt auszuführen.

Secrets, statisches Sicherheitstesten von Anwendungen und Infrastructure-as-Code-Scanning. Wenn eine hartcodierte Anmeldeinformation oder eine übermäßig freigebige Cloud-Richtlinie in einem Diff landet, gehen Sie nicht davon aus, dass dies erkannt wird. Behalten Sie die Scanner, die Sie bereits einsetzen.

Korrektheit von Geschäftsregeln. Es wird bestätigen, dass eine Rabattberechnung intern konsistent und rechnerisch korrekt ist. Es hat keine Möglichkeit zu wissen, dass die Finanzabteilung die Regel im letzten Quartal geändert hat. Code, der gleichzeitig korrekt und falsch ist, bleibt ein menschliches Problem.

Architektonisches Urteilsvermögen. Es wird Ihnen nicht sagen, dass der dritte Microservice, den Sie diesen Monat hinzugefügt haben, eigentlich ein Modul hätte sein sollen, oder dass ein Muster heute funktioniert, aber die nächsten zwei Features nicht überleben wird. Designfragen brauchen ebenfalls Hin und Her, und jede Review-Runde dauert etwa 20 Minuten, sodass es unpraktisch ist, eine architektonische Entscheidung auf diesem Weg durchzuarbeiten, selbst wenn der Reviewer etwas Nützliches zu sagen hat.

Testqualität. Der Standardfokus liegt auf Korrektheitsfehlern, nicht auf Abdeckungslücken. Ein Pull Request mit drei Tests, die alle nur den Happy Path prüfen, besteht die Review problemlos, sofern nicht ausdrücklich mehr verlangt wurde.

Es gibt außerdem eine Grenze, die es wert ist, als Feature gelesen zu werden. Es genehmigt keine Pull Requests, und sein Status-Check blockiert nie einen Merge, sodass die Entscheidung bei einem Menschen bleibt. Das ist Absicht und entspricht dem, wie sehr Entwickler dieser Art von Ergebnis derzeit vertrauen: Die Stack-Overflow-Umfrage 2025 fand heraus, dass die größte KI-Frustration, genannt von 66% der Entwickler, eine Ausgabe ist, die fast richtig, aber nicht ganz richtig ist. Ein KI-Reviewer erbt genau dieses Merkmal. Er leistet auf der mechanischen Ebene gute Arbeit und schweigt zur Absicht. Wie sich das bei Tools allgemein auswirkt, zeigt unser Beitrag zu KI-gestützten Code-Reviews.

Wie viel sollten Sie ausführen, und wie oft?

Die Kosten skalieren mit der Häufigkeit, mit der Reviews ausgelöst werden, und die Trigger-Einstellung ist wichtiger als der Preis pro Review. Gartner prognostiziert, dass 75% der Enterprise-Softwareentwickler bis 2028 KI-Codeassistenten nutzen werden, gegenüber unter 14% Anfang 2024, sodass die Review-Kapazität die Beschränkung ist, die zuerst zerbricht, wenn Codegenerierung billiger wird. Wahllos dafür zu bezahlen, bleibt trotzdem ein Fehler.

Das Setup, das sich in der Praxis bewährt, ist einfach. Führen Sie für die meisten Repositories einmal eine Review durch, wenn ein Pull Request geöffnet wird, weil das die Mehrheit der Probleme für eine einzige Abrechnung erfasst. Wechseln Sie für Ihre am stärksten frequentierten Repositories auf „nur auf Anfrage“, wo eine Review bei jedem Push die Rechnung vervielfachen würde, ohne viel zusätzlichen Nutzen zu bringen. Und lassen Sie Entwickler den lokalen Befehl vor dem Push ausführen, da das nichts zusätzlich kostet und Probleme erkennt, bevor überhaupt eine kostenpflichtige Review beginnt.

Legen Sie ein monatliches Ausgabenlimit fest, bevor Sie dies breit ausrollen, prüfen Sie dann nach der ersten Woche die durchschnittlichen Kosten pro Repository und passen Sie von dort aus an. Wenn Sie die Review-Praxis über Zeitzonen hinweg vereinheitlichen, ist unser Vergleich der Code-Review-Tools für verteilte Teams eine nützliche Ergänzung.

Wann Sie noch eine unabhängige Code-Review benötigen

Manche Fragen liegen außerhalb dessen, was ein automatisierter Reviewer beantworten soll, und das sind meist die teuren. Sie haben eine gemeinsame Form: Der entscheidende Befund ist ein Muster über die gesamte Codebasis hinweg, kein Defekt innerhalb einer einzelnen Änderung.

Technische Due Diligence vor einer Übernahme ist der klarste Fall, bei dem die Frage lautet, ob der Vermögenswert wartbar ist, und nicht, ob Zeile 142 einen Fehler hat. Sicherheits- und Compliance-Audits benötigen ausführbaren Beweis statt Schlussfolgerung. Eine Codebasis von einem früheren Anbieter zu übernehmen, erfordert jemanden, der ein Muster über 40 Dateien hinweg nachverfolgt, was keine Pull-Request-Review jemals zu sehen bekommt. Und jedes Repository, in dem die KI den Großteil des Codes geschrieben hat und niemand seither gefragt hat, ob er zusammenhält, ist ein Fall für Vibe-Code-Cleanup statt für einen weiteren automatisierten Durchgang.

Hier die ehrliche Zusammenfassung. Claude Code Review markiert die subtilen Fehler und Versehen, die einem erschöpften Code-Reviewer, der sich beeilt fertig zu werden, leicht durchgehen. Es findet nicht die Probleme, die ein Reviewer entdeckt, weil er sich erinnert, warum dieses Modul 2019 so geschrieben wurde, wie es geschrieben wurde.

Warum Teams Redwerk hinzuziehen

Wir bauen seit mehr als zwei Jahrzehnten maßgeschneiderte Software für Unternehmen in Nordamerika und Europa, darunter Siemens, J.B. Hunt und Universal Music Group. Die technischen Grundlagen und Sicherheitspraktiken hinter einer guten Review sind nichts, was wir uns durch eine Produktveröffentlichung angeeignet haben. Es ist das, was wir bereits getan haben.

Daraus ergeben sich drei Arten von Unterstützung. Wir konfigurieren Claude Code richtig als Review-Agenten, mit einem auf Ihre Codebasis abgestimmten Schweregrad, eingerichteten Ausgabenkontrollen und pro Repository angepassten Triggern statt überall eingeschaltet. Wir bauen die breitere Claude Code Automatisierung darum herum auf, denn Review ist ein Workflow, und die meisten Teams haben mehrere weitere, die sich zu automatisieren lohnen. Und wenn die richtige Antwort ist, dass eine Person Ihren Code sorgfältig liest, liefern unsere Code-Review-Dienstleistungen das mit einem schriftlichen Bericht, den Sie einem Vorstand oder einem Käufer vorlegen können.

Möchten Sie wissen, was ein automatisierter Reviewer in Ihrer Codebasis erkennen würde und was nicht? Nehmen Sie Kontakt mit unserem Team auf, und wir gehen es gemeinsam mit Ihnen durch.

FAQ

Sehen Sie sich an, wie wir die Project Science-Software von Complete Network geprüft und eine 80-prozentige Steigerung der Wartbarkeit des Codes erreicht haben

Bitte geben Sie Ihre Geschäfts-E-Mail-Adresse ein ist keine Geschäfts-E-Mail

Fallstudie herunterladen