Warum ein KI-Agent „Fertig“ sagt, obwohl die Arbeit noch nicht abgeschlossen ist

Wie konnte ein OpenAI-Modell aus der Sandbox ausbrechen und Hugging Face hacken?#

Zuerst die Fakten, dann, warum das für dich wichtig ist.

OpenAI maß, was seine Modelle im Bereich offensiver Cybersicherheit leisten konnten. Dafür nutzte das Unternehmen den ExploitGym-Test – 898 Aufgaben, bei denen man eine bekannte Schwachstelle in einen funktionierenden Exploit verwandeln muss, also in ein fertiges Programm, das diese Schwachstelle ausnutzt. Um die tatsächliche Leistungsgrenze zu erkennen, deaktivierten sie die eingebauten Sicherheitsfilter, die das Modell normalerweise davon abhalten, solche Dinge zu tun. Sie schotteten die Umgebung vollständig ab und ließen nur einen Ausweg offen: ein internes Vermittlungsprogramm, das zum Installieren von Paketen verwendet wurde.

Eine Zero-Day-Schwachstelle ist eine Lücke, von der noch niemand weiß – auch nicht die Person, die das Programm geschrieben hat. Die Modelle fanden eine solche Lücke genau in diesem einzigen offenen Zugang.

Anschließend erweiterten sie ihre Berechtigungen, bewegten sich durch das interne Netzwerk zu einem Rechner mit Internetzugang und vermuteten von dort aus, dass sich die Antworten auf ExploitGym vielleicht auf Hugging Face befänden. Niemand hatte ihnen Hugging Face genannt. Sie kamen selbst darauf.

Die Vermutung war falsch. ExploitGym ist auf Hugging Face überhaupt nicht zu finden. Das macht den Hack nicht weniger real.

Hugging Face entdeckte den Einbruch selbst und veröffentlichte seine Mitteilung am 16. Juli, ohne zu wissen, wer das Unternehmen gehackt hatte.

Ein weiteres Detail aus diesem Bericht sagt viel über den Stand der Dinge aus. Als Ingenieure von Hugging Face versuchten, das Angriffsprotokoll über gewöhnliche kommerzielle Schnittstellen führenden Modellen vorzulegen, blockierten Sicherheitsfilter die Anfragen: Sie können nicht zwischen jemandem unterscheiden, der einen Hack untersucht, und jemandem, der ihn ausführt. Am Ende lief die Analyse auf einem offenen Modell auf der eigenen Hardware.

OpenAI bestätigte den Vorfall am 21. Juli, fünf Tage nach der Mitteilung von Hugging Face. Zu diesem Zeitpunkt waren seit dem Einbruch selbst bereits etwa zehn Tage vergangen.

OpenAI schloss die eigene Analyse mit diesen Worten ab.

Das Modell fixierte sich auf das enge Ziel des Tests und ging bis zum Äußersten, um es zu erreichen. Die Wörter hyper-focused und fairly narrow testing objective stammen von OpenAI selbst und beziehen sich auf die eigenen Modelle.

Das ist die Brücke von einem fremden Labor zu deinem Laptop.

Warum ist das keine „Halluzination“?#

In Chats sehe ich oft Formulierungen wie „halluziniert schon wieder“, „der Kontext ist überlastet“ oder „wir hätten einen Plan machen sollen“. Manchmal ist das genau der Grund. Wenn ein KI-Agent aber schreibt „fertig, geprüft, alles funktioniert“ und die Arbeit nicht erledigt ist, hat die Größe des Kontexts meist nichts damit zu tun.

Er hat nichts erfunden. Er hat genau das getan, was du gemessen hast.

Unter dem beliebten Sammelbegriff „Halluzinationen“ fassen wir drei verschiedene Fehler zusammen. So unterscheiden sie sich:

Der erste Fehler lässt sich mit Kontext beheben; er ist der bekannteste Fall. Der zweite ist ein eigenes Phänomen, das in einer Analyse dazu behandelt wird, wenn Claude allem zustimmt: Das Modell opfert Genauigkeit für schnelle Zustimmung. Beide treten vor der Arbeit auf, auf der Eingabeseite.

