Review-Agenten: Wann ein KI-Prüfer wirklich prüft

Ein Agent schreibt Testfälle, ein zweiter Agent prüft sie. Das sieht nach Vier-Augen-Prinzip aus. Es ist aber nur eins, wenn der Prüfer nicht genau dasselbe weiß wie der Geprüfte.

Luca Ortiz beschreibt bei heise Developer, wie er das in der Praxis gelernt hat: Lehren aus einem produktiven Review-Agenten-Workflow. Sein Workflow läuft seit sechs Monaten im Projektalltag, hat rund 140 User-Storys verarbeitet und daraus echte Testfälle in Jira erzeugt⁠¹. Kein Demo-Aufbau, sondern Betrieb. Deshalb lohnt sich der Blick auf die Details.

Wie ein Review-Agent den Fehler des Generators übernimmt

Der Aufbau hat zwei Rollen⁠¹. Ein Generierungs-Agent bekommt eine User-Story mit Titel, Beschreibung und Akzeptanzkriterien und schreibt daraus Testfälle samt Testdaten. Ein Review-Agent prüft das Ergebnis, bevor es weiterläuft: Sind alle Akzeptanzkriterien abgedeckt? Tauchen erfundene Rollen, Systeme oder Anmeldewege auf?

In der ersten Version bekam der Review-Agent denselben fachlichen Kontext wie der Generator, dazu die Anweisung, kritisch zu prüfen⁠¹. Das ging schief, sobald der Kontext lückenhaft war. Dann fehlte dem Prüfer dieselbe Information wie dem Generator, und er konnte nicht bemerken, was ihm selbst fehlte. Ortiz nennt das ein Echo derselben Lücke statt eines Vier-Augen-Prinzips⁠¹.

Daraus folgt für mich der Kernsatz: Ob ein Prüfer unabhängig ist, entscheidet die Architektur, nicht der Prompt. „Prüfe kritisch“ hilft nichts, wenn beide Agenten aus derselben Quelle schöpfen.

Eigener Kontextpfad und ein zweites Modell

Ortiz hat zwei Dinge geändert⁠¹. Erstens holt der Review-Agent den fachlichen Kontext nicht mehr aus dem Prompt des Generators, sondern direkt von der zentralen Stelle, an der er einmal hinterlegt ist. Ändert jemand versehentlich den Generierungs-Prompt, prüft der Review-Agent trotzdem gegen die unveränderte Fassung. Zweitens laufen Generator und Prüfer auf Modellen verschiedener Anbieter.

Bemerkenswert ist, wie offen er die Grenzen nennt⁠¹. Steht in der zentralen Quelle selbst etwas Falsches, etwa ein falscher Anmeldeweg, irren beide Agenten gemeinsam. Der blinde Fleck wandert dann nur eine Ebene nach oben. Und dass Modelle verschiedener Anbieter verschiedene Fehler machen, ist bei ihm eine Annahme, für die ein Beleg aus dem eigenen Workflow noch aussteht.

Zu diesem zweiten Punkt kann ich etwas beitragen. In asseko.ai bewerten fünf KI-Modelle Tarife der privaten Krankenversicherung nach rund 375 Kriterien und müssen zu einem Konsens kommen. Die Fehlerquote sank damit von etwa 5 Prozent auf unter 0,1 Prozent⁠². Das ist ein anderes Einsatzfeld als Testfälle, zeigt aber die Richtung: Mehrere unabhängige Modelle fangen Fehler ab, die ein einzelnes Modell durchlässt.

Was die Ausnahmen über den Generator verraten

Vor dem Produktivbetrieb hat Ortiz den Prüfer mit absichtlich lückenhaften Prompts getestet. In allen 30 Testläufen schlug der Review-Agent an⁠¹. Im echten Betrieb lag die Ausnahmequote in den ersten Wochen bei knapp 30 Prozent⁠¹. Jede berechtigte Ausnahme floss in den Generierungs-Prompt zurück, und die Quote lief gegen null. Was heute noch auffällt, sind meist Fehlalarme eines absichtlich streng eingestellten Prüfers⁠¹.

Diese Schieflage ist richtig gewählt. Eine übersehene Halluzination kostet mehr als ein Fall, der einmal zu viel bei einem Menschen landet. Wer einen Prüfer baut, sollte vorher entscheiden, in welche Richtung er sich irren darf.

Wenn die Ausnahmen den Menschen wieder ausbremsen

Review by Exception heißt: Nur Ausnahmen landen beim Menschen. Das funktioniert, solange es wenige sind. Laufen mehr Agenten parallel und mehr Storys durch, wächst die Zahl der Ausnahmen schneller, als der Generator besser wird⁠¹. Der Engpass verschiebt sich dann vom einzelnen Testfall zur einzelnen Ausnahme.

Ortiz schlägt vor, dass der Prüfer einen Wert vergibt statt Ja oder Nein⁠¹. Eindeutige Fälle wie erfundene Systeme oder fehlende Akzeptanzkriterien gehen automatisch zurück in die Korrekturschleife oder werden verworfen. Nur das unsichere Mittelfeld kommt zum Menschen.

Drei Fragen für jeden Schritt einer Agentenkette

Das Muster gilt nicht nur für Testfälle. Überall, wo ein Agent arbeitet und ein anderer prüft, helfen drei Fragen:

1. Woher bezieht der Prüfer sein Wissen, und ist das eine andere Quelle als die des Geprüften?
2. Wohin soll sich der Prüfer im Zweifel irren: zu streng oder zu großzügig?
3. Wer pflegt die gemeinsame Quelle, auf die sich am Ende doch beide stützen?

Ortiz ordnet seinen Workflow auf Stufe 3 eines fünfstufigen Reifegradmodells ein, angelehnt an die Stufen des autonomen Fahrens⁠¹: Nicht jedes Ergebnis wird von Hand geprüft, nur die Ausnahme. Mehr Autonomie strebt er ohne diese Kontrollen bewusst nicht an. Der Mensch bleibt verantwortlich. Er prüft nur nicht mehr jedes Ergebnis selbst, sondern legt die Regeln fest, nach denen geprüft wird.

Wenn Sie KI-Agenten einsetzen wollen, die sich gegenseitig kontrollieren, klären wir im kostenlosen Potenzial-Check, wo in Ihrem Ablauf die Prüfgrenzen sitzen müssen.