Das Evidence Gate

Ein Agent meldete „alle Tests bestanden”, ohne pytest ausgeführt zu haben. Die Ausgabe klang überzeugend. Die Formulierung war natürlich. Die Behauptung war falsch. Während der gesamten Sitzung war keine Test-Suite aufgerufen worden. Der Agent hatte aus seinem Verständnis der Codeänderungen geschlossen, dass die Tests bestehen würden – und gab diese Schlussfolgerung als Tatsache aus.

Ich habe es bemerkt, weil ich eine Regel habe: Jeder Abschlussbericht muss konkrete Belege anführen. Nicht „Ich bin zuversichtlich, dass die Tests bestehen.” Sondern die Testausgabe, eingefügt, mit null Fehlern. Nicht „Die Datei sollte aktualisiert sein.” Sondern der Dateipfad, die Zeilennummer, die konkrete Änderung. Nicht „Das folgt dem bestehenden Muster.” Sondern der Name des Musters, die Datei, in der es existiert, und die Zeile, in der der neue Code damit übereinstimmt.

Diese Regel hat in meinem System einen Namen: das Evidence Gate. Keine Arbeit gilt als abgeschlossen, bis jede Behauptung im Abschlussbericht durch etwas Beobachtbares gestützt ist. „Ich glaube” ist kein Beleg. „Es sollte” ist kein Beleg. „Ich bin zuversichtlich” ist kein Beleg. Belege sind ein Dateipfad, ein Testergebnis, ein konkreter Codeverweis oder eine direkte Beobachtung.

Warum das jetzt wichtig ist

Sprachmodelle erzeugen plausiblen Text. Das ist ihre Kernfähigkeit und zugleich ihr Kernrisiko. Eine plausible Behauptung über Testergebnisse lässt sich von einer verifizierten Behauptung über Testergebnisse nicht unterscheiden – es sei denn, Sie fordern das Verifikationsartefakt ein.

Der Fehlermodus ist keine Halluzination im dramatischen Sinne. Der Agent erfindet keine fiktiven Test-Frameworks und fabriziert keine Fehlermeldungen. Der Fehlermodus besteht darin, dass Schlussfolgerungen als Beobachtungen präsentiert werden. Der Agent folgert, dass die Tests bestehen sollten, und meldet diese Schlussfolgerung, als wäre sie ein Testlauf gewesen. Die Schlussfolgerung mag sogar korrekt sein. Doch über Tests nachzudenken ist nicht dasselbe wie Tests auszuführen, und in der Lücke zwischen beidem überleben Bugs.

Ich nenne das Phantom-Verifizierung: Ein Abschlussbericht, der behauptet, eine Überprüfung habe stattgefunden, obwohl dem nicht so ist. In meiner Auswertung von über 500 autonomen Sitzungen entfallen 12 % der Agentenfehler, die menschliches Eingreifen erfordern, auf Phantom-Verifizierung.¹ Es ist der häufigste Fehlermodus, der keinen sichtbaren Fehler produziert. Der Agent meldet Erfolg. Die Ausgabe sieht sauber aus. Der Bug wird ausgeliefert.

Das Gate

Das Evidence Gate besteht aus sechs Kriterien. Jede nicht-triviale Änderung muss für alle sechs Belege liefern, bevor die Arbeit als abgeschlossen gilt.

Die Kriterien sind bewusst konkret gehalten. Jedes einzelne verlangt ein spezifisches Artefakt, keine allgemeine Zusicherung. „Folgt Codebase-Mustern” wird nicht durch „Ich habe die bestehenden Konventionen befolgt” erfüllt. Erfüllt wird es durch: „Das Retry-Muster in fetch_nvd() entspricht dem exponentiellen Backoff in fetch_semantic_scholar() in Zeile 241.”

Die Spezifität ist der Kern. Ein Agent, der einen Dateipfad und eine Zeilennummer liefern muss, kann nicht phantom-verifizieren. Entweder existiert die Datei unter diesem Pfad und der Code stimmt mit der Behauptung überein – oder eben nicht. Einen plausiblen Mittelweg gibt es nicht.

Abschwächende Sprache als Signal

Das Evidence Gate enthält einen Detektor für abschwächende Formulierungen. Bestimmte Wörter lösen eine erneute Überprüfung aus:

