Die Pipeline, in der eine zweite KI den Fix der ersten widerlegen muss

Wer schon einmal einen KI-Agenten Code reviewen ließ, kennt das: Fremden Code zerlegt er ziemlich zuverlässig. Lässt man ihn aber den Code reviewen, den er gerade selbst geschrieben hat, wird er seltsam nachsichtig. Zurück kommt "die Implementierung entspricht der Intention", und wenn man es tatsächlich ausführt, ist der Bug immer noch da.

Kein Wunder. Innerhalb desselben Modells und desselben Kontexts begeht das Modell beim Review denselben Denkfehler, den es schon beim Schreiben begangen hat. Es ist eine Struktur, in der jemand die eigene Schlussfolgerung noch einmal selbst absegnet; das ist kein Review, sondern eher ein Nachsprechen.

Also habe ich die Begutachtung nach außen verlagert. Den Code, den Claude gefixt hat, gebe ich an Codex weiter, mit genau einem Auftrag: "Nimm an, dieser Fix ist falsch, und widerlege ihn."

Drei Runden in Folge kam ein tieferer Bug zum Vorschein

Den Wert dieser Schleife habe ich zum ersten Mal bei einem Logout-Bug wirklich gespürt. Das Symptom war simpel: Manchmal loggt der Logout-Button nicht aus. Claude fand die Ursache und fixte sie, und beim reinen Lesen wirkte der Code plausibel. Ich hätte beinahe gemergt.

Ich ließ Codex den Fix widerlegen, und in Runde eins kam diese Antwort: Der Fix selbst sei korrekt, aber der Redirect der Auth-Seite fange den Ablauf ab, bevor dieser Codepfad überhaupt erreicht wird; der Fix bekomme nie die Gelegenheit zu laufen. Der gefixte Code war toter Code.

Ich fixte auch den Redirect und ließ erneut widerlegen. In Runde zwei kam wieder etwas. Diesmal war das Processing-Flag das Problem, das doppelte Ausführung verhindern sollte. Bei bestimmtem Timing macht genau diese Guard den Logout-Request zu einem no-op, der gar nichts bewirkt. Erst in Runde drei kam die Antwort "ich finde nichts mehr zu widerlegen", und erst dann habe ich gemergt.

Alle drei Runden betrafen Code, der das Self-Review bestanden hatte. Und in allen drei Runden hat der Widerleger die Fehler gefunden, weil er nicht fragte "sieht der Code gut aus?", sondern "gibt es ein Szenario, in dem diese Behauptung zusammenbricht?".

Das Muster wiederholte sich auch danach. Bei einem Server-Fix, der zwei Runden Self-Review überstanden hatte, fing der Cross-Check einen fehlenden Wert in einer DB-Constraint ab, und eine Migration kam hinzu. Bei einem Fix an der Retry-Logik schickte der Widerleger einen Grenzfall mit Blocker-Urteil zurück, in dem eine bestimmte Timeout-Antwort als permanenter Fehler fehlklassifiziert wurde. Alles Dinge, die plausibel genug waren, um beinahe durchzurutschen.

Kein Review, sondern eine Widerlegung

Das Wichtigste am Prompt-Design ist das Framing. Sagt man "review das mal", liefert das Modell eine unverbindliche Antwort, halb Lob, halb Kleinkram. Sagt man "nimm an, dieser Fix ist falsch, und widerlege ihn; lass ihn nur durch, wenn die Widerlegung scheitert", ändert sich die Haltung. Das Durchlassen ist dann nicht mehr der Default, sondern die Folge einer gescheiterten Widerlegung.

Dazu kommen drei weitere Auflagen.

