Prüf durch Ausführen, nicht durch Lesen

Ich habe neulich eine halbe Stunde damit verbracht, einen Fehler an der falschen Stelle zu suchen.

Die KI hatte mir erklärt, wo die Daten herkommen. Ich habe die Datei aufgemacht, sie gelesen, genickt, und angefangen, dort zu reparieren. Es half nichts. Ich las nochmal. Half wieder nichts. Erst als ich aufhörte zu lesen und stattdessen die App einmal durchlaufen ließ und nachschaute, was wirklich in die Datenbank ging, sah ich es: Die Daten kamen aus einer ganz anderen Datei. Die KI hatte mir eine plausible Erklärung geliefert. Ich hatte sie gelesen. Und ich hatte die falsche Datei vor mir.

Das ist mir passiert, mit Jahren Erfahrung. Es liegt nicht an dir, wenn es dir auch passiert.

Lesen prüft das falsche Ding

Wenn du Code liest, prüfst du dein Bild davon, was passiert. Du prüfst nicht, was passiert.

Das klingt nach Wortklauberei, ist aber der ganze Unterschied. Beim Lesen baust du im Kopf ein Modell: Diese Funktion wird aufgerufen, dann jene, am Ende landet das Ergebnis hier. Wenn dein Modell stimmt, bestätigt das Lesen es. Wenn dein Modell falsch ist, bestätigt das Lesen es trotzdem, weil du liest, was zu deinem Modell passt, und über den Rest hinweggleitest. Ein falsches mentales Modell überlebt das Lesen problemlos.

Dazu kommt das Problem mit der richtigen Datei. Bei zehn Dateien, die alle ähnlich aussehen, kannst du nie sicher sein, dass du die liest, die im Ernstfall tatsächlich läuft. Du liest sorgfältig. Nur eben das Falsche.

Ausführen prüft die Realität

Eine Abfrage gegen die echte Datenbank lügt nicht. Eine kleine Prüfung, die du tatsächlich laufen lässt, zeigt dir das System, wie es ist, nicht wie du es dir vorstellst.

Eine ausgeführte Abfrage schlägt zehn gelesene Dateien. Nicht, weil Lesen wertlos wäre, sondern weil Ausführen die eine Frage beantwortet, die Lesen offen lässt: stimmt mein Bild mit der Wirklichkeit überein? Und es beantwortet sie, ohne dass du vorher die richtige Datei erraten musst. Du fragst das laufende System direkt, und das laufende System weiß, welche Datei wirklich zählt.

Die Dreißig-Sekunden-Prüfung

KI-Modelle behaupten Dinge mit voller Überzeugung, die schlicht nicht stimmen. OpenAI hat in einer eigenen Untersuchung beschrieben, warum Sprachmodelle selbstbewusst Falsches erzeugen — es ist kein Bug, der sich wegtrainieren lässt, sondern fällt aus der Funktionsweise. Eine selbstbewusste Behauptung ist also kein Beweis. Sie ist eine Behauptung mit gutem Tonfall.

Deshalb: Wenn die KI dir etwas über dein laufendes System sagt, glaub es nicht. Test es. Und das dauert meistens dreißig Sekunden.

“Die User-Tabelle hat ein Feld für den Verifizierungsstatus.” Schön. Frag die Datenbank, welche Felder die Tabelle wirklich hat. “Nach dem Login wird die Session gesetzt.” Gut. Log dich ein und schau nach, ob sie gesetzt ist. “Diese Funktion wird beim Speichern aufgerufen.” Bau eine sichtbare Spur ein, speichere einmal, und sieh nach, ob die Spur erscheint.

Jede dieser Prüfungen ersetzt eine Annahme durch eine Beobachtung. Und eine Beobachtung kann dich nicht so anlügen wie ein gut formulierter Satz. Welche Fragen du der KI stellst, damit sie dir die Stelle zeigt statt sie nur zu behaupten, habe ich in lass dir’s zeigen, nicht sagen durchgespielt.

Vom Test zum Schutz

Wenn du eine Behauptung einmal gegen die Realität geprüft hast, wirf die Prüfung nicht weg. Gieß sie in einen Test, der von allein anschlägt, wenn sich das Verhalten später ändert. Aus der einmaligen Dreißig-Sekunden-Prüfung wird ein Wächter, der dauerhaft auf der Stelle sitzt, die dir wichtig ist. Warum das mehr ist als nur Lesen und worauf es beim genauen Hinsehen ankommt, steht in was die KI in deinem Code wirklich gebaut hat.

Und es schützt vor einer zweiten Falle: dem grünen Häkchen, das wie ein Beweis aussieht, aber keiner ist. Eine KI, die sagt “ich habe es getestet, es funktioniert”, hat dir wieder nur etwas erzählt. Warum dir das nicht reichen darf, habe ich in verifiziert ist kein Beweis auseinandergenommen.

Solange du dran denken musst, passiert es unregelmäßig

Die Dreißig-Sekunden-Prüfung hat einen Haken. Du musst sie machen. In der ersten Woche prüfst du jede Behauptung. In der vierten nickst du wieder und liest.

Deshalb wandert das Ausführen irgendwann aus deinem Kopf in deine Einrichtung. Eine Prüfung, die bei jedem Change von allein losläuft, fragt nicht, ob du gerade Zeit hast. Sie läuft am Freitagabend genauso wie am Montagmorgen.

Dasselbe gilt für die KI. Ein Agent, dessen Auftrag “führ es aus und zeig mir die Ausgabe” lautet, erzählt dir seltener etwas. Er startet die App, ruft den Endpoint auf, fragt die Datenbank. Was zurückkommt, ist eine Beobachtung. Nur bewertest du ab da den Beleg: Ein grüner Testlauf ohne echte Prüfbedingung läuft durch den Codepfad und prüft nichts, und ein Screenshot zeigt eine Oberfläche, nicht die Zeile in der Datenbank. Welche Beobachtung als Beweis zählt, legst du fest.

Und der wichtigste Teil: Ein Fehlschlag meldet sich selbst. Du erfährst von der kaputten Annahme in dem Moment, in dem sie kaputtgeht, nicht eine halbe Stunde später an der falschen Stelle.

Genau das steht im Harness-Setup-Guide: welche Prüfungen sich verdrahten lassen, wo im Ablauf sie einhaken und wie du einem Agenten das Ausführen zur Pflicht machst.

Eine Annahme stirbt nicht beim Lesen. Sie stirbt beim Ausführen.