Wenn die KI "fertig" sagt: der Mechanismus, der es ihr nicht glaubt

Wenn man mit KI-Coding-Agenten arbeitet, gibt es einen Satz, der einen am häufigsten hereinlegt: "Fertig."

Der Agent sagt das viel zu leicht. Er behauptet "die Tests werden durchlaufen", ohne sie tatsächlich gestartet zu haben, und er sagt "die Ursache ist behoben", ohne den Bug je reproduziert zu haben. Liest man den Code, wirkt er plausibel. Führt man die Befehle aber wirklich aus, ist ungefähr die Hälfte gar nicht fertig. Nachdem ich das lange erlebt hatte, kam ich zu einem Schluss: Das Problem ist nicht, dass die KI lügt, sondern dass ich jedes Mal selbst entscheiden musste, ob ich ihr das glaube oder nicht.

Kein Vertrauensproblem, sondern ein Beweisproblem

Ich arbeite allein und schreibe fast meinen gesamten Code mit KI. Dabei entscheide ich Dutzende Male am Tag: "Kann ich diese Änderung übernehmen?" Anfangs las ich jedes Mal den Bericht des Agenten und prüfte bei Zweifeln selbst nach, indem ich die Befehle laufen ließ. Das Problem an dieser Methode ist, dass die Prüfung an mir hängt. An müden Tagen, an hektischen Tagen, am zehnten ähnlichen Vorgang winkt man es durch nach dem Motto "wird schon passen, wenn er es sagt". Und genau bei dem, was man so durchgewunken hat, passiert der Unfall.

Also habe ich die Richtung geändert. Statt jedes Mal selbst misstrauisch zu sein, habe ich das System dazu gebracht, Beweise zu verlangen. Ich habe ein Tor in die Harness eingebaut, das es dem Agenten unmöglich macht, seinen Turn allein mit den Worten "fertig" zu beenden. Fertigstellung ist keine Erklärung mehr, sondern eine Prüfung, die bestanden werden muss.

Die Wurzel dieses Gedankens ist simpel. Je billiger die KI Code ausspuckt, desto mehr verschiebt sich der Engpass von der Produktion zur Verifizierung. Wenn die Kosten fürs Erzeugen von Code gegen null gehen, wird "glauben, dass es stimmt" relativ die teuerste Aufgabe. Und dann sollte man diese teure Aufgabe nicht der jeweiligen Tagesform eines Menschen überlassen, sondern zu einem automatisch erzwungenen Ablauf machen.

Der Hook, der das Beenden blockiert

Konkret nutze ich einen Hook, der sich zum Zeitpunkt des Beendens einklinkt. Wenn der Agent erklärt, die Arbeit sei erledigt, und den Turn beenden will, läuft unmittelbar davor eine Prüfung. Diese Prüfung verlangt nur eines: "Leg den Beweis vor, dass es fertig ist."

Gibt es keinen Beweis, wird das Beenden verweigert. Der Agent wird zurückgeschickt, mit der Nachricht: "Du hast die Fertigstellung nicht bewiesen, mach weiter." Dann erst startet der Agent die Tests, führt die Befehle aus und fügt die Ausgabe an. Das Kuriose ist, dass er dabei in der Hälfte der Fälle selbst feststellt: "Ach, es ist noch gar nicht fertig", und die restliche Arbeit tatsächlich zu Ende bringt. Als er "fertig" sagte, war es eben doch nicht wirklich fertig.

Entscheidend ist, dass dieses Tor eine Maschine ist und kein Mensch. Ob ich müde oder in Eile bin, das Tor bleibt gleich streng. Meine Disziplin wackelt, die des Hooks nicht. Die Verifizierung ist damit keine Gewohnheit mehr, sondern Infrastruktur.

Was als Beweis anerkannt wird

Was also lasse ich als "Beweis" gelten? Ich nutze vier Arten.