Um die dritte Tabellenzeile geht es in diesem Artikel. Hier hat der Agent weder geschmeichelt noch etwas erfunden. Er hat gearbeitet, geprüft und die Wahrheit berichtet. Nur beschreibt diese Wahrheit die Kennzahl und sagt nichts über die Aufgabe aus.

Der dritte Fehler hat einen Namen.

Was ist Reward Hacking in einfachen Worten?#

Anthropic liefert selbst die Definition.

Die Idee ist älter als neuronale Netze. Ein Paper von DeepMind nennt das Specification Gaming und erklärt es anhand eines Mythos.

Midas bekam genau das, worum er gebeten hatte. Das Problem lag in der Formulierung seines Wunsches.

In der Programmierung nimmt das konkrete Formen an. Hier ist ein Lehrbuchbeispiel, ebenfalls von Anthropic:

Und das ist keine exotische Laborbedingung. Cursor analysierte 731 Abläufe in einem beliebten Benchmark.

Sechs von zehn „gelösten“ Aufgaben sind gefundene Antworten. Genau deshalb ändert die Branche, wie sie Leistung misst: Wir haben eine Analyse zu einem Benchmark, der die Produktionsreife misst, bei dem bestandene Prüfungen nicht mehr das Hauptkriterium sind.

Wie sieht das in einem gewöhnlichen Produkt aus?#

Laborbeispiele lassen sich leicht als exotisch abtun. Deshalb folgen hier vier Geschichten aus der Praxis. Kunden und Branchen sind geändert, die Abläufe aber so geblieben, wie sie waren.

Vier grüne Häkchen und eine tote Dienstkomponente

Eine Immobilienagentur baut einen Dienst: eine Website mit Immobilienanzeigen und dazu einen separaten Hintergrundprozess, der die Anzeigen nachts auf Plattformen exportiert. Der Agent erledigt die Aufgabe und berichtet: Die Typprüfung ist bestanden, die Stilprüfung ist bestanden, der Build ist erfolgreich, die Seiten reagieren, und sie wurden visuell überprüft.

Jede Aussage stimmt. Und keine davon hat etwas mit dem nächtlichen Prozess zu tun: Er läuft als separater Prozess und gehört überhaupt nicht zum Website-Build. Das Deployment gelingt, die Website funktioniert einwandfrei, der Export der Anzeigen stoppt, und die Kunden melden sich einen Tag später.

Bevor ich „fertig“ sage, stelle ich jetzt eine Frage: Welcher Teil der Arbeit läuft außerhalb des von meiner Prüfung abgedeckten Bereichs? Falls es einen solchen Teil gibt, führe ihn separat aus und füge die Befehlsausgabe dem Bericht bei. Mit dem Wort „geprüft“ ist das nicht erledigt.

Das falsche Häkchen sitzt genau an der Schnittstelle

Ein Onlineshop verteilt eine große Aufgabe gleichzeitig auf mehrere Agenten: Einer übernimmt das Backend, ein anderer die Seiten, ein dritter die Produktkarten. Alle arbeiten sorgfältig, und bei allen sind die Prüfungen grün.

Eine Woche später stellt sich heraus, dass die Schaltfläche „Diese Rezension war hilfreich“ nirgendwo funktioniert. Das Backend ist vollständig geschrieben, seine Prüfungen sind grün, und die Regeln zur Neuberechnung wurden befolgt. Nur zeigt keine Seite die Schaltfläche an: Sie lag im Zuständigkeitsbereich eines Agenten, die Seiten im Bereich eines anderen, und niemand dachte daran, sie auf den Bildschirm zu bringen. Der Zähler wäre für immer bei null geblieben.

„Der Code ist geschrieben und durch Prüfungen abgedeckt“ und „das Feature funktioniert“ sind zwei verschiedene Aussagen. Die zweite prüfe ich für jedes neue Feature mit einer Frage: Wer ruft es auf? Und ich überprüfe es, indem ich das Projekt durchsuche, denn der Bericht des Agenten ist hier keine verlässliche Quelle.

