KI-gestütztes Code-Review als Ergänzung zum Team

1. Was KI-gestütztes Code-Review wirklich ist

KI-gestütztes Code-Review bedeutet, dass ein Sprachmodell wie Claude einen Diff oder Pull Request liest und automatisch Auffälligkeiten kommentiert, bevor ein menschlicher Reviewer den Code überhaupt öffnet. Der Unterschied zu klassischer statischer Analyse liegt im Kontextverständnis: Ein Linter wie PHPStan prüft Typen und Signaturen gegen feste Regeln, während ein Sprachmodell den Code im Zusammenhang mit Nachbardateien, Namenskonventionen und dem sichtbaren Zweck einer Änderung bewertet. Das erlaubt Kommentare, die über reine Syntaxfehler hinausgehen, etwa den Hinweis, dass eine neue Methode denselben Zweck wie eine bereits vorhandene Klasse erfüllt.

Wichtig ist die Einordnung als zusätzliche Prüfebene, nicht als Ersatz. In einem mehrstufigen Modell prüfen zuerst Linter und Type-Checker rein mechanische Regelverstöße, danach ein KI-Review-Schritt semantisch naheliegende Probleme, und erst danach bewertet ein Mensch fachliche Korrektheit und Architekturentscheidungen. Diese Reihenfolge spart Zeit, weil offensichtliche Fehler nicht mehr in der menschlichen Prüfschleife landen, verändert aber nichts daran, dass die Freigabeverantwortung für eine Änderung weiterhin bei einer Person liegt, die den Code versteht und für seine Konsequenzen einsteht.

2. Der Review-Workflow: KI als erste Instanz vor dem Menschen

Der praktische Nutzen von KI-Review entsteht durch die Position im Workflow: Sie läuft automatisch bei jedem Pull Request, nicht erst auf Anfrage eines Entwicklers. Sobald ein Branch gepusht wird, generiert eine CI-Pipeline den Diff gegen den Zielbranch und schickt ihn an Claude Code im nicht interaktiven Modus. Die Rückmeldung erscheint als Kommentar im Pull Request, bevor überhaupt ein Mensch zugewiesen wird. Entwickler beheben offensichtliche Probleme direkt, ohne eine Review-Runde mit einem Kollegen zu verbrauchen.

Der Effekt zeigt sich vor allem bei kleineren, aber häufigen Fehlern: fehlende Null-Prüfungen, inkonsistente Exception-Behandlung, vergessene Übersetzungsfunktionen in Templates oder Rückgabetypen, die nicht zur PHPDoc-Annotation passen. Werden diese Punkte schon vor der menschlichen Prüfung behoben, verkürzt sich der eigentliche Review auf die Fragen, die wirklich Fachwissen erfordern. Wichtig ist, den KI-Schritt als Gate vor dem Reviewer-Zuweisen zu platzieren, nicht parallel dazu, sonst entsteht doppelte statt sequenzielle Entlastung.

3. Starke Seiten: Stilkonsistenz, mechanische Bugs, Sicherheitsmuster

KI-Review ist zuverlässig bei Mustern, die sich aus dem Code selbst ableiten lassen, ohne Wissen über die Fachlichkeit dahinter. Dazu zählen Verstöße gegen dokumentierte Coding-Standards, etwa fehlende Constructor Property Promotion, assert() statt sauberer Typprüfung, das @-Zeichen zur Fehlerunterdrückung oder addFieldToFilter() mit einem rohen Integer statt der ['eq' => $value]-Array-Form. Solche Verstöße sind in jedem Magento-Projekt mit dokumentierten Konventionen eindeutig erkennbar, weil die Regel unabhängig vom konkreten Geschäftsfall gilt.

Ebenso gut erkennt ein Sprachmodell offensichtliche Logikfehler wie vertauschte Vergleichsoperatoren, fehlende Breaks in Switch-Statements, ungeprüfte Array-Zugriffe oder Ressourcen, die nicht geschlossen werden. Bei Sicherheitsmustern zeigt sich der Vorteil gegenüber reinen Linter-Regeln: Ein Modell erkennt unsanitisierte Benutzereingaben in einer Datenbankabfrage auch dann, wenn die konkrete Funktion nicht auf einer bekannten Blacklist steht, weil es das Muster der Datenherkunft und -verwendung versteht. Diese Stärke gilt für jede Änderung, unabhängig von der Größe des Diffs.

