Das Review-Problem

Der Standardrat für KI-generierten Code lautet „prüfe ihn sorgfältig.”

Dieser Rat ist korrekt und im großen Maßstab nutzlos.

Ein Entwickler, der KI-Ausgaben prüft, erkennt Probleme, wenn er aufmerksam ist, mit der Domäne vertraut ist und nicht unter Zeitdruck steht. Unter allen anderen Bedingungen – also den meisten Bedingungen – rutschen Dinge durch.

Ein KI-Reviewer, der KI-generierte Probleme erkennen soll, ist noch weniger zuverlässig. Man bittet ein probabilistisches System, die Ausgabe eines anderen probabilistischen Systems zu verifizieren. Die Fehlermodi korrelieren.

Das einzige Muster, das skaliert, ist deterministisches Enforcement. Regeln, die bei jedem Commit geprüft werden, die nicht durch Ermüdung oder Optimismus außer Kraft gesetzt werden können, und die den Build fehlschlagen lassen, wenn sie verletzt werden.

Was deterministisch bedeutet

Deterministisch bedeutet, dass die Prüfung jedes Mal dasselbe Ergebnis liefert, unabhängig davon, wer sie ausführt oder wann.

  • Eine Linter-Regel ist deterministisch.
  • Eine Typprüfung ist deterministisch.
  • Eine Boundary-Import-Beschränkung ist deterministisch.
  • Ein Contract Test ist deterministisch.
  • Die Aufmerksamkeitsspanne eines menschlichen Reviewers ist es nicht.
  • Die Bewertung eines LLM ist es nicht.

Diese Unterscheidung ist in KI-generierten Codebases wichtiger, weil das Volumen des generierten Codes das übersteigt, was jedes Team manuell prüfen kann. Man kann Review nicht linear mit der Generierungsgeschwindigkeit skalieren. deterministic checks lassen sich trivial skalieren.

Der Leitplanken-Stack

Für KI-generierte Codebases hat der Leitplanken-Stack vier Schichten:

Schicht 1: Typsystem

Das Typsystem ist die erste Leitplanke. Strikte Typen fangen eine Fehlerklasse ab, die kein Review-Prozess – weder menschlich noch KI – konsistent erkennt:

  • Null-Verletzungen
  • Interface-Inkompatibilitäten
  • Fehlende Fallbehandlung
  • Falsche Argumenttypen

Wenn das Projekt TypeScript verwendet, ist strict: true nicht verhandelbar. Wenn es eine Sprache ohne starkes Typsystem verwendet, füge man eines über Tooling hinzu oder wähle eine andere Sprache.

Schicht 2: Architekturregeln

Architekturregeln erzwingen Grenz-Disziplin:

  • Kein Screen importiert aus den Interna eines anderen Screens.
  • Keine Domänenlogik importiert Infrastruktur direkt.
  • Kein Teil des Systems umgeht den Composition Root für Abhängigkeitszugriff.
  • Kein Anbieter-SDK erscheint außerhalb seines Adapter-Modules.

Werkzeuge wie Semgrep, ArchUnit, dependency-cruiser oder benutzerdefinierte ESLint-Regeln können dies statisch erzwingen. Der Schlüssel ist, dass sie in CI laufen und den Build fehlschlagen lassen. Eine Warnung, die Entwickler ignorieren können, ist keine Leitplanke.

Schicht 3: Contract Tests

Contract Tests verifizieren, dass Module ihre Interfaces erfüllen, ohne das gesamte System auszuführen:

  • Der Auth-Adapter erfüllt das Auth-Interface.
  • Der Analytics-Adapter erfüllt das Analytics-Interface.
  • Der Storage-Adapter erfüllt das Storage-Interface.

Diese laufen schnell, testen Integrationsgrenzen und fangen den spezifischen Fehlermodus ab, bei dem KI-generierter Code die Typsignatur erfüllt, aber den verhaltensbasierten Contract verletzt.

Schicht 4: Deterministic Integration Checks

Auf der Integrationsebene verifizieren Prüfungen systemweite Eigenschaften:

  • Der Composition Root löst alle Abhängigkeiten ohne Laufzeitfehler auf.
  • Der Abhängigkeitsgraph enthält keine Zyklen.
  • Alle erforderlichen Umgebungsvariablen sind deklariert.
  • Die Konfiguration ist zur Build-Zeit gültig, nicht erst zur Laufzeit.

Semgrep für KI-generierten Code

Semgrep verdient besondere Erwähnung, weil es hervorragend darin ist, Architekturregeln als Code auszudrücken:

  • Pattern-Matching auf AST-Struktur, kein String-Matching.
  • Benutzerdefinierte Regeln pro Projekt, nicht nur generisches Linting.
  • Schnell genug, um bei jedem Commit zu laufen.
  • Ausdrucksstark genug, um Boundary-Verletzungen zu kodieren.

Ein Team, das KI-Generierung intensiv nutzt, sollte ein Semgrep-Regelwerk pflegen, das seine architektonischen Grenzen kodiert. Wenn die KI Code generiert, der eine Grenze verletzt, schlägt der Build vor dem Merge fehl. Keine menschliche Aufmerksamkeit erforderlich.