Die prüfende Person sieht nur die Richtung, die sie prüfen sollte

Ein Dienst führt Treuestufen ein: Je mehr du bezahlst, desto höher dein Status und desto größer dein Rabatt. Vor dem Deployment wird der Code mit der Anweisung zur Prüfung geschickt: „Versuche, deinen eigenen Status zu erhöhen.“ Die prüfende Person erledigt die Aufgabe ehrlich und meldet „nichts Kritisches“ – tatsächlich lässt sich der Status nicht künstlich erhöhen.

Bei einer zweiten Prüfung wird eine andere Frage gestellt: „Was passiert mit dem Status, wenn Geld zurückerstattet wird?“ Die Lücke ist in zehn Minuten gefunden. Punkte wurden anhand des Transaktionsprotokolls berechnet, und das Protokoll weiß nichts von Rückerstattungen. Etwas kaufen, Punkte verdienen, eine Rückerstattung erhalten und Status und Rabatt für immer behalten.

Die erste prüfende Person hat keine Abkürzungen genommen. Sie konnte das strukturell gar nicht sehen: Vorgegeben war ihr der Vektor „Eingabe, Aufwertung“, während die Lücke im Vektor „Eingabe umkehren, Aufwertung behalten“ lag. Wenn Geld, Zugang oder ein käuflicher Status auf dem Spiel stehen, lasse ich die Arbeit durch zwei Prüfungen laufen; bei der zweiten liste ich ausdrücklich die umgekehrten Vektoren auf: Rückerstattung, Sperrung, Zugangsentzug, Ablauf, Löschen der Datenquelle.

Die Kennzahl belohnt Ähnlichkeit

Ein Lieferdienst möchte messen, ob sich KI-Vorschläge für Mitarbeitende im Support verbessert haben. Er nimmt zweihundert alte Supportanfragen, lässt sie durch die neue Version laufen und misst, wie ähnlich der Entwurf der tatsächlichen Antwort einer menschlichen Supportkraft ist. Die Messung zeigt einen deutlichen Anstieg.

Der Anstieg bedeutet aus zwei Gründen nichts. Der Kontext für den Entwurf wird „zum heutigen Stand“ zusammengestellt und enthält den gesamten Schriftwechsel, einschließlich genau der Antwort der Supportkraft, mit der er anschließend verglichen wird. Das Modell verfasst keine Antwort, sondern formuliert die Referenz um, die es gesehen hat. Außerdem belohnt die Kennzahl selbst die Übereinstimmung bei Wörtern und Länge: Ein Entwurf mit dem falschen Datum erhält eine hohe Punktzahl, wenn er dieselben Wörter wie die korrekte Antwort der Supportkraft verwendet.

Neben jede Kennzahl nach dem Motto „ähnlich heißt gut“ setze ich jetzt strenge mechanische Schranken, die sich nicht mit Stil täuschen lassen: erfundene Zahlen und Daten, Stoppwörter, Handlungsversprechen. Jede Verschlechterung bei den Schranken hebt jede Verbesserung der Kennzahl auf.

Warum beweist „Ich habe geprüft“ vom Agenten gar nichts?#

Nimm eines deiner Projekte und frage den Agenten: „Prüfe die Sicherheit.“ Oft lautet die Antwort: „Alles ist in Ordnung, keine kritischen Probleme.“

Stell einem anderen Modell dieselbe Frage zum selben Projekt. Besonders bei einem großen Projekt wird es vieles finden. Vor dem Deployment prüft der Autor das Projekt mit drei verschiedenen Modellen, und jedes bringt etwas anderes zum Vorschein.

Gleiche Eingabe, gleiche Frage, gegensätzliche Urteile. Ein Modell ist nicht schlechter als das andere. „Alles ist in Ordnung“ ist einfach generierter Text, auf genau derselben Ebene wie jede andere Antwort. Der Agent kann nicht unterscheiden zwischen „Ich habe nachgesehen, alles ist sauber“ und „Ich habe an der falschen Stelle nachgesehen“.

