KI-generierten Code kritisch prüfen statt blind vertrauen

1. Warum KI-generierter Code denselben Review-Maßstab braucht

Ein Pull Request, den ein Kollege geschrieben hat, wird geprüft: Logik nachvollziehen, Tests lesen, Randfälle hinterfragen, bei Unsicherheit nachfragen. Bei einem Vorschlag von Claude oder einem anderen KI-Assistenten fällt dieser Reflex bei vielen Entwicklern überraschend oft weg, obwohl das Ergebnis strukturell dasselbe ist: Code, der von einem Dritten geschrieben wurde und in eine gemeinsame Codebasis einfließen soll. Der Unterschied liegt nicht in der Notwendigkeit der Prüfung, sondern darin, dass die Fehlerquellen anders verteilt sind als bei menschlichem Code.

Ein KI-Modell kennt weder den tatsächlichen Zustand der Produktionsdatenbank noch die konkrete Lastsituation im Live-Betrieb, noch alle impliziten Annahmen, die im Team über Jahre gewachsen sind. Es generiert eine statistisch plausible Lösung auf Basis von Trainingsdaten und dem bereitgestellten Kontext, nicht zwingend die für dieses eine System korrekte Lösung. Das macht KI-generierten Code weder grundsätzlich schlechter noch besser als menschlichen Code, sondern schlicht review-pflichtig nach denselben Maßstäben, ergänzt um ein Bewusstsein für die Fehlermuster, die in den folgenden Abschnitten konkret behandelt werden.

2. Automation Bias: Warum wir KI-Code weniger kritisch lesen

Automation Bias beschreibt die kognitive Tendenz, automatisiert erzeugten Ergebnissen mehr zu vertrauen als sie objektiv verdienen, einfach weil sie von einem System statt von einem fehleranfälligen Menschen stammen. Bei KI-generiertem Code verstärkt sich dieser Effekt durch die äußere Form: sauber eingerückter Code, passende Variablennamen, vollständige PHPDoc-Blöcke und ein selbstbewusster erklärender Kommentar erzeugen den Eindruck von Sorgfalt, unabhängig davon, ob die Logik tatsächlich korrekt ist. Ein Reviewer, der unbewusst von der Form auf den Inhalt schließt, überspringt genau die Fragen, die er bei einem hingerotzten Fix eines gestressten Kollegen automatisch stellen würde.

Wirksam dagegen hilft eine bewusste Umkehr der Grundannahme: KI-generierten Code wie den Vorschlag eines neuen, unbekannten Teammitglieds behandeln, dessen Erfahrungsstand nicht eingeschätzt werden kann. Diese Haltung ist unabhängig von der tatsächlichen Qualität des Modells sinnvoll, weil sie den Reviewer dazu zwingt, Behauptungen im Code, etwa in Kommentaren oder Docstrings, gegen die tatsächliche Implementierung zu prüfen statt sie zu übernehmen. Gerade bei sicherheitsrelevantem oder geschäftskritischem Code ist diese zusätzliche Distanz kein Misstrauensvotum gegen das Werkzeug, sondern schlicht professionelle Sorgfaltspflicht.

3. Subtile Fehler bei Randfällen und Grenzwerten

Der Happy Path, also der Ablauf mit gültigen, typischen Eingaben, wird von KI-Assistenten in aller Regel korrekt umgesetzt, weil er in den Trainingsdaten am häufigsten vorkommt. Randfälle wie leere Listen, Null-Werte, negative Zahlen, sehr große Zahlen, doppelte Einträge oder gleichzeitige Zugriffe werden dagegen oft nur teilweise oder gar nicht behandelt, obwohl der generierte Code auf den ersten Blick vollständig wirkt. Besonders tückisch sind Fälle, in denen der Code für den Randfall nicht abstürzt, sondern ein plausibel aussehendes, aber falsches Ergebnis liefert, etwa eine falsche Rundung bei Preisberechnungen oder einen stillschweigend übersprungenen Datensatz.

Eine gezielte Prüfstrategie fragt bei jeder generierten Funktion aktiv: Was passiert bei einer leeren Eingabe, bei genau einem Element, bei einem negativen oder überlaufenden Wert, bei gleichzeitigem Zugriff aus zwei Threads oder Requests? Diese Fragen lassen sich nicht zuverlässig aus dem Code selbst ablesen, sie müssen explizit gestellt und im Zweifel mit einem Testfall belegt werden. Das folgende Beispiel zeigt eine von einem KI-Assistenten vorgeschlagene Funktion zur Rabattberechnung, die bei einer leeren Warenkorb-Liste eine Division durch Null auslöst, ein Fehler, der im Review ohne expliziten Blick auf den Randfall leicht übersehen wird.

