KI-Code-Review-Checkliste

KI-Tools wie ChatGPT, Claude, GitHub Copilot oder Cursor generieren in Sekunden Code, der funktional aussieht — aber oft Fehler versteckt: halluzinierte APIs, unsichere Defaults, fehlende Fehlerfälle oder Copy-Paste aus geschützten Quellen. Diese abhakbare Checkliste hilft dir, vor dem Merge systematisch zu prüfen, ob der Code produktionsreif ist.

Erstellt von der FlowKI-Community. Rein defensiv — es geht um sicheren Umgang mit generiertem Code, nicht um Angriffe. Orientierung, keine Vollständigkeitsgarantie.

---

1. Halluzinierte APIs & erfundene Bibliotheken

LLMs halluzinieren Funktionen, Parameter und ganze Pakete, die nie existierten. Der Code sieht plausibel aus, bricht aber beim ersten Ausführen.

• Import-Check: Jede importierte Bibliothek wirklich installiert? npm list <pkg> / pip show <pkg> ausführen.
• Versions-Check: Passt die verwendete API zur tatsächlich installierten Version? Nicht auf neuere/ältere Syntax verlassen.
• Funktions-Check: Gibt es die aufgerufene Methode wirklich? In der offiziellen Doku (nicht LLM) nachschlagen.
• Parameter-Check: Stimmen Anzahl, Namen und Typen der Parameter? LLMs erfinden oft Komfort-Parameter.
• Test ausführen: Code lokal laufen lassen — halluzinierte APIs werfen sofort AttributeError / TypeError / Module not found.

2. Sicherheit

KI-Code folgt oft dem kürzesten Weg — Sicherheit ist Nacharbeit.

• Secrets/Keys: Keine API-Keys, Passwörter, Tokens hartcodiert? Prüfe String-Literale, keine .env-Werte im Code.
• Input-Validierung: Werden Nutzereingaben validiert, bevor sie in SQL/Shell/LLM-Prompts gehen?
• Injection-Risiken: Kein raw SQL mit String-Interpolation, keine eval(), kein exec() mit User-Input?
• Unsichere Defaults: Hash-Algorithmen, CORS-Wildcard, fehlende CSRF-Protection? LLMs nutzen oft Beispiel-Configs.
• Berechtigungen: Auth-Checks an allen kritischen Endpunkten? Ownership-Prüfung vor Datenzugriff?
• Dependencies: npm audit / pip audit auf neue Abhängigkeiten laufen lassen — keine bekannten Vulns einbauen.

3. Korrektheit & Edge-Cases

LLMs optimieren für den Happy Path — Grenzfälle ignorieren sie gern.

• Tut es das Richtige? Code gegen die tatsächliche Anforderung prüfen, nicht nur ob er läuft.
• Leere Eingaben: Was passiert bei null, undefined, [], ""? Crasht es oder ist der Fehler gefangen?
• Grenzwerte: Off-by-one-Fehler, falsche Schleifen-Grenzen, Overflow bei großen Zahlen?
• Race-Conditions: Bei async/await — werden Promises richtig gewartet? Keine ungeschützten Zugriffe auf shared state?
• Fehlerbehandlung: Jede externe API/DB-Call hat try/catch oder .catch()? Error-Pfade führen zu sinnvollem Verhalten?
• Typen-Konsistenz: TypeScript/Pydantic-Schemas vorhanden und korrekt? Keine any / dict an kritischen Stellen?

4. Lizenz & Herkunft

LLMs lernen aus öffentlichem Code — auch aus proprietärem oder GPL-lizenziertem.

• Ähnlichkeit prüfen: Bei auffällig spezifischem Code (komplexe Algorithmen, Nischen-Libs) Google-Search nach exakten Zeilen.
• Lizenz-Kompatibilität: Neue Dependencies mit npm view <pkg> license / PyPI prüfen — passt GPL/AGPL zu deinem Projekt?
• Attribution: Falls der Code klar aus OSS-Quellen stammt: Original-Lizenz + Link im Comment?
• Company-Policy: Erlaubt deine Firma KI-generierten Code überhaupt? Einige Branchen (Finance, Medizin) haben strenge Regeln.

5. Tests

Code ohne Tests ist im besten Fall ein glücklicher Zufall.

• Hat das LLM Tests generiert? Falls ja: testen sie nur den Happy Path oder auch Fehlerfälle?
• Realistische Fixtures: Test-Daten decken Edge-Cases ab (nicht nur user = "Alice", id = 1)?
• Assertions sinnvoll: Prüfen die Tests wirklich das Verhalten oder nur assert result is not None?
• Test-Coverage: Neue Funktionen/Klassen haben mindestens einen Unit-Test? Kritische Pfade haben Integration-Tests?
• Tests laufen grün: Nicht blind vertrauen — pytest / npm test lokal ausführen und Output prüfen.
• Regressions-Tests: Bei Bugfixes — Test der vorher rot war, jetzt grün?

6. Lesbarkeit & Wartbarkeit

Generierter Code ist oft syntaktisch korrekt, aber unleserlich oder stilfremd.

• Passt zum Projekt-Stil? Gleiche Naming-Conventions, gleiche Dateistruktur, konsistente Patterns?
• Verständlich für das Team? Keine obskuren One-Liner, keine unnötigen Nested-Loops, sprechende Variablennamen?
• Kommentare sinnvoll? LLMs schreiben oft Redundanz-Kommentare (# Increment counter) — brauchbare Erklärungen behalten, Rest raus.
• Keine Over-Engineering: Braucht es wirklich eine Abstraktion für Single-Use-Code? Keine Factory-Pattern für 2 Zeilen.
• Keine Code-Duplizierung: Hat das LLM denselben Block mehrfach kopiert statt zu refactorn?

---

Die 3 häufigsten Fehler beim Umgang mit KI-Code

1. Blind mergen ohne lokalen Test-Lauf

„Sieht gut aus" ist kein Beweis. Jeder generierte Code-Block muss mindestens einmal lokal ausgeführt werden — LLMs halluzinieren subtile Syntax-Fehler, die nur zur Runtime sichtbar werden.

2. Sicherheit nachträglich „dazudenken"

KI-Code nutzt Demo-Defaults: cors(*), debug=True, kein Auth-Check. Vor dem Commit jeden neuen Endpoint/Form/DB-Zugriff explizit auf Input-Validierung und Berechtigungen prüfen.

3. Dependencies blind installieren

LLMs schlagen oft veraltete oder unnötige Pakete vor. Vor npm install / pip install: Paket auf npm/PyPI prüfen (letztes Update? Stars? bekannte Vulns?), nur das Nötigste installieren.

---

Passt dazu

Für die praktische Absicherung schau in den Prompt-Hardening-Guide (sichere LLM-Integration), die OWASP LLM Top 10 (Risiko-Übersicht) und das Claude Code Toolkit (sichere Entwicklung mit AI-Assistants). Wer mit Model Context Protocol arbeitet, findet in MCP absichern die passende Server-Härtung.

Diskussion und konkrete Code-Reviews laufen in der FlowKI-Community.