1. Beweisformat erzwingen. Jeder Befund muss Datei und Zeilennummer nennen, plus ein Reproduktionsszenario, in dem der Defekt tatsächlich hochgeht. "Diese Stelle sieht riskant aus" wird nicht akzeptiert. Kommt kein Szenario zustande, ist dieser Verdacht kein Befund, sondern abgewiesen. Tatsächlich passiert es ziemlich oft, dass der Widerleger seinen eigenen Verdacht selbst widerlegt und fallen lässt; genau das ist der zentrale Mechanismus, der Fehlalarme herausfiltert.
2. Das Urteil als Stufe entgegennehmen. Bestanden / bestanden nach kleiner Korrektur / blockiert, drei Stufen reichen. Mit Stufen vermischen sich der Zustand "es gibt Anmerkungen, aber mergen ist ok" und der Zustand "mergen verboten" nicht mehr.
3. In unabhängigem Kontext laufen lassen. Der Widerleger bekommt nur den diff und den relevanten Code. Nicht das Gespräch aus dem Arbeitsprozess und nicht die Erzählung, warum so gefixt wurde. In dem Moment, in dem man die Erzählung teilt, färbt derselbe Denkfehler auch auf den Widerleger ab.

Noch ein Betriebstipp: Der Widerleger läuft read-only. Gibt man ihm das Recht, Code zu ändern, will er statt anzumerken lieber selbst fixen, und dann steht wieder die Frage im Raum, wer diesmal diesen Fix verifiziert. Die Rolle bleibt auf die Begutachtung fixiert, die Korrektur geht zurück an den ursprünglichen Bearbeiter.

Wann die Schleife laufen soll

Nicht bei jeder Änderung läuft diese Schleife. Für einen Tippfehler-Fix den Widerleger zu rufen ist Verschwendung. Unbedingt läuft sie bei Änderungen, die sich schwer rückgängig machen lassen. DB-Migrationen, Datenlöschungen, Payment- und Auth-Pfade gehören dazu. Auch Änderungen, an denen die Behauptung "gefixt" hängt, sind Kandidaten. Ein Bugfix braucht eigentlich das Paar aus "der Bug war reproduzierbar" und "nach dem Fix ist er verschwunden", und der Widerleger findet die Lücken in diesem Paar zuverlässig. Der dritte Fall sind Änderungen, deren Code ich nicht vollständig lesen werde. Dass ein Mensch einen großen, von KI erzeugten diff komplett liest, bricht in der Praxis zusammen. Wenn ich schon nicht lese, soll wenigstens ein anderes Modell adversarial lesen.

Über die Kosten muss man reden, aber eine Widerlegungsrunde kostet den Gegenwert einiger Modellaufrufe. Verglichen mit den Kosten, einen in Produktion gegangenen Bug als Mensch zurückzuverfolgen, war das keine Abwägung wert. Wäre der Logout-Bug von oben bis ins Deployment gekommen, hätte ich mit nichts als der Meldung "manchmal klappt der Logout nicht" selbst durch zwei Schichten graben müssen, den Redirect und die Flag-Guard.

Warum es ein anderes Modell sein muss

Eine frische Session desselben Modells bringt schon einen gewissen Effekt. Allein die Kontexttrennung beseitigt das Problem, dass die Erzählung abfärbt. Aber nach einigen Monaten Betrieb ist mein Fazit: Wenn das Modell selbst ein anderes ist, wird deutlich mehr gefunden.

Jedes Modell achtet auf andere Stellen. Ist das eine empfindlich für Timing-Probleme im State-Management, reagiert das andere auf Vertragsverletzungen und Randwerte. Zwei Sessions desselben Modells teilen dieselben blinden Flecken, aber bei verschiedenen Modellen verschieben sich die blinden Flecken gegeneinander. Der Wert des Cross-Checks kommt genau aus dieser Verschiebung.

Diese Struktur dürfte niemandem fremd vorkommen. Es ist derselbe Grund, aus dem menschliche Teams das Code-Review jemandem geben, der nicht der Autor ist. Mit KI zu arbeiten hebt dieses Prinzip nicht auf; es lässt sich nur endlich billig und dauerhaft anwenden. Ein Prüfer, der nicht der Autor ist, ein Blick, den die Erzählung nicht gefärbt hat, und eine Freigabe, die es erst gibt, wenn die Widerlegung scheitert. Was sich menschliche Organisationen wegen der Kosten nur gelegentlich leisten konnten, kann jetzt dauerhaft vor jedem Merge stehen.