# AI-suggested function looks complete but misses the empty-list edge case
def average_discount(cart_items):
    total_discount = sum(item.discount for item in cart_items)
    return total_discount / len(cart_items)  # ZeroDivisionError if cart_items is empty

# Corrected version: explicit guard for the edge case, plus a regression test
def average_discount(cart_items):
    if not cart_items:
        return 0.0
    total_discount = sum(item.discount for item in cart_items)
    return total_discount / len(cart_items)

def test_average_discount_empty_cart():
    assert average_discount([]) == 0.0

4. Veraltete oder falsche API-Nutzung erkennen

Jedes Sprachmodell hat einen Trainingsdaten-Stand, nach dem neue Versionen von Bibliotheken, Frameworks und Sprach-Features nicht mehr zuverlässig bekannt sind. Für ein Magento-Projekt bedeutet das konkret: Ein Vorschlag kann eine seit mehreren Major-Versionen als deprecated markierte Methode verwenden, ein veraltetes Layout-XML-Muster reproduzieren oder eine Klasse aus einem Modul referenzieren, das im aktuellen Projekt längst durch ein anderes ersetzt wurde. Der generierte Code funktioniert dabei oft trotzdem, weil die alte API aus Kompatibilitätsgründen noch existiert, erzeugt aber technische Schulden und in manchen Fällen Deprecation-Warnungen, die erst bei einem späteren Major-Upgrade zum echten Problem werden.

Das gleiche Muster zeigt sich sprachübergreifend in der Frontend-Entwicklung. Ein KI-Assistent schlägt beispielsweise in einem Node.js-Kontext gelegentlich noch den mit Sicherheitswarnung versehenen Buffer-Konstruktor vor, obwohl die sichere Alternative seit Jahren dokumentierter Standard ist. Der zuverlässigste Gegencheck ist ein kurzer Blick in die offizielle Dokumentation oder das Changelog der tatsächlich im Projekt verwendeten Version, nicht das Vertrauen darauf, dass ein selbstbewusst formulierter Vorschlag automatisch aktuell ist.

// AI-suggested code using a deprecated, security-flagged constructor
const buf = new Buffer(1024); // deprecated since Node.js 6, unsafe with numeric input

// Corrected version using the documented safe replacement
const buf = Buffer.alloc(1024); // zero-filled, predictable, no leftover memory content

5. Sicherheitslücken, die KI-Assistenten gerne übersehen

KI-Assistenten optimieren primär auf funktionierenden Code, der die gestellte Aufgabe löst, nicht zwingend auf die sicherste Variante dieser Lösung. Typische Muster, die sich in generiertem Code wiederholt finden: fehlende Escaping- oder Prepared-Statement-Nutzung bei Datenbankabfragen, fehlende ACL-Prüfung in einem neuen Admin-Controller, zu breit gefasste CORS-Konfigurationen mit einem Wildcard-Origin, oder Zugangsdaten, die als Platzhalter direkt im Beispielcode landen und im schlimmsten Fall unverändert übernommen werden. Keines dieser Muster ist böswillig, sie entstehen schlicht, weil die funktionale Anforderung im Prompt oft klarer formuliert ist als die implizite Sicherheitsanforderung.

Eine wirksame Gegenmaßnahme ist eine feste, kurze Sicherheits-Checkliste, die bei jeder KI-generierten Änderung mit Außenwirkung durchlaufen wird: Werden Nutzereingaben validiert und escaped? Wird die Berechtigung des aufrufenden Nutzers tatsächlich geprüft, nicht nur die Existenz eines Login-Tokens? Sind Zugangsdaten und Secrets ausgelagert statt hartkodiert? Ist eine Konfiguration wie CORS oder eine Webhook-Freigabe so eng wie möglich statt so bequem wie möglich formuliert? Das folgende Beispiel zeigt eine von einem Assistenten vorgeschlagene Webhook-Konfiguration, die jede Origin akzeptiert und keine Signaturprüfung vorsieht.

