Reviews: Warum der Mensch das letzte Wort haben muss

Hier kommt die unpopulärste Meinung dieser Serie: KI-generierter Code braucht mehr Review, nicht weniger. Nicht weil die KI schlechten Code schreibt — oft ist das Gegenteil der Fall. Sondern weil Code, der auf den ersten Blick perfekt aussieht, die gefährlichste Art von fehlerhaftem Code ist.

Warum Reviews wichtiger sind als je zuvor

Vor der KI-Ära war schlechter Code offensichtlich. Falsche Einrückung, fehlende Fehlerbehandlung, Magic Numbers — du hast es beim Drüberlesen gesehen. KI-generierter Code hat dieses Problem nicht. Er ist sauber formatiert, gut benannt, syntaktisch korrekt. Er kompiliert, er besteht einfache Tests, er liest sich wie aus einem Lehrbuch. Und genau das macht ihn gefährlich — weil die Oberfläche nichts über die tieferliegenden Probleme verrät.

Unter der sauberen Oberfläche können sich Fehler verstecken, die nur Domänenwissen aufdeckt. Die KI hat eine Rabattberechnung implementiert, die mathematisch korrekt ist — aber nicht zum Geschäftsmodell passt, weil Rabatte in diesem System nie unter null gehen dürfen und der Gesamtpreis nie negativ werden kann. Die KI hat ein Caching eingebaut, das die Performance verbessert — aber invalidiert den Cache nie, weil sie nicht weiß, dass sich die zugrundeliegenden Daten stündlich ändern. Solche Fehler findest du nicht mit PHPStan — du findest sie nur, wenn du den Code liest und gegen dein Wissen über das System prüfst.

Die Gefahr ist real: Weil der Code gut aussieht, überspringen Entwickler das Review oder skimmen nur darüber. „Sieht gut aus, die KI hat das schon richtig gemacht.“ Das ist der Moment, in dem subtile Bugs in die Produktion gelangen. Ich kenne Teams, die nach der Einführung von KI-Tools mehr Bugs in der Produktion hatten als vorher — nicht weil die KI schlechteren Code schrieb, sondern weil die Reviews nachlässiger wurden.

Es gibt einen psychologischen Effekt, der das verschärft: Automation Bias. Wenn eine Maschine etwas produziert hat, neigen Menschen dazu, es weniger kritisch zu hinterfragen als menschliche Arbeit. Wir vertrauen dem Algorithmus mehr als dem Kollegen — obwohl der Algorithmus keine Ahnung von unserem Geschäftskontext hat. Dieses Vertrauen ist der eigentliche Feind der Codequalität, nicht die KI selbst. Das Bewusstsein für diesen Bias ist der erste Schritt, ihm entgegenzuwirken.

Was ein Review beinhalten muss

Ein Review von KI-generiertem Code muss fünf Fragen beantworten. Architektur-Fit: Gehört dieser Code hierher? Passt er in die bestehende Struktur, oder hat die KI eine eigene Architektur erfunden, die mit dem Rest des Projekts kollidiert? Ich habe schon gesehen, wie eine KI ein Repository-Pattern in ein Projekt eingeführt hat, das bewusst ohne Repositories arbeitet — weil das Pattern in den Trainingsdaten häufiger vorkam als der direkte Datenzugriff.

Sicherheit: Sind alle Eingaben validiert? Werden Ausgaben korrekt escaped? Gibt es SQL-Injections, XSS-Vektoren, fehlende Autorisierungsprüfungen? Die KI vergisst Sicherheitsaspekte nicht häufiger als menschliche Entwickler — aber sie vergisst sie auf eine subtilere Art. Ein fehlender htmlspecialchars()-Aufruf in einer Template-Variable fällt erst auf, wenn jemand gezielt danach sucht. Eine fehlende Nonce-Prüfung in einem WordPress-Formular sieht man nur, wenn man weiß, dass sie dort hingehört.

Performance: N+1-Queries sind der Klassiker. Die KI generiert eine Schleife, die für jeden Datensatz eine Datenbankabfrage auslöst, statt einen JOIN oder eine Batch-Abfrage zu verwenden. Bei zehn Testdatensätzen fällt das nicht auf. Bei zehntausend in der Produktion bricht die Seite ein. Unnötige Datenbankaufrufe, fehlende Indizes, überflüssige Berechnungen in Schleifen — all das gehört ins Review und erfordert ein Verständnis dafür, wie dein System unter Last funktioniert. Die KI optimiert für Lesbarkeit und Korrektheit, aber Performance ist selten ihr Fokus.

