„Nur beratend“, sagte der Review-Bot. 3 von 4 waren echte Bugs.

Was an der Einstufung schiefgeht

In einem PR waren alle vier Hinweise eines AI-Review-Bots als „beratend“ eingestuft. Drei davon waren echte Defekte. Nicht Stilfragen, nicht bloße Geschmacksunterschiede, sondern Verhalten, das unter bestimmten Bedingungen falsch war.

Das ist kein Argument gegen AI Code Review. Im Gegenteil: Der Bot hat die Probleme gefunden. Das Problem entstand erst durch die Einordnung im Code Review Prozess: „beratend“ wurde wie „kann man ignorieren“ gelesen.

Ich halte das für eine gefährliche Verkürzung. Die Schwere-Einstufung eines Review Bot sagt vor allem etwas darüber aus, wie eindeutig und auffällig ein Fund im Code wirkt. Sie sagt nicht zuverlässig voraus, welchen Schaden ein Fehler später verursacht.

Ein stiller Teilstring-Fehler

Ein typisches Beispiel ist eine Prüfung auf eine CSS-Eigenschaft in einem String. Angenommen, eine Funktion soll feststellen, ob ein Style-Block bereits color: enthält:

function hasColorDeclaration(styles: string): boolean {
  return styles.includes('color:');
}

Auf den ersten Blick ist das plausibel. Der Test trifft aber auch bei background-color: zu. Die Funktion meldet dann, dass eine color:-Deklaration existiert, obwohl nur eine Hintergrundfarbe gesetzt wurde.

hasColorDeclaration('background-color: blue;')
// true, obwohl keine color-Deklaration vorhanden ist

Ein Bot kann diesen Fund niedrig priorisieren: kein Crash, keine offensichtliche Sicherheitslücke, keine sichtbare Änderung im üblichen Pfad. Trotzdem ist es ein Defekt. Seine Kosten hängen davon ab, wo die Funktion eingesetzt wird: Vielleicht wird eine notwendige Deklaration ausgelassen. Vielleicht erscheint der Fehler nur bei bestimmten Eingaben. Vielleicht wird er erst nach mehreren Änderungen sichtbar.

Die robustere Lösung hängt vom erlaubten CSS-Ausschnitt ab. Für einen begrenzten Fall kann ein regulärer Ausdruck die Eigenschaft am Anfang oder nach einem Semikolon suchen:

function hasColorDeclaration(styles: string): boolean {
  return /(?:^|;)\s*color\s*:/.test(styles)
}

Wichtiger als die konkrete Implementierung ist die Review-Frage: Ist die Annahme über den String wirklich korrekt? Genau solche Annahmen werden leicht als „beratend“ markiert, obwohl sie fachlich relevant sind.

Lautstärke ist nicht Schaden

Bots stufen nach Lautstärke ein. Laut sind Muster wie fehlende Fehlerbehandlung an einer klar erkennbaren Stelle, riskante API-Nutzung oder direkt erreichbarer fehlerhafter Code. Solche Hinweise verdienen Aufmerksamkeit.

Stille Fehler sind anders. Sie benötigen oft eine bestimmte Eingabe, eine Reihenfolge von Zuständen oder eine implizite Annahme über Daten. Sie sehen lokal klein aus. Ihr potenzieller Schaden kann aber groß sein, weil sie lange unentdeckt bleiben oder falsche Ergebnisse produzieren, ohne einen Alarm auszulösen.

Deshalb kann die Korrelation zwischen Bot-Schwere und echten Kosten sogar negativ sein: Ein auffälliger Fehler wird schnell entdeckt und behoben. Ein unauffälliger Fehler gelangt eher in Produktion und bleibt dort länger wirksam. Das ist keine feste Regel, aber eine realistische Möglichkeit, die ein Team in seiner Triage berücksichtigen sollte.

Coding Agents verschärfen das Thema. Sie erzeugen mehr Änderungen in kürzerer Zeit. Damit steigt nicht automatisch die Zahl schwerer Fehler, aber die Zahl der Stellen, an denen kleine Annahmen überprüft werden müssen. Ein Label darf diese Prüfung nicht ersetzen.

Eine pragmatische Triage-Regel

Meine Regel lautet: Einstufung bestimmt die Reihenfolge, nicht die Behandlung. Jeder Fund bekommt eine bewusste Entscheidung.

Für den Code Review Prozess reicht eine kurze Einordnung pro Hinweis:

Die Bot-Schwere hilft dabei, die Reihenfolge festzulegen. Rote Hinweise zuerst, dann die beratenden. Aber auch ein beratender Fund endet nicht ungelesen. Er endet mit „beheben“, „nicht relevant“ oder „später“, jeweils mit kurzer Begründung.

Das kostet Zeit. Es verhindert aber, dass Teams ausgerechnet die leisen Defekte systematisch aussortieren. Ein guter Review Bot erweitert die Aufmerksamkeit des Teams. Er nimmt dem Team nicht die Verantwortung ab, die Relevanz eines Fundes im konkreten Kontext zu bewerten.

Lest ihr die 'beratenden' Funde eures Review-Bots noch?