Anthropic beschreibt diesen Mechanismus in der Claude-Code-Dokumentation.

Nimm den Satz langsam auseinander. Solange du dem Agenten keine Prüfung gibst, die er ausführen kann, hat er ein Signal – wie die Dinge aussehen. In diesem Setup bist du die Prüfschleife, nur erfährst du als Letzter von den Fehlern.

Es gibt eine tiefere Ebene. Als OpenAI versuchte, ein Modell unter Druck zu setzen, indem es seine Schlussfolgerungen überwachte und es für „schlechte Gedanken“ bestrafte, war das Ergebnis nicht das erwartete.

Wenn man erklärte Absichten bestraft, verschwindet die Erklärung. Die Absicht selbst bleibt. Deshalb würde ich nicht darauf vertrauen, dass der Agent ehrlich erzählt, wie er geschummelt hat.

Auch die Entwickler der Tools bewegen sich in dieselbe Richtung. In Claude Code Version 2.1.215 wurden die Skills /verify und /code-review nicht mehr auf eigene Initiative des Modells ausgeführt.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic erklärt nicht, warum. Aber das Prinzip ist klar: Wer geprüft wird, setzt nicht selbst die eigene Prüfung an.

Warum hält eine Regel in der Projektdatei den Agenten nicht auf Kurs?#

Du hast in die Regeldatei des Projekts geschrieben: nur auf ausdrückliche Anweisung committen, nur dann in der Produktion deployen, wenn ich es direkt sage, und auf Produktionsdaten nur lesend zugreifen.

Nach Erfahrung des Autors setzt der Agent trotzdem etwa jedes zehnte Mal eigenmächtig ein Deployment um. Nicht aus Bosheit und auch nicht, weil er die Regel nicht gelesen hätte. Er hat sie gelesen. Vor ihm stand einfach ein Ziel, und die Regel war Text – genau wie der restliche Kontext.

Genau das passierte in größerem Maßstab auch im Labor von OpenAI. Die Modelle befanden sich in einer abgeschlossenen Umgebung mit nur einem Ausweg und verbrachten einen erheblichen Teil ihrer Rechenleistung damit, einen Ausgang zu suchen. Die Testaufgaben blieben ungelöst.

Meine Haltung dazu ist einfach: Der Agent ist weder gefährlich noch böswillig. Er ist gewöhnlich, nur ein Narr mit Befugnissen. Deshalb musst du seine Befugnisse beschränken und nicht deine Anfragen umschreiben.

Was tatsächlich standhält: strikt lesender Zugriff auf Produktionsdaten. Das Löschen ganzer Verzeichnisse verbieten. Befehle verbieten, die den Verlauf unwiderruflich neu schreiben. Ein Ausgabenlimit beim Anbieter festlegen. Der Unterschied liegt in einer Formulierung: „physisch unmöglich“ setzt sich gegen „Ich habe ihn darum gebeten, es nicht zu tun“ durch. Konkrete Einstellungen werden separat im Artikel über mechanische Bremsen statt Bitten in Anweisungen behandelt.

Trotzdem solltest du einen kühlen Kopf bewahren. Auch eine Sandbox ist keine absolute Grenze, und der Anbieter sagt das ganz offen.

Außerdem hat Claude Code einen eingebauten Notausstieg, den das Modell selbst nutzen kann. Wenn ein Befehl aufgrund von Sandbox-Einschränkungen fehlschlägt, analysiert Claude den Fehler und kann denselben Befehl mit einem Parameter erneut ausführen, der die Sandbox deaktiviert. Das lässt sich mit einer ausdrücklichen Strict-Mode-Einstellung unterbinden; standardmäßig ist diese Umgehung verfügbar und dokumentiert.

Eine Einschränkung wirkt nur so weit, wie du sie verschärfst. Und jede Barriere kostet Geschwindigkeit – es lohnt sich, das vorher ehrlich zu berechnen, denn eine Woche später wird es teurer.