Wartbarkeit: Wird jemand in sechs Monaten verstehen, was dieser Code tut? Hat die KI sinnvolle Variablennamen gewählt, oder heißen die Variablen $data, $result und $temp? Gibt es Kommentare, die das Warum erklären — nicht das Was? Wartbarkeit ist der am meisten unterschätzte Aspekt von Code-Qualität, und die KI hat hier blinde Flecken, weil sie nicht weiß, wer diesen Code in Zukunft lesen wird und welches Vorwissen diese Person mitbringt.

Korrektheit: Löst der Code tatsächlich das richtige Problem? Nicht „ein“ Problem, sondern „das“ Problem. Die KI liefert gerne eine technisch saubere Lösung für ein Problem, das du gar nicht hattest — weil sie deine Frage anders interpretiert hat, als du sie gemeint hast. Ein perfekt implementierter Sortieralgorithmus nützt dir nichts, wenn du eigentlich einen Filter brauchtest.

KI-Review vs. Mensch-Review

Kann die KI nicht einfach ihren eigenen Code reviewen? Technisch ja. Praktisch ist das wie eine Klausur vom selben Lehrer korrigieren zu lassen, der sie geschrieben hat. Dieselben blinden Flecken, dieselben Annahmen, dieselben Trainingsdaten. Die KI findet Syntax-Fehler, Style-Violations und offensichtliche Bugs. Sie findet, was PHPStan und PHP-CS-Fixer auch finden. Für diese Art von Prüfung brauchst du keine KI — dafür hast du statische Analyse-Tools in deiner CI/CD-Pipeline.

Was die KI nicht kann: Domänenwissen einbringen. Sie weiß nicht, dass euer Payment-Provider bei bestimmten Beträgen anders rundet. Sie weiß nicht, dass die Legacy-API in Version 2.3 einen Breaking Change hat, den ihr schon einmal als Bug hattet. Sie weiß nicht, dass der Vertrieb letzte Woche eine Sonderregelung für Großkunden vereinbart hat, die die Rabattlogik betrifft. Dieses Wissen existiert in den Köpfen deines Teams, nicht in Trainingsdaten.

Ein menschlicher Reviewer bringt genau das mit: Kontext, Geschichte, Geschäftswissen. Er stellt die Frage „Ist das die richtige Lösung?“ — nicht nur „Ist das eine funktionierende Lösung?“ Dieser Unterschied ist fundamental und wird es bleiben, solange KI-Modelle keinen Zugang zu eurem Firmen-Slack, euren Meeting-Notizen und dem Gedächtnis eures Teams haben. Die KI kann den zweiten Teil gut beantworten. Den ersten Teil kann nur ein Mensch beantworten, der das Projekt und das Geschäft kennt.

KI als Review-Ergänzung, nicht als Ersatz

Das heißt nicht, dass KI-Reviews nutzlos sind. Im Gegenteil — sie eignen sich hervorragend als erste Filterstufe. Lass die KI den Code auf offensichtliche Probleme prüfen, bevor ein Mensch draufschaut. Das spart dem menschlichen Reviewer Zeit für die wichtigen Fragen. Die KI findet den fehlenden Return-Type, der Mensch findet die falsche Business-Logik. Beide Reviews zusammen sind stärker als jedes einzelne.

In der Praxis sieht das so aus: Der Pre-Commit-Hook läuft PHPStan und PHP-CS-Fixer. Die CI/CD-Pipeline führt die Tests aus. Optional prüft eine KI den Commit auf bekannte Anti-Patterns. Und am Ende sitzt ein Mensch, der den Code liest und die Frage stellt: Löst das tatsächlich unser Problem? Jede Schicht fängt andere Fehler ab. Keine Schicht allein reicht aus. Zusammen bilden sie ein Sicherheitsnetz, das die meisten Fehler fängt, bevor sie die Produktion erreichen.

Der persönliche Review-Prozess

Mein Vorgehen ist simpel und nicht verhandelbar: Jede Zeile lesen. Nicht skimmen, nicht überfliegen, lesen. Wenn der Code 200 Zeilen hat, lese ich 200 Zeilen. Wenn ich nach 50 Zeilen denke „das sieht alles gut aus“, zwinge ich mich, die restlichen 150 genauso aufmerksam zu lesen. Denn genau dort verstecken sich die Fehler — am Ende, wo die Aufmerksamkeit nachlässt und das Gehirn anfängt, Patterns zu erkennen statt Code zu analysieren.