4. Grenzen: Business-Logik, Architektur und Domänenwissen

Sobald die Korrektheit einer Änderung vom fachlichen Kontext abhängt, stößt KI-Review an klare Grenzen. Ein Beispiel: Eine Preisberechnung, die für ein bestimmtes Kundensegment einen Rabatt anders staffelt als für andere, lässt sich syntaktisch fehlerfrei implementieren und trotzdem fachlich falsch sein, weil sie eine Vereinbarung mit einem Kunden nicht korrekt abbildet. Ein Sprachmodell kennt diese Vereinbarung nicht und kann sie auch nicht aus dem Code allein ableiten, selbst wenn Variablennamen und Kommentare Hinweise geben.

Ähnlich verhält es sich bei Architekturentscheidungen: Ob ein neuer Service als eigenständiges Modul oder als Erweiterung eines bestehenden Plugins sinnvoller ist, hängt von der geplanten Weiterentwicklung des Shops ab, von Team-Erfahrung und von Aufwand für spätere Migrationen. Diese Abwägung erfordert Wissen über Roadmap und historische Entscheidungen, das selten vollständig im Repository dokumentiert ist. Ein KI-Review-Kommentar, der eine Architekturentscheidung unkommentiert als „sauber gelöst" bewertet, kann falsches Vertrauen erzeugen, wenn die eigentliche Abwägung nie stattgefunden hat.

5. Claude Code als Reviewer im Entwickleralltag

In der Praxis lässt sich Claude Code im nicht interaktiven Modus (-p) direkt in bestehende Skripte einbinden, ohne dass ein Entwickler manuell eine Sitzung startet. Für Review-Zwecke ist ein reiner Lesemodus sinnvoll, der explizit keine Datei-Änderungen zulässt, damit der Review-Schritt nicht versehentlich Code modifiziert, während er eigentlich nur kommentieren soll. Der Plan-Modus mit eingeschränkten Berechtigungen ist dafür genau richtig konfiguriert.

#!/usr/bin/env bash
# Run a read-only review pass on the current PR diff with Claude Code
set -euo pipefail

# Generate the diff against the target branch
git diff origin/main...HEAD > /tmp/pr.diff

# Headless review run in plan-only mode (no file edits allowed)
claude -p "Review this diff for style violations, obvious bugs, missing \
error handling and PHPStan level 5 issues. Do not comment on business \
logic correctness, only on mechanical and stylistic problems. List \
findings with file, line and severity (low, medium, high)." \
  --permission-mode plan < /tmp/pr.diff > /tmp/review-findings.txt

cat /tmp/review-findings.txt

Entscheidend ist die restriktive Berechtigungskonfiguration für diesen speziellen Anwendungsfall. Ein Review-Lauf darf lesen, Diffs erzeugen und Analyse-Tools wie PHPStan aufrufen, aber weder Dateien schreiben noch Commits erzeugen oder pushen. Diese Trennung verhindert, dass ein für Review gedachter Prozess versehentlich produktive Änderungen vornimmt, und macht das Verhalten des Bots für das gesamte Team nachvollziehbar und auditierbar.

{
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Read(**)",
      "Grep(**)",
      "Bash(git diff:*)",
      "Bash(bin/analyse:*)"
    ],
    "deny": [
      "Edit(**)",
      "Write(**)",
      "Bash(git push:*)",
      "Bash(git commit:*)"
    ]
  }
}

6. Automatisierte Reviews in CI/CD-Pipelines

Damit KI-Review tatsächlich vor jedem menschlichen Blick greift, muss der Schritt in der CI-Pipeline verankert sein, nicht als optionales lokales Werkzeug. Ein typischer Ablauf: Bei jedem Push auf einen Feature-Branch erzeugt ein CI-Job zunächst den Diff, ruft Claude Code im JSON-Ausgabeformat auf und speichert die strukturierten Befunde als Artefakt. Ein zweiter Schritt liest diese Befunde und postet sie als Inline-Kommentare direkt an den betroffenen Codezeilen im Pull Request, ähnlich wie es Linter-Integrationen bereits für PHPStan oder ESLint tun.

