KI Code Review ist gute Erstprüfung, aber keine Freigabe

KI Code Review findet vor allem Muster, die im Ausschnitt sichtbar sind. Dazu gehören Regelverstöße, offensichtliche Stilbrüche, fehlende Tests, Duplikate und einfache Inkonsistenzen. Auch bekannte Sicherheitsmuster fallen auf — aber nur als Erstprüfung.

Der Nutzen entsteht, bevor ein Mensch den Pull Request liest. Der Prüfer räumt Kleinkram aus dem Weg und markiert Stellen, die eine menschliche Entscheidung verdienen. Die Freigabe bleibt beim Team, weil der Ausschnitt selten die ganze Änderung erklärt.

Ein KI-Prüfer übersieht alles, was außerhalb des sichtbaren Ausschnitts entschieden wird. Dazu zählen komplexe Fachlogik, Architekturfolgen, projektspezifische Konventionen und implizite Abhängigkeiten. Der Treffer im Code sagt noch nicht, ob die Änderung im Betrieb stimmt.

Besonders gefährlich sind Reparaturen, die lokal richtig aussehen. Eine scheinbar saubere Korrektur kann an anderer Stelle Schaden erzeugen — etwa bei Datenmigration, Berechtigung oder Vertragslogik. Kontextarme Prüfung ist stark beim Lesen, aber schwach beim Bewerten von Folgen.

Der Prüfer bekommt absichtlich keinen Projektkontext, weil Distanz die Aufgabe verändert. Ein Modell, das zugleich schreibt und bewertet, gibt sich selbst recht. Der Ausschnitt erscheint wie bei einem fremden Review — genau dadurch wird Selbstbestätigung schwerer.

In dieser Architektur liest der Prüfer Dateien und schreibt Befunde, aber er startet keinen Test und keine Anwendung. Das feste Ausgabeformat zwingt zur Begründung: Regel, Beobachtung, Risiko und empfohlene Nachprüfung stehen getrennt da.

Zwei Prüfschritte, zwei Rollen: der eine liest nur, der andere schreibt Tests und führt sie aus. Die erste Rolle bewertet den konkreten Ausschnitt, benennt Risiko und trennt Sperren von Hinweisen. Die zweite Rolle prüft den Befund gegen Tests, Laufzeit und Nebenwirkungen.

Die Reihenfolge ist der Schutz gegen einen einzigen bestätigenden KI-Schritt. Erst kommt der fremde Blick auf den Ausschnitt, dann die Gegenprobe mit Tests und Ausführung. Dadurch wird aus einem Hinweis keine Wahrheit, bevor eine andere Rolle ihn belastet.

KI Code Review passt vor das menschliche Review im Pull Request. Git liefert den Änderungsstand, Continuous Integration und Continuous Delivery liefern den Takt. Der Prüfer sitzt dazwischen — nach dem geänderten Code, aber vor der menschlichen Freigabe.

In bestehende Abläufe gehört der Prüfer als Vorfilter, nicht als neue Freigabeschranke. Externe Unterstützung hilft, wenn Regeln, Ausgabeformat und Verantwortliche zuerst sortiert werden müssen. Architekturentscheidungen und finale Freigaben bleiben bei Menschen.

Fehlalarme sinken, wenn der Prüfer nicht frei formuliert. Ein Befund braucht ein festes Format, eine Kritikalität und eine Regel, gegen die sich der Hinweis prüfen lässt.

Eine Sperre braucht eine andere Behandlung als ein Hinweis. Kritische Befunde gehen in eine Nachprüfung, Hinweise bleiben sichtbar, aber sie blockieren nicht automatisch. So entsteht Druck nur dort, wo eine Regel wirklich trägt.

Der Erfolg zeigt sich auf Prozessebene, nicht am Klang der Kommentare. Geeignete Messgrößen sind Zeit bis zum ersten Review, später gefundene Fehler, unnötige Warnungen, Nacharbeit pro Pull Request und Akzeptanz im Team.

Wichtig ist die Gegenprobe: Wenn Warnungen oft weggeklickt werden, entlastet die Prüfung nicht. Wenn menschliche Reviewer schneller bei Architektur und Fachlogik ankommen, erfüllt der Vorfilter seinen Zweck.

Der Einsatz lohnt sich nicht, wenn die Änderung fast nur aus Fachlogik besteht. Auch unvollständige Tests, hohe Sicherheitsanforderungen ohne Freigabekette und fehlende Review-Regeln sprechen gegen einen automatischen Vorfilter.

Teams ohne gepflegte Review-Regeln bekommen durch KI Code Review nur schneller uneinheitliche Kommentare. Bei unklaren Rollen beginnt die Prüfung der Review-Architektur im eigenen Team, nicht beim Modell. KI hilft nur dort, wo Regeln und Kontextgrenzen klar sind.