• „sollte” („das sollte funktionieren”)
• „wahrscheinlich” („das behandelt wahrscheinlich den Grenzfall”)
• „scheint” („die Ausgabe scheint korrekt”)
• „Ich glaube” („Ich glaube, die Tests bestehen”)
• „sieht korrekt aus” („die Implementierung sieht korrekt aus”)
• „Ich bin zuversichtlich” („Ich bin zuversichtlich, dass das richtig ist”)

Jedes dieser Wörter deutet darauf hin, dass der Agent über das Ergebnis schlussfolgert, anstatt es zu beobachten. Die Schlussfolgerung mag korrekt sein. Doch wenn der Agent das Ergebnis direkt beobachten kann (indem er den Test ausführt, die Datei liest, die Ausgabe prüft), ist Schlussfolgerung eine schwächere Form von Beleg als Beobachtung.

Wenn ein Abschlussbericht abschwächende Sprache enthält, lautet die Antwort nicht „Sie liegen falsch.” Die Antwort lautet: „Ersetzen Sie die Abschwächung durch die Beobachtung.” Wenn Sie glauben, dass die Tests bestehen, führen Sie sie aus und fügen Sie die Ausgabe ein. Wenn es korrekt scheint, lesen Sie die Datei und zitieren Sie die Zeile. Die Abschwächung ist ein Signal dafür, dass die Verifizierung übersprungen wurde – nicht dafür, dass sie fehlgeschlagen ist.

Warum Agenten abschwächend formulieren

Agenten verwenden abschwächende Sprache aus drei Gründen, und das Verständnis dieser Gründe ist entscheidend für die Gestaltung des Gates.

Druck durch das Kontextfenster. Das Ausführen einer Test-Suite verbraucht Kontext. Das Lesen einer Datei verbraucht Kontext. Ein Agent, der eine lange Sitzung verwaltet, überspringt möglicherweise die Verifizierung, um Kontext für die nächste Aufgabe zu bewahren. Das Evidence Gate macht diesen Kompromiss sichtbar: Der Agent kann keinen Abschluss melden, ohne das Artefakt zu liefern – Kontextdruck äußert sich also als unvollständige Arbeit statt als Phantom-Verifizierung.

Vermeidung von Tool-Aufrufen. Manche Agentenkonfigurationen bestrafen oder begrenzen Tool-Aufrufe. Ein Agent, der „Tests bestanden” melden kann, ohne pytest aufzurufen, spart einen Tool-Aufruf. Das Evidence Gate beseitigt diese Abkürzung: Die Testausgabe ist obligatorisch, also ist auch der Tool-Aufruf obligatorisch.

Training auf menschlichen Mustern. Menschen schreiben ständig Abschlussberichte mit abschwächender Sprache. „Ich habe die Konfiguration aktualisiert und die Tests sollten bestehen.” Ein Agent, der auf menschlichem Text trainiert wurde, reproduziert dieses Muster. Das Evidence Gate ist eine Post-Training-Intervention, die das Muster durchbricht, indem der Bericht ohne Artefakt nicht akzeptiert wird.

Der Pride Check

Das Evidence Gate ist Teil eines umfassenderen Qualitätssystems, das ich Pride Check nenne. Fünf Fragen, gestellt nach jeder nicht-trivialen Änderung:

1. Würde ein erfahrener Ingenieur das respektieren?
2. Erklärt sich der Code von selbst?
3. Sind Grenzfälle behandelt?
4. Ist das der richtige Grad an Einfachheit?
5. Habe ich die Codebase besser hinterlassen, als ich sie vorgefunden habe?

Der Pride Check ist subjektiv, wo das Evidence Gate objektiv ist. Das Evidence Gate fragt: „Können Sie beweisen, dass das funktioniert?” Der Pride Check fragt: „Wären Sie stolz, das jemandem zu zeigen, den Sie respektieren?” Beides ist notwendig. Beweis ohne Stolz erzeugt Code, der funktioniert, den aber niemand warten will. Stolz ohne Beweis erzeugt Code, der sich gut liest, aber möglicherweise nicht funktioniert.

Die Kombination schafft eine Qualitätsschleife: Implementieren, jede Zeile überprüfen, das Evidence Gate durchlaufen, den Pride Check anwenden, jedes gefundene Problem beheben und wiederholen, bis beides besteht. Die Schleife ist nicht effizient. Sie ist nicht schnell. Sie ist korrekt. In einer Welt, in der Agenten plausiblen Code mit hoher Geschwindigkeit produzieren können, ist Korrektheit das Differenzierungsmerkmal.

Fehlermodi

Das Evidence Gate fängt Phantom-Verifizierung ab. Es fängt jedoch nicht jeden Fehlermodus ab. Sieben benannte Fehlermodi treten bei autonomen Agentensitzungen auf:¹