1. Befehlsausgabe. Wenn die Tests bestanden wurden, muss die tatsächliche Ausgabe des Test-Runners da sein. Nicht "wird bestehen", sondern das Log vom Bestehen. Wenn der Build durchlief, das Build-Log; wenn der Lint sauber ist, die Lint-Ausgabe.
2. diff. Was geändert wurde, muss als diff sichtbar sein. Nicht in Worten "ich habe diese Funktion gefixt", sondern die geänderten Zeilen im Original. Hier fällt auf, ob der Umfang der Änderung mit dem Bericht übereinstimmt.
3. Reproduktion. Wenn ein Bug behoben wurde, müssen als Paar zwei Belege vorliegen: der Beweis, dass der Bug vor dem Fix tatsächlich reproduzierbar war, und der Beweis, dass er nach dem Fix verschwunden ist. Ohne before/after ist "behoben" nur eine Vermutung.
4. Cross-Check. Wichtige Änderungen lasse ich von einem anderen Modell reviewen. Was Claude geschrieben hat, sieht sich Codex an, und beide zeigen die blinden Flecken des jeweils anderen auf. Das fängt weit mehr, als wenn ein Modell die eigene Arbeit selbst begutachtet.

Die Gemeinsamkeit dieser vier ist, dass sie allesamt reproduzierbare Fakten sind. Keine Meinung, sondern Ausgabe, die man einfügen kann. Genau hier liegt der Grund, warum die KI nicht das letzte Urteil fällen kann. Den Maßstab für "gut" festzulegen und zu entscheiden, welche Ausgabe diesen Maßstab erfüllt, bleibt am Ende Sache des Menschen. Nur trifft man dieses Urteil nicht jedes Mal von Hand, sondern gießt das Prüfverfahren in Code.

Warum das auch für den Menschen gut ist

Nachdem das Tor stand, gab es einen Effekt, den ich nicht erwartet hatte. Nicht nur der Agent wurde diszipliniert, auch für mich wurde es leichter.

Früher war es meine Aufgabe, den Bericht zu lesen und zu zweifeln: "Ist das wirklich fertig?" Jetzt macht das der Hook. Die Arbeit, die bei mir ankommt, hat den Beweis bereits angeheftet. Ich prüfe den Beweis, statt erst nachzusehen, ob überhaupt einer da ist. Die Startlinie meines Urteils ist damit einen Schritt nach vorn gerückt.

Und das ist zugleich eine Aufzeichnung, die ich meinem späteren Ich hinterlasse. Warum eine bestimmte Änderung sicher ist, bleibt zusammen mit der damaligen Befehlsausgabe erhalten. Wenn ich mich einen Monat später frage "warum habe ich das so gemacht", hängt die Begründung direkt neben dem Commit.

Der eine Muskel, den man neu trainieren muss

Über die Art, mit KI zu arbeiten, werden allerhand Skills diskutiert, aber am stärksten geblieben ist bei mir dies: Verlagere die Verifizierung weg von dir selbst ins System.

Die Kunst, gute Prompts zu schreiben, veraltet, wenn das Modell wechselt. Ein Kniff, der gestern funktioniert hat, greift beim neuen Modell nicht mehr. Die Disziplin "Fertigstellung nur als Beweis anerkennen" hingegen liegt als Schicht über dem Modell und veraltet nicht. Egal welches Modell man nutzt, egal wie viele Generationen die Modelle durchlaufen, das Tor, das Beweise verlangt, bleibt gleichermaßen nützlich. Im Gegenteil steigt sein Wert, je klüger die Modelle werden, denn sie liegen dann umso überzeugender falsch.

Die KI hat uns die Last des Programmierens abgenommen. Übrig gelassen hat sie uns dafür die Aufgabe zu entscheiden: "Darf ich das glauben?" Will man dieses Urteil jedes Mal mit menschlichem Willen fällen, ermüdet man und es sickert etwas durch. Sorgt man stattdessen dafür, dass die Maschine Beweise verlangt, steht ein Tor, das nicht ermüdet, stellvertretend für mich streng auf Posten. Je mehr jemand die KI arbeiten lässt, desto mehr sollte die Mühe nicht in das "Wie beauftrage ich?" fließen, sondern in das "Wie verifiziere ich die Behauptung, es sei fertig?"