name: ai-review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: read
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      # Generate the diff against the PR base branch
      - name: Generate diff
        run: git diff origin/${{ github.base_ref }}...HEAD > pr.diff

      # Headless review run in plan-only mode, no file edits allowed
      - name: Run Claude Code review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          claude -p "Review this diff for style and obvious bugs only." \
            --permission-mode plan \
            --output-format json < pr.diff > review-findings.json

      # Post filtered findings as inline PR comments
      - name: Post inline comments
        run: node post-ai-review.js
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}

Wichtig ist eine Filterung nach Konfidenz vor dem Posten: Befunde mit niedriger Sicherheit sollten nicht als Kommentar erscheinen, weil eine hohe Zahl unsicherer Hinweise die Akzeptanz im Team senkt und echte Probleme in der Menge untergehen. Ein Merge-Gate, das den Merge bei hohen Befunden komplett blockiert, ist nur für eindeutig mechanische Kategorien wie fehlende Fehlerbehandlung sinnvoll, nicht für Kommentare zu Architektur oder Stil, die immer eine menschliche Einschätzung brauchen.

// post-ai-review.js: post Claude Code findings as inline PR review comments
const { Octokit } = require("@octokit/rest");
const fs = require("fs");

const findings = JSON.parse(fs.readFileSync("review-findings.json", "utf8"));
const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });

async function postComments() {
  const [owner, repo] = process.env.GITHUB_REPOSITORY.split("/");
  const pullNumber = Number(process.env.PR_NUMBER);

  for (const finding of findings) {
    if (finding.severity === "low") continue; // skip low-confidence noise

    await octokit.pulls.createReviewComment({
      owner,
      repo,
      pull_number: pullNumber,
      commit_id: process.env.HEAD_SHA,
      path: finding.file,
      line: finding.line,
      body: `**[AI Review, ${finding.severity}]** ${finding.message}\n\nPlease verify manually before merging.`,
    });
  }
}

postComments().catch((err) => {
  console.error("Failed to post AI review comments:", err);
  process.exit(1);
});

7. Verantwortung und Accountability behalten

Der wichtigste organisatorische Punkt bei KI-Review ist, dass die Freigabeentscheidung eines Pull Requests weiterhin bei einer benannten Person liegt. Ein Kommentar von Claude Code ist ein Hinweis, keine Freigabe. Wird ein KI-Review-Durchlauf ohne Beanstandung als ausreichende Grundlage für ein Merge akzeptiert, verschiebt sich Verantwortung unbemerkt von einer Person auf ein Werkzeug, das für fachliche Korrektheit gar nicht zuständig ist. Diese Verschiebung fällt erst auf, wenn ein Fehler produktiv wird und niemand ihn eindeutig hätte verhindern können, weil formal niemand ihn geprüft hat.

Ein praktikabler Weg ist, KI-Kommentare im Pull Request klar als solche zu kennzeichnen, etwa mit einem eigenen Bot-Namen und einem Hinweis im Kommentartext, dass die Aussage nicht auf Fachwissen über die Domäne beruht. Zusätzlich sollte die Merge-Regel weiterhin mindestens eine menschliche Genehmigung verlangen, unabhängig davon, ob der KI-Schritt ohne Befunde durchgelaufen ist. So bleibt die KI ein Filter, der Reviewzeit spart, ohne dass die eigentliche Entscheidungsinstanz aus dem Prozess verschwindet.

8. Review-Prompts und Konfiguration gezielt einsetzen

Ein generischer Prompt wie „Review this code" liefert selten brauchbare Ergebnisse, weil das Modell dann meist oberflächliche stilistische Anmerkungen macht, statt gezielt nach den Fehlerklassen zu suchen, die im jeweiligen Projekt tatsächlich relevant sind. Deutlich wirksamer ist ein Prompt, der explizit auf dokumentierte Projektregeln verweist, etwa auf die in CLAUDE.md hinterlegten verbotenen Muster, und der ausdrücklich ausschließt, worüber das Modell keine verlässliche Aussage treffen kann, etwa Business-Logik-Korrektheit.

In lokalen Entwicklungsumgebungen lässt sich derselbe Ansatz als Pre-Commit-Hook nutzen, der einen Commit blockiert, wenn hochgradig sichere Befunde auftreten, aber unsichere Hinweise nur protokolliert statt den Workflow zu unterbrechen. Diese Abstufung verhindert, dass Entwickler den Hook nach kurzer Zeit wegen zu vieler Fehlalarme deaktivieren, was in der Praxis der häufigste Grund ist, warum automatisierte Review-Gates nach wenigen Wochen ungenutzt bleiben.

#!/usr/bin/env python3
"""Pre-commit hook: block the commit on high-severity AI review findings."""
import json
import subprocess
import sys


def get_staged_diff() -> str:
    """Return the staged diff as a string."""
    result = subprocess.run(
        ["git", "diff", "--cached"], capture_output=True, text=True, check=True
    )
    return result.stdout


def run_ai_review(diff: str) -> list:
    """Send the diff to Claude Code in headless mode and parse findings."""
    prompt = (
        "Review this diff for obvious bugs, missing null checks and "
        "forbidden patterns like assert() or @ error suppression. "
        "Return findings as a JSON array with severity: low, medium, high."
    )
    result = subprocess.run(
        ["claude", "-p", prompt, "--output-format", "json"],
        input=diff, capture_output=True, text=True, check=True,
    )
    return json.loads(result.stdout).get("findings", [])


def main() -> int:
    diff = get_staged_diff()
    if not diff.strip():
        return 0
    findings = run_ai_review(diff)
    high = [f for f in findings if f.get("severity") == "high"]
    for f in high:
        print(f"[HIGH] {f['file']}:{f['line']} {f['message']}", file=sys.stderr)
    return 1 if high else 0


if __name__ == "__main__":
    sys.exit(main())

9. KI-Review vs. menschliches Review im Vergleich

Die folgende Übersicht ordnet typische Review-Aufgaben danach ein, welche Kombination aus KI- und menschlicher Prüfung jeweils das verlässlichste Ergebnis liefert. Sie zeigt, dass es selten um ein Entweder-oder geht, sondern um die richtige Reihenfolge und Aufgabenteilung zwischen beiden Ebenen.

Der Trend in der Tabelle ist konsistent: Je mechanischer und regelbasierter eine Prüfung ist, desto zuverlässiger übernimmt sie ein Sprachmodell. Je stärker eine Entscheidung von Geschäftskontext, Teamhistorie oder langfristiger Wartbarkeit abhängt, desto klarer bleibt sie eine menschliche Aufgabe, bei der KI-Kommentare höchstens als zusätzlicher Denkanstoß dienen.

10. Zusammenfassung

KI-gestütztes Code-Review ist am wirksamsten als vorgeschaltete Prüfebene, die mechanische und stilistische Probleme abfängt, bevor ein menschlicher Reviewer den Code sieht. Claude Code erkennt zuverlässig Verstöße gegen dokumentierte Coding-Standards, offensichtliche Logikfehler und viele Sicherheitsmuster, weil diese Kategorien sich aus dem Code selbst ableiten lassen. Sobald Korrektheit von Geschäftskontext, Kundenabsprachen oder langfristigen Architekturentscheidungen abhängt, bleibt die Einschätzung eine menschliche Aufgabe, die kein Sprachmodell aus dem Diff allein zuverlässig treffen kann.

Für den produktiven Einsatz zählt vor allem die technische Einbettung: restriktive Berechtigungen für den Review-Bot, klare Kennzeichnung von KI-Kommentaren, eine Filterung nach Konfidenz vor dem Posten und eine Merge-Regel, die weiterhin mindestens eine menschliche Freigabe verlangt. Wird diese Struktur eingehalten, sinkt die Zeit, die Teams mit offensichtlichen Fehlern verbringen, ohne dass Verantwortung für fachliche Korrektheit unbemerkt an ein Werkzeug abgegeben wird, das dafür nicht zuständig ist.

11. FAQ: KI-gestütztes Code-Review als Ergänzung zum Team