{
  "webhook_insecure_suggestion": {
    "allowed_origin": "*",
    "require_signature": false,
    "comment": "AI suggestion optimized for a working demo, not for production"
  },
  "webhook_corrected": {
    "allowed_origin": "https://mironsoft.de",
    "require_signature": true,
    "signature_header": "X-Webhook-Signature",
    "comment": "Explicit origin and mandatory signature check before processing"
  }
}

6. Halluzinierte Funktionen, Pakete und Parameter

Ein weniger offensichtliches, aber praktisch relevantes Fehlermuster ist die Halluzination nicht existierender Bausteine: Das Modell erfindet einen plausibel klingenden Methodennamen auf einer bekannten Klasse, einen Konstruktor-Parameter, den es nie gab, oder gleich ein ganzes Composer- beziehungsweise npm-Paket, das nie veröffentlicht wurde. Solche Vorschläge fallen beim Ausführen häufig sofort auf, weil ein Fatal Error oder ein "package not found" auftritt. Riskanter wird es, wenn ein Angreifer einen halluzinierten, aber plausibel benannten Paketnamen tatsächlich registriert und dort Schadcode hinterlegt, ein als Slopsquatting bekanntes Angriffsmuster, das gezielt auf unreflektiert übernommene KI-Vorschläge abzielt.

Der zuverlässige Gegencheck ist simpel, aber wird häufig übersprungen: Jeder neue Paketname wird vor der Installation im offiziellen Registry, bei Composer also auf Packagist, nachgeschlagen und auf Downloadzahlen, Maintainer und letzte Aktualisierung geprüft. Jede unbekannte Methode auf einer vertrauten Klasse wird kurz gegen die tatsächlich installierte Version der Bibliothek verifiziert, statt sich auf die selbstbewusste Formulierung des Vorschlags zu verlassen. Dieser Schritt kostet wenige Minuten und verhindert sowohl funktionale Fehlschläge als auch das Einschleusen von Schadcode über einen erfundenen Abhängigkeitsnamen.

7. Ein praktischer Review-Workflow für KI-generierte Änderungen

Ein wiederholbarer Workflow reduziert die Abhängigkeit von der Tagesform des Reviewers und macht die Prüfung KI-generierter Änderungen zu einem festen Bestandteil des Entwicklungsprozesses statt einer optionalen Zusatzaufgabe. Der Ablauf beginnt mit dem vollständigen Lesen des Diffs, nicht nur der Zusammenfassung, gefolgt von einem Lauf der statischen Analyse und der bestehenden Testsuite. Erst danach folgt die gezielte Prüfung der in diesem Artikel behandelten Fehlermuster: Randfälle, API-Aktualität, Sicherheitsaspekte und die Existenz aller referenzierten Pakete und Methoden.

Wichtig ist, diesen Ablauf nicht nur im Kopf zu haben, sondern als Skript oder Checkliste greifbar zu machen, damit er unter Zeitdruck nicht stillschweigend verkürzt wird. Für ein Magento-Projekt mit dem hier verwendeten Docker-Setup lässt sich der technische Teil des Workflows direkt in ein wiederverwendbares Skript gießen, das nach jeder von Claude Code vorgeschlagenen und angenommenen Änderung ausgeführt wird, bevor der Commit erstellt wird.

#!/usr/bin/env bash
# review-ai-diff.sh: run this after accepting an AI-suggested change, before commit
set -euo pipefail

echo "[1/5] Reviewing full diff (not just the summary)..."
git diff --staged

echo "[2/5] Running static analysis..."
bin/analyse app/code/Mironsoft/Checkout --level=5

echo "[3/5] Running code style check..."
bin/phpcs app/code/Mironsoft/Checkout

echo "[4/5] Running existing test suite..."
bin/cli vendor/bin/phpunit --filter Checkout

echo "[5/5] Checking for newly referenced packages..."
git diff --staged composer.json | grep -E '^\+' || echo "No new dependencies added"

echo "Manual checklist: edge cases, API currency, security, hallucinated calls."

8. Tools und Automatisierung als Unterstützung, nicht Ersatz