Bei jeder Funktion frage ich mich: „Hätte ich das so geschrieben?“ Wenn ja, weiter. Wenn nein, verstehen warum die KI es anders gemacht hat. Manchmal ist die KI-Lösung besser — sauberer, performanter, idiomatischer. Dann lerne ich etwas, und das passiert öfter als man denkt. Manchmal hat die KI aber eine falsche Annahme getroffen, und dann habe ich einen Bug gefunden, bevor er in der Produktion landet. Beide Ergebnisse sind wertvoll.

Besondere Aufmerksamkeit verdienen Grenzfälle und Fehlerbehandlung. Was passiert bei leeren Eingaben? Was bei null? Was bei unerwarteten Typen? Was bei gleichzeitigen Zugriffen? Die KI behandelt oft den Happy Path perfekt und die Edge Cases gar nicht — weil du sie im Prompt nicht erwähnt hast und die KI sie nicht aus deinem Geschäftskontext ableiten kann. Ein Commit, der nur den Happy Path abdeckt, ist ein halber Commit.

Reviews dauern. Sie kosten Zeit, die sich nicht direkt in Features messen lässt. Aber ein gründliches Review von KI-generiertem Code ist keine Zeitverschwendung — es ist der Moment, in dem du den Wert der KI-Unterstützung sicherst. Ohne Review ist KI-Code eine Blackbox. Mit Review ist er geprüfter, verstandener, wartbarer Code. Und das ist der ganze Punkt — nicht schneller Code, sondern richtiger Code.

Review-Checkliste für KI-Code

In meiner täglichen Arbeit habe ich mir eine mentale Checkliste angewöhnt, die ich bei jedem KI-generierten Code durchgehe. Erstens: Hat die KI Features hinzugefügt, die ich nicht angefordert habe? Das ist der häufigste Fehler — ein zusätzliches Error-Handling hier, eine kleine Refaktorierung dort. Nicht schlimm im Einzelfall, aber es summiert sich und macht den Commit unübersichtlich.

Zweitens: Verwendet der Code Funktionen oder APIs, die ich nicht kenne? Wenn ja, verifizieren. Nicht annehmen, dass sie existieren — die KI erfindet APIs. Drittens: Sind die Variablennamen konsistent mit dem restlichen Projekt? Die KI hat ihren eigenen Benennungsstil, der nicht immer zu deinem passt. Viertens: Gibt es hardcodierte Werte, die in eine Konfiguration gehören? Die KI nimmt gerne Abkürzungen, die in einem Prototyp okay sind, aber in Produktionscode nicht.

Fünftens, und das ist der wichtigste Punkt: Würde ich diesen Code einem Kunden gegenüber verantworten? Wenn die Antwort nicht ein klares Ja ist, geht der Code zurück. Nicht an die KI — an dein eigenes Urteilsvermögen. Denn am Ende trägst du die Verantwortung für jeden Commit, der in der Produktion landet. Nicht die KI, nicht das Tool, nicht der Algorithmus — du.

Diese Checkliste klingt aufwendig, dauert in der Praxis aber fünf bis zehn Minuten pro Review. Das ist weniger als die Zeit, die du für das Debugging brauchst, wenn ein unkontrollierter KI-Output einen subtilen Bug einführt.

Und mit jeder Wiederholung wird der Prozess schneller, weil du lernst, worauf du bei welchem Modell besonders achten musst. Dein Review-Muskel wird stärker — und das macht dich auch bei menschlichem Code zum besseren Reviewer. Eine Fähigkeit, die sich doppelt auszahlt.

Alle Teile dieser Serie

Teil 1: Projekt vorbereiten — Dateien, Struktur, Kontext
Teil 2: Gute Regeln schreiben — der KI Grenzen setzen
Teil 3: Saubere Prompts — präzise formulieren, Token sparen
Teil 4: Modelle und Tools — Stärken, Schwächen, Einsatzgebiete
Teil 5: Sicherheit — was nicht in den Prompt gehört
Teil 6: Reviews — warum der Mensch das letzte Wort haben muss
Teil 7: Wann KI nicht nutzen — die Grenzen kennen
Glossar: Begriffe für Entwickler