KI-Code-Review in der Praxis: Was Copilot, Cursor und Claude übersehen und Menschen finden
Die meisten Entwicklungsteams setzen inzwischen irgendeine Form von KI-Code-Review ein. Copilot kommentiert Pull Requests, Cursor markiert Probleme schon beim Tippen, und Claude liest einen kompletten Diff und liefert ein Review, das aussieht, als hätte es ein Senior Engineer geschrieben. Das Ergebnis wirkt überzeugend. Ob es vollständig ist, ist eine andere Frage. Nach etlichen Audits KI-unterstützter Codebasen für unsere Kunden haben wir ein ziemlich klares Bild davon, welche Grenzen von KI-Code-Reviews in der Praxis wirklich zählen. Die Tools sind in manchen Kategorien zuverlässig und in anderen konsequent blind, und die Trennlinie zwischen beiden ist vorhersehbarer, als die meisten Teams annehmen.
Dieser Beitrag zeigt beide Seiten: was du heute gefahrlos an einen maschinellen Reviewer delegieren kannst und wo du weiterhin einen Menschen brauchst, der deine Domäne versteht.
Was KI-Reviewer zuverlässig finden
Zuerst die gute Nachricht. Für eine ganze Klasse von Problemen ist KI-Review schneller als jeder Mensch und selten falsch.
Gängige Sicherheitsmuster sind der klarste Gewinn. String-Konkatenation in einer SQL-Query wird jedes Mal markiert, in jedem Tool, das wir getestet haben. Dasselbe gilt für nicht escapte Ausgaben, die ein XSS-Loch öffnen, und für einen Endpoint ohne Authentifizierungsprüfung, während jeder benachbarte Endpoint eine hat. Das sind Muster mit Tausenden gelabelten Beispielen dahinter, und Mustererkennung ist genau das, was diese Modelle gut können.
Offensichtliche Performance-Probleme folgen direkt danach. Eine N+1-Query in einer Schleife wird fast immer erkannt, besonders in ORM-lastigem Code, wo die Form visuell markant ist. Bitte Claude, eine Doctrine-Repository-Klasse zu reviewen, und es zeigt oft auf den fehlenden Join, bevor ein menschlicher Reviewer die Datei zu Ende gelesen hat. Ein Filter auf einer Spalte ohne Index wird ebenfalls markiert, sofern das Schema im Diff oder im umgebenden Kontext sichtbar ist.
Dann ist da die unglamouröse Schicht: Benennungen, die von den Konventionen im Rest der Datei abweichen, eine Methode, die in einem Zweig null zurückgibt und in einem anderen eine Exception wirft, eine Dereferenzierung ohne Null-Check zwei Zeilen nach einer nullable Zuweisung. Nichts davon ist aufregend. Alles davon hat früher menschliche Review-Zeit gefressen, und das muss es nicht mehr.
Wenn deine Pull Requests vom menschlichen Reviewer voller Kommentare zu Formatierung und fehlenden Null-Checks zurückkommen, hebt ein erster KI-Durchgang das Niveau der Diskussion. Dieser Teil des Versprechens ist real.
Die Grenzen von KI-Code-Reviews, die uns am häufigsten begegnen
Die Lücken sind genauso konsistent wie die Treffer. Fünf Kategorien tauchen in fast jedem unserer Audits auf.
Fehler in der Geschäftslogik stehen ganz oben auf der Liste. Stell dir ein Billing-Modul vor, in dem der Erstattungspfad die anteilige Verrechnung auf Basis des aktuellen Planpreises neu berechnet statt auf Basis des Preises, den der Kunde tatsächlich bezahlt hat. Jede Zeile ist sauber. Die Typen stimmen, die Tests laufen durch, das KI-Review lobt das Error Handling. Der Bug wird erst sichtbar, wenn man weiß, dass das Unternehmen Bestandskunden zu alten Preisen führt, und das kann kein Modell aus dem Diff ableiten. Domänenwissen steht nicht in den Trainingsdaten und auch nicht im Kontextfenster.
Race Conditions sind der zweite verlässliche blinde Fleck. Zwei Request-Handler lesen jeweils eine Zeile, prüfen eine Bedingung und schreiben zurück. Datei für Datei reviewt sind beide korrekt. Lass sie parallel auf derselben Zeile laufen, und du bekommst doppelt ausgezahlte Guthaben oder eine doppelte Rechnung. Der Defekt lebt in keiner einzelnen Zeile, also hat ein Reviewer, der lokal über einen Diff nachdenkt, nichts, woran er sich festhalten kann. In unseren Audits KI-unterstützter Codebasen gehören ungeschützte Check-then-act-Sequenzen zu den häufigsten gravierenden Findings, und wir sehen fast nie, dass ein Tool eine davon unaufgefordert markiert.
Autorisierungsgrenzen sind die Lücke, die uns am meisten beunruhigt. Der Endpoint authentifiziert den User, validiert den Payload und aktualisiert dann jede Datensatz-ID, die im Request steht. Copilot und Cursor bestätigen, dass Authentifizierung existiert und die Eingabe validiert wird. Fast nie fragt ein Tool, ob User 4711 überhaupt Rechnung 8102 ändern dürfen sollte, die zu einem anderen Tenant gehört. Genau so bearbeitet ein User über einen völlig legitimen Endpoint die Daten eines anderen Kunden, und es sieht exakt aus wie funktionierender Code. Er besteht die Tests. Er besteht das KI-Review. Er ist eine Datenpanne, die auf einen neugierigen User wartet.
Viertens: Wechselwirkungen zwischen zwei einzeln korrekten Änderungen. Ein Pull Request ergänzt einen Dateiexport. Ein anderer lockert Wochen später die Dateinamen-Validierung für einen Kunden, der Leerzeichen in Reportnamen wollte. Jeder PR ist für sich in Ordnung, und jeder bekam ein sauberes KI-Review. Zusammen erlauben sie Path Traversal. Kein Diff-fokussierter Reviewer, ob Mensch oder Maschine, findet das ohne Wissen über die jeweils andere Änderung, aber ein erfahrener Mensch erinnert sich deutlich wahrscheinlicher daran, dass es das Exportfeature gibt.
Und schließlich Architektur. Eine Änderung kann lokal korrekt und trotzdem falsch für das System sein: ein synchroner HTTP-Call, der in einem heißen Request-Pfad landet, eine neue direkte Abhängigkeit aus einem Modul, das bewusst isoliert gehalten wurde, ein Cache vor Daten, die read-after-write-konsistent sein müssen. KI-Reviewer bewerten den Code, der vor ihnen liegt. Sie wissen nicht, welche deiner Constraints Absicht sind.
Warum sich die Lücken genau dort häufen
In dieser Liste steckt ein Muster. Jeder verlässliche Treffer ist innerhalb des Diffs selbst sichtbar. Jede verlässliche Lücke braucht Kontext, den der Diff nicht trägt: die Domäne, das Concurrency-Verhalten des Deployments, das Tenant-Modell, die Historie benachbarter Änderungen, die Architekturentscheidungen, die jemand vor drei Jahren aus Gründen getroffen hat, die nie aufgeschrieben wurden.
Ein Reviewer kann nur beurteilen, was er sieht. Aktuelle Tools sehen die geänderten Dateien plus das, was die Kontextsuche hereinholt, und Retrieval ist gut darin, ähnlichen Code zu finden, nicht darin, die Invariante zu finden, von der dein Geschäft abhängt. Menschliche Reviewer tragen diese Invariante im Kopf. Das, mehr als reine Fähigkeit im Codelesen, macht ein Senior-Review tatsächlich aus. Und deshalb schließt sich die Lücke auch nicht einfach dadurch, dass die Modelle besser im Codelesen werden. Die fehlende Information ist organisatorisch, nicht textuell.
Das deckt sich mit dem, was wir beim Audit stark KI-unterstützt gebauter Codebasen finden: Der Code ist Zeile für Zeile oft sauberer als typischer menschlicher Output, während sich die Defekte in genau den Kategorien oben konzentrieren. Über die Testseite davon haben wir in unserem Beitrag über KI-generierte Tests, die Bugs verstecken geschrieben.
Ein Workflow, der beide Stärken nutzt
Die praktische Antwort ist, jeder Art von Reviewer die Ebene zuzuweisen, auf der sie gut ist.
Lass das KI-Review zuerst laufen, bevor ein Mensch irgendetwas ansieht. Lass es das Rauschen wegräumen: Injection-Muster, N+1-Queries, Stil-Drift, Null-Handling. Behebe diese Findings, bevor du ein menschliches Review anforderst, damit der Mensch darauf keine Aufmerksamkeit mehr verwenden muss.
Danach reviewt ein Mensch auf Korrektheit. Die Frage an dieser Stelle ist, ob die Änderung das tut, was das Ticket wirklich meinte, und was an den Rändern passiert. Hier sterben die Bugs mit den Bestandspreisen, und dafür braucht es einen Reviewer, der das Produkt kennt.
Für Code, der Authentifizierung, Autorisierung, Zahlungen oder Datenzugriff berührt, kommt ein zweiter, sicherheitsfokussierter menschlicher Durchgang dazu. Das ist ein kleiner Teil der meisten Changesets, trägt aber den Großteil des Risikos für eine Datenpanne. Der Reviewer sollte eine Frage unerbittlich stellen: Kann ein gültiger, authentifizierter User Daten oder Aktionen erreichen, die nicht seine sind? Nach unserer Erfahrung findet diese eine Gewohnheit mehr reale Schwachstellen als jedes Tooling-Investment vergleichbarer Größe.
Eine Warnung: Lass ein sauberes KI-Review kein Vertrauen erzeugen, das es nicht verdient hat. Ein grüner erster Durchgang heißt, dass die offensichtlichen Probleme fehlen. Über die fünf Kategorien oben sagt er nichts, und ihn als Freigabe zu behandeln ist der Weg, auf dem Teams den Autorisierungsbug mit einem beruhigenden Review im Anhang ausliefern.
Herausfinden, was deine Reviews bisher übersehen haben
Wenn dein Team heute auf KI-Review setzt, ist der nützliche nächste Schritt herauszufinden, was dabei durchgerutscht ist. Das ist eine begrenzte Übung: ein unabhängiger Durchgang über die Concurrency-, Autorisierungs- und Geschäftslogik-Ebenen einer bestehenden Codebasis, der Kern unserer Arbeit in der Code-Quality-Beratung. Für Teams, die neue Produkte mit viel KI-Unterstützung bauen, verankern wir dieses Review-Modell außerdem vom ersten Sprint an in Projekten der individuellen Softwareentwicklung, was deutlich günstiger ist, als es nach einem Vorfall nachzurüsten.
Wenn du eine zweite Meinung dazu willst, was dein aktuelles Review-Setup übersieht, schreib an hello@wolf-tech.io oder schau dich auf wolf-tech.io um. Ein kurzes Gespräch über deinen Stack und deinen Review-Prozess reicht meist, um zu sagen, ob sich ein Audit rechnet.