Statische Analyse mit PHPStan, Codestil-Prüfung mit phpcs und automatisierte Sicherheitsscanner fangen einen relevanten Teil der genannten Fehlermuster zuverlässig ab, insbesondere veraltete Methodenaufrufe, offensichtliche Typfehler und bekannte unsichere Funktionen. Diese Werkzeuge lassen sich zusätzlich über Claude-Code-Hooks automatisch nach jeder Dateiänderung auslösen, sodass ein grober Fehler nicht erst im nächsten manuellen Review-Durchgang auffällt, sondern unmittelbar nach der Codegenerierung. Das verkürzt die Feedback-Schleife erheblich und entlastet den menschlichen Reviewer von der Suche nach mechanisch erkennbaren Fehlern.

Was diese Werkzeuge strukturell nicht leisten können, ist die Bewertung von Geschäftslogik, impliziten Annahmen über Systemverhalten und Sicherheitsentscheidungen, die von der konkreten Bedrohungslage des Projekts abhängen. Ein Scanner erkennt eine fehlende Escaping-Funktion, aber nicht, ob die gewählte Rabattregel für einen bestimmten Kundensegment geschäftlich überhaupt sinnvoll ist. Automatisierung sollte deshalb als erste Filterstufe verstanden werden, die offensichtliche Fehler vor dem menschlichen Review abfängt, nicht als Ersatz für die inhaltliche Prüfung durch einen Entwickler mit Kontextwissen über das konkrete Projekt.

#!/usr/bin/env bash
# post-edit-hook.sh: triggered automatically by Claude Code after each file write
# Registered under "hooks": { "PostToolUse": [...] } in .claude/settings.json
set -euo pipefail

changed_file="$1"

if [[ "$changed_file" == *.php ]]; then
  echo "[hook] Running static analysis on $changed_file"
  bin/analyse "$(dirname "$changed_file")" --level=5 || echo "[hook] PHPStan found issues, review before commit"

  echo "[hook] Running code style check on $changed_file"
  bin/phpcs "$changed_file" || echo "[hook] Style violations found, review before commit"
fi

9. Review-Gewohnheiten im Vergleich

Die folgende Gegenüberstellung zeigt, wie sich eine unreflektierte Übernahme von KI-Vorschlägen von einem disziplinierten Review-Ansatz in der Praxis unterscheidet. Der Unterschied liegt selten in der eingesetzten Technologie, sondern in der Frage, ob die im Artikel beschriebenen Prüfpunkte tatsächlich als fester Bestandteil des Workflows verankert sind oder von der individuellen Aufmerksamkeit im Einzelfall abhängen.

In der Praxis zeigt sich, dass die rechte Spalte kaum mehr Zeit kostet als die linke, sofern der Workflow als Skript oder Checkliste vorliegt und nicht bei jedem Review neu erfunden werden muss. Der eigentliche Aufwand liegt nicht in der Ausführung der Prüfschritte, sondern in der Etablierung der Gewohnheit, sie bei jeder KI-generierten Änderung tatsächlich anzuwenden, auch wenn der Code auf den ersten Blick überzeugend fertig aussieht.

10. Zusammenfassung

KI-generierter Code braucht denselben Review-Maßstab wie jeder von Menschen geschriebene Code, weil er strukturell dasselbe ist: eine Änderung eines Dritten, die in eine gemeinsame Codebasis einfließen soll. Automation Bias führt dazu, dass sauber formatierter, selbstbewusst kommentierter Code unbewusst weniger kritisch geprüft wird, obwohl die tatsächliche Fehlerquote nicht automatisch niedriger liegt. Die relevanten Fehlermuster verteilen sich auf vier Bereiche: übersehene Randfälle bei leeren, negativen oder gleichzeitig verarbeiteten Eingaben, veraltete API-Nutzung aus dem Trainingsdaten-Stand des Modells, übersehene Sicherheitsaspekte wie fehlende Escaping- oder Berechtigungsprüfung, und halluzinierte, nicht existierende Funktionen oder Pakete.

Ein wiederholbarer Review-Workflow aus vollständigem Diff-Lesen, statischer Analyse, Testlauf und einer gezielten Prüfung dieser vier Fehlermuster reduziert die Abhängigkeit von der Tagesform des Reviewers erheblich. Tools wie PHPStan, phpcs und automatisierte Hooks fangen dabei einen relevanten Teil mechanisch erkennbarer Fehler ab, ersetzen aber nicht die inhaltliche Prüfung durch einen Entwickler mit Kontextwissen über das konkrete Projekt und dessen Geschäftslogik.

11. FAQ: KI-generierten Code kritisch prüfen