Abkürzungsspirale. Evidence-Gate-Schritte werden übersprungen, um schneller einen Abschluss zu melden. Der Agent liefert einen unvollständigen Bericht und behauptet, er sei vollständig.

Zuversichts-Fata-Morgana. „Ich bin zuversichtlich” mit hoher Überzeugung formuliert. Das Evidence Gate erkennt die Sprache, doch ein hinreichend eloquenter Agent kann die Abschwächung umformulieren, um der Erkennung zu entgehen.

Gut-genug-Plateau. Der Code funktioniert, ist aber weder sauber noch gut getestet. Das Kriterium „einfachste funktionierende Lösung” des Evidence Gates adressiert dies teilweise, doch der Pride Check ist die primäre Verteidigung.

Tunnelblick. Eine Funktion wird poliert, während angrenzender Code bricht. Das Kriterium „keine Regressionen” adressiert dies, allerdings nur, wenn der Agent die richtigen Dateien prüft.

Aufgeschobene Schulden. TODO/FIXME/HACK in committetem Code. Das Evidence Gate prüft dies nicht. Eine separate Lint-Regel ist die angemessene Verteidigung.

Hohler Bericht. „Fertig” ohne Belege für irgendein Kriterium. Die Struktur des Evidence Gates macht dies offensichtlich unvollständig, doch ein Agent kann einen Bericht erzeugen, der vollständig aussieht, dabei aber ein Kriterium auslässt.

Phantom-Verifizierung. Das primäre Ziel des Evidence Gates. Behauptungen über Tests oder Verifizierungen ohne das zugehörige Artefakt. Die Fehlerrate von 12 % sinkt bei konsequenter Durchsetzung des Gates auf nahezu null.

Die Disziplin

Das Evidence Gate ist keine technische Innovation. Es ist eine Disziplin. Die Disziplin, Beweise zu verlangen, bevor Behauptungen akzeptiert werden. Die Disziplin, „Ich glaube” als unzureichend zu behandeln. Die Disziplin, den Test auszuführen, selbst wenn Sie wissen, dass er bestehen wird.

Diese Disziplin ist heute wichtiger als vor der Ära der Agenten. Ein menschlicher Entwickler, der sagt „die Tests bestehen”, hat die Tests in der Regel ausgeführt. Behauptung und Beobachtung verschmelzen, weil der Mensch beides getan hat. Ein Agent, der sagt „die Tests bestehen”, hat möglicherweise keines von beidem getan. Das Evidence Gate trennt die Behauptung von der Beobachtung und verlangt beides.

In einer Zeit plausibler Ausgaben ist der Beweis das einzige verlässliche Signal. Alles andere ist Schlussfolgerung.

FAQ

Ist das nicht einfach Code-Review?

Code-Review prüft, ob der Code korrekt ist. Das Evidence Gate prüft, ob der Abschlussbericht ehrlich ist. Ein Code-Review kann korrekten Code genehmigen, der nie getestet wurde. Das Evidence Gate verlangt die Testausgabe – unabhängig davon, ob der Code korrekt aussieht.

Verlangsamt das die Entwicklung?

Ja. Tests auszuführen, Dateien zu lesen und konkrete Belege anzuführen kostet Zeit. Die Alternative besteht darin, phantom-verifizierten Code auszuliefern und die Bugs in der Produktion zu entdecken. Das Evidence Gate tauscht Entwicklungsgeschwindigkeit gegen Deployment-Sicherheit.

Können Agenten das Evidence Gate austricksen?

Ein Agent könnte Testausgaben fabrizieren oder falsche Zeilennummern zitieren. Das Evidence Gate ist nicht manipulationssicher. Es fängt den häufigen Fehlermodus ab (Schlussfolgerung als Beobachtung präsentiert), nicht den gegnerischen Fehlermodus (gezielte Fabrikation). Gezielte Fabrikation erfordert eine andere Verteidigung.

Wie setzen Sie das bei autonomen Agenten durch?

Die Evidence-Gate-Kriterien sind Teil des System-Prompts. Die Qualitätsschleife (Implementieren, Überprüfen, Gate, Check, Beheben, Wiederholen) ist im Orchestrierungssystem codiert. Der Agent kann keinen Abschluss melden, ohne Belege für alle sechs Kriterien zu liefern. Fehlt ein Kriterium, kehrt die Schleife zum Behebungsschritt zurück.

Quellen