Es geht hier nicht darum, Bugs in KI-Ausgaben zu finden. Es geht darum, strukturelle Verletzungen unmöglich zu mergen, unabhängig davon, wie sie entstanden sind.

Was KI-Code-Review tatsächlich erkennt

KI-Code-Review-Werkzeuge sind nützlich für:

  • Stilkonsistenz
  • Dokumentationslücken
  • Offensichtliche Logikfehler
  • Vorschläge alternativer Ansätze

KI-Code-Review-Werkzeuge sind unzuverlässig für:

  • Architektonische Boundary-Verletzungen
  • Subtile Kopplung, die modulübergreifend eingeführt wird
  • Verhaltensbasierte Contract-Verletzungen
  • Sicherheitseigenschaften, die Gesamtsystem-Reasoning erfordern

Der Fehlermodus ist nicht, dass KI-Review gelegentlich Dinge übersieht. Der Fehlermodus ist, dass es Dinge unvorhersehbar übersieht und man nicht wissen kann, wann es etwas übersehen hat. Deshalb kann es deterministisches Enforcement nicht ersetzen – nur ergänzen.

Die Wirtschaftlichkeit

Deterministische Leitplanken sind günstig im Betrieb und anfänglich teuer in der Erstellung.

Das Schreiben der Architekturregeln dauert einige Tage. Die Pflege der Semgrep-Konfiguration erfordert fortlaufende Aufmerksamkeit. Das Einrichten von Contract Tests erfordert, zuerst Interfaces zu definieren.

Aber sobald sie existieren, laufen sie bei jedem Commit zu nahezu null Grenzkosten. Sie werden nicht müde. Sie überspringen keine Prüfungen am Freitagnachmittag. Sie beugen sich weder Seniorität noch sozialem Druck.

Für KI-generierte Codebases, in denen das Codevolumen hoch und die Generierungsgeschwindigkeit schnell ist, ist dieses wirtschaftliche Profil entscheidend. Die Alternative – menschliches Review zu skalieren, um mit der KI-Generierungsgeschwindigkeit Schritt zu halten – ist nicht tragfähig.

Die Verbindung zu AI-native-Architektur

Ich habe über dieses umfassendere Muster in Stanford CS146S Is Right About AI Coding — The Missing Subject Is Architecture geschrieben. Deterministische Leitplanken sind der Enforcement-Mechanismus, der ersetzbare Architektur real macht.

Ohne Leitplanken sind architektonische Grenzen nur Absichtserklärungen. Mit ihnen sind Grenzen strukturell. Der Unterschied zwischen „wir versuchen, Module isoliert zu halten” und „der Build schlägt fehl, wenn Module-Isolation verletzt wird” ist der Unterschied zwischen Architektur, die KI-Geschwindigkeits-Iteration überlebt, und Architektur, die darunter zusammenbricht.

Der moderne Softwareentwickler braucht nicht nur KI-Werkzeugkompetenz. Er braucht einen Leitplanken-Stack, der KI-generierten Code strukturell sicher macht, um ihn mit hoher Geschwindigkeit auszuliefern.

FAQ

Was ist das beste Werkzeug zur Durchsetzung von Architekturregeln bei KI-generiertem Code?

Semgrep ist die flexibelste Option für benutzerdefinierte Architekturregeln. Es unterstützt Pattern-Matching gegen AST-Struktur, läuft schnell in CI und lässt Teams projektspezifische Grenzen kodieren. Für JavaScript-/TypeScript-Projekte sind dependency-cruiser und benutzerdefinierte ESLint-Regeln ebenfalls wirksam.

Kann KI-Code-Review menschliches Code-Review ersetzen?

Nein. KI-Code-Review ergänzt menschliches Review bei Stil und Dokumentation, ist aber unzuverlässig für architektonisches Boundary-Enforcement und Sicherheitseigenschaften. deterministic checks (Typsystem, Linter, Architekturregeln, Contract Tests) sind der einzige skalierbare Ersatz für aufmerksamkeitsabhängiges Review.

Wie richtet man Leitplanken ein, ohne das Team auszubremsen?

Man beginnt mit dem Typsystem (strikter Modus, keine Ausnahmen). Dann fügt man Architekturregeln für die drei risikoreichsten Grenzen hinzu. Dann fügt man Contract Tests für externe Integrationen hinzu. Jede Schicht benötigt einen Tag zur Einrichtung und läuft in Sekunden. Die Verlangsamung kommt durch Verletzungen, nicht durch die Prüfungen selbst.

Was ist der Unterschied zwischen einer Leitplanke und einem Linter?

Ein Linter schlägt Verbesserungen vor. Eine Leitplanke lässt den Build fehlschlagen. Die Unterscheidung ist Enforcement. In KI-generierten Codebases werden Vorschläge im großen Maßstab ignoriert, weil das Volumen zu hoch für konsistente manuelle Aufmerksamkeit ist. Nur Build-Fehler garantieren Einhaltung.