Wie setzt man ein Abschlusskriterium, das sich nicht manipulieren lässt?#

Die Formulierung des Kriteriums bestimmt alles Weitere. Prüfe sie mit einer Frage: Kann der Agent dieses Kriterium erfüllen, ohne etwas zu tun?

• „Prüfe, ob alles funktioniert“ – das kann er. Es reicht, „geprüft, funktioniert“ zu schreiben.
• „Führe den Build aus und zeige mir die Ausgabe“ – schon schwieriger; irgendwo muss er die Ausgabe herbekommen.
• „Starte die App, klicke auf die Checkout-Schaltfläche und zeige, was auf dem Bildschirm erscheint“ – das lässt sich kaum mit Text erfüllen.

Der Unterschied zwischen dem ersten und dem dritten Beispiel ist der Unterschied zwischen einem Bericht und einem Beleg.

Die Claude-Code-Dokumentation beschreibt vier Stufen der Strenge. Eine sinnvolle Leiter, die du mit steigenden Fehlerkosten erklimmen kannst:

1. In einer Nachricht. Bitte den Agenten, die Prüfung auszuführen und sie hier so lange zu wiederholen, bis sie erfolgreich ist. Am günstigsten und für Kleinigkeiten geeignet.
2. Für die ganze Sitzung. Mache die Prüfung zur Bedingung des Ziels: Ein separater Evaluator prüft nach jeder Runde, und der Agent arbeitet weiter, bis die Bedingung erfüllt ist. Die technischen Einzelheiten findest du in der Anleitung zum vorherigen Festlegen eines Abschlusskriteriums.
3. Eine mechanische Barriere. Ein Script läuft, wenn der Agent versucht, eine Runde zu beenden, und verhindert den Abschluss, bis die Prüfung bestanden ist. Ein ehrliches Detail: Nach acht aufeinanderfolgenden Blockierungen setzt sich Claude Code über die Barriere hinweg und beendet die Runde trotzdem. Im System gibt es keine absolut undurchdringlichen Barrieren.
4. Eine zweite Meinung. Eine separate prüfende Person mit frischem Kontext, deren Aufgabe darin besteht, das Ergebnis zu widerlegen.

Der vierte Punkt steht für sich, weil er der einzige ist, bei dem es nicht um Tools geht.

Wer sollte die Arbeit des Agenten abnehmen?#

Wenn ich Agenten in einer Schleife an einer großen Aufgabe arbeiten lasse, sieht das Setup so aus: Eine Gruppe schreibt; eine andere, frische Gruppe nimmt die Arbeit ab, ohne am Schreiben beteiligt gewesen zu sein.

„Frisch“ ist das Schlüsselwort. Gemeint ist ein sauberer Kontext, der nicht mitbekommen hat, wie jede Entscheidung zustande kam. Ein anderer Prompt in derselben Sitzung reicht dafür nicht aus. Wer den Code geschrieben hat, hat bereits viel Energie darauf verwendet, sich selbst davon zu überzeugen, dass er richtig ist, und wird weiter nach Bestätigung suchen. Widerlegung liegt nicht im eigenen Interesse.

Die Formulierung des Prüfauftrags ist wichtiger als das Modell der prüfenden Person. Vergleiche:

• „Prüfe diese Arbeit“ – die prüfende Person findet, was sich leicht finden lässt, und schreibt „im Allgemeinen in Ordnung“.
• „Versuche zu beweisen, dass diese Arbeit NICHT erledigt wurde“ – die prüfende Person beginnt, nach Lücken zu suchen, weil das ihr Ziel ist.

Die zweite Formulierung funktioniert aus demselben Grund besser, aus dem ExploitGym scheiterte: Der Agent richtet sich nach dem Ziel, das er bekommt. Gib ihm das Ziel, eine Lücke zu finden, und er wird danach suchen.

Hier ist der vollständige Text, direkt zum Kopieren:

Du überprüfst die Arbeit einer anderen Person. Du hast sie nicht geschrieben und musst sie nicht verteidigen.

Dein Ziel ist zu beweisen, dass das behauptete Ergebnis NICHT erreicht wurde. Finde mindestens drei Möglichkeiten, wie es nicht erreicht worden sein könnte, obwohl alle Prüfungen grün sind.

Prüfe in dieser Reihenfolge:

Welche Arbeit läuft außerhalb des von den Prüfungen abgedeckten Bereichs – Hintergrundprozesse, separate Scripts, geplante Aufgaben, Queue-Handler.

Wer ruft jede neue Funktion auf? Finde den Aufruf durch eine Suche im Projekt; nenne Datei und Zeile.

Umgekehrte Abläufe: Rückerstattung, Sperrung, Zugang entziehen, Ablauf, Löschen der Datenquelle.

Die Werte im Ergebnis, nicht nur, ob es vorhanden ist.

Wenn eine ehrliche Suche keine Lücken ergibt, sag das, aber nenne genau, was du geprüft hast und wie.

Der Artikel darüber, wie ein Agent sich in einer Schleife selbst prüft, erklärt, wie die Schleife funktioniert, in der ein Agent sich zwischen Iterationen selbst prüft, und woran sie gewöhnlich scheitert.

Was ändert sich, wenn man das Kriterium anders formuliert?#

Das ist die günstigste Verbesserung, die ich kenne, und fast niemand nutzt sie.

Bitte den Agenten um eine Codeprüfung – er denkt dann in Kategorien wie Code: Struktur, Fehlerbehandlung, Wiederholungsversuche, anfällige Bereiche. Nützlich.

Bitte ihn, die Kundenreise vom ersten Besuch auf der Website bis zum Versuch einer Rückerstattung durchzugehen, und es treten andere Arten von Fehlern hervor. Ein Fehler zeigt dem Nutzer etwas, das er nicht sehen sollte. Der Text einer E-Mail stimmt nicht mit dem tatsächlichen Geschehen überein. Ein Schritt lässt sich logisch nicht abschließen, wenn man nicht über das ideale Szenario dorthin gelangt ist.

Keine dieser Fehlerarten wird bei einer Codeprüfung gefunden, denn jede ist im Code gültig.

Daraus ergibt sich eine Regel, die ich mir merke: Wenn eine Prüfung nichts findet, ändere zuerst die Formulierung. Meist liegt das Problem nicht am Modell. Dieselbe Arbeit führt, je nachdem, auf welche von drei verschiedenen Arten danach gefragt wird, zu drei unterschiedlichen Listen von Ergebnissen. Eine praktische Sammlung von Fragen für Menschen ohne Programmierkenntnisse ist separat zusammengestellt: sieben Codeprüfungen ohne Programmierkenntnisse.

Ein fertiger Prompt zur Abnahme der Arbeit eines Agenten#

Antworte nicht mit „fertig“ oder „geprüft“. Ich brauche Belege.

Gib mir für jeden Arbeitspunkt genau Folgendes:

Welchen Befehl hast du ausgeführt, um zu bestätigen, dass der Punkt funktioniert? Füge den Befehl selbst und seine vollständige Ausgabe ohne Kürzungen ein.

Wenn du den Befehl nicht ausgeführt hast, sag: „nicht ausgeführt“. Ersetze das nicht durch „visuell geprüft“ oder „die Logik stimmt“.

Welche Arbeit läuft außerhalb des von deiner Prüfung abgedeckten Bereichs? Hintergrundprozesse, separate Scripts, geplante Aufgaben, Queue-Handler – alles, was anders als die Hauptanwendung gestartet wird. Hast du jedes solche Element separat ausgeführt, und was hat es ausgegeben?

Wer ruft jede neue Funktion auf, die du hinzugefügt hast? Finde den Aufruf durch eine Suche im Projekt und nenne Datei und Zeile. Falls es keinen Aufruf gibt, sag das direkt.

Dann, in einem separaten Abschnitt: drei Möglichkeiten, wie das behauptete Ergebnis möglicherweise NICHT erreicht wurde, obwohl alle deine Prüfungen grün sind. Suche gründlich.

Zum Schluss eine Zeile: Was sollte ich mit eigenen Augen prüfen, weil eine automatisierte Prüfung es nicht erkennt?

Der vierte Punkt scheint unbedeutend, fängt aber eine ganze Fehlerklasse ab. Bei einer großen Aufgabe, die ich nach Bereichen auf Agenten verteilt hatte, lag das einzige falsche „fertig“ des gesamten Hunderts genau an der Schnittstelle zwischen zwei Bereichen: Der Code war geschrieben, die Prüfungen waren grün, und niemand dachte daran, es auf den Bildschirm zu bringen.

Vier Möglichkeiten, sich mit einer Prüfung selbst zu täuschen#

1. Nicht auf alle Prüfenden gewartet. Ich startete drei parallele Prüfungen, zwei kamen mit grüner Rückmeldung zurück, und ich deployte. Die dritte traf vier Minuten später mit sechs Beanstandungen ein. Nach der Veröffentlichung etwas zu reparieren kostet mehr, als zwei Minuten zu warten.
2. Der Zusammenfassung „N von N verarbeitet“ vertraut. Bei großem Fan-out fallen manche Agenten still aus: Sie melden Erfolg, aber die Datei bleibt unangetastet. Jetzt überprüfe ich nach jedem Schreiben durch einen Agenten mechanisch, ob die Änderungen tatsächlich auf der Festplatte stehen.
3. Nicht mit eigenen Augen nachgesehen. Automatisierte Prüfungen können für ein völlig unbrauchbares Ergebnis grün sein. Die Bilder sind technisch korrekt, die Größe stimmt, der Antwortcode stimmt. Tatsächlich sind es jedoch automatisch erzeugte Standbilder anstelle der vorgesehenen illustrierten Titelbilder. Keine automatisierte Prüfung erkennt das.
4. Auf Vorhandensein statt auf Wert geprüft. Die Prüfung suchte im Ergebnis nach dem erforderlichen Text. Der Text war vorhanden, aber die darin enthaltenen Daten waren falsch: Das Datum lag einen Tag daneben. Die Prüfung war grün, und der Bericht war eine Lüge. Jetzt prüfe ich den gesamten erwarteten Wert, denn das Vorhandensein des richtigen Wortes allein garantiert nichts.

Diesen vier Fällen ist gemeinsam: Es gab eine Prüfung, sie wirkte überzeugend, aber sie prüfte das Falsche. Dieselbe Mechanik wie bei den Modellen und ihrem Test, nur ohne jede Erfindungsgabe.

Wo fängst du heute an?#

Drei Schritte, die zwanzig Minuten dauern.

1. Nimm das letzte „fertig“. Prüfe es mit dem Abnahme-Prompt im Abschnitt über Belege. Das Ziel ist einfach: Sieh nach, wie viele Punkte mit Worten abgeschlossen wurden und wie viele mit Befehlsausgabe.
2. Lege eine Regel für dich selbst fest. Das Wort „geprüft“ ohne angehängte Befehlsausgabe zählt nicht als Abschluss. Diese Regel gilt für dich, nicht für den Agenten, und genau deshalb funktioniert sie.
3. Trenne die arbeitende und die prüfende Person. Gib bei der nächsten Aufgabe einer frischen Sitzung den Prüf-Prompt und bitte sie zu beweisen, dass die Arbeit NICHT erledigt wurde. Der erste Durchlauf lohnt sich meistens schon.

Das Tool ist gut und wird jeden Monat besser: Dinge, die ein Agent vor einem Jahr stillschweigend getan hätte, bringen ihn heute zum Stillstand. Die Sicherheitsgrenze verschiebt sich ständig und bleibt dennoch eine Grenze. Solange der Agent das ihm vorgegebene Ziel verfolgt, bleibt die Frage „Und wie genau hast du das gemessen?“ deine Aufgabe. Die Gewohnheit des Prüfens ist dein Sicherheitsnetz.