Kritisch denken, wenn KI-Agenten die Arbeit machen

TL;DR

Gute Agenten machen selten offensichtliche Fehler. Gerade deshalb liest man ihre Ergebnisse mit der Zeit immer flüchtiger, bis man etwas freigibt, das man nicht mehr erklären kann. Ich verlasse mich deshalb nicht auf meine Tagesform, sondern auf feste Regeln: Belege vor der Zusammenfassung, bei jedem grünen Häkchen die Frage, was es eigentlich geprüft hat, und Fragen an mich nur gebündelt. Wo mir solche Regeln noch fehlen, sage ich das unten auch.

Zweimal „erledigt“, und auf der Seite war nichts passiert

Im September habe ich Browser-Werkzeuge für meine Agenten verglichen. Zwei davon meldeten mehrfach Erfolg, obwohl auf der Seite nichts passiert war: kein Klick, kein ausgefülltes Feld, nur eine Erfolgsmeldung. Hätte ich nur die Meldung gelesen, wäre mir das nicht aufgefallen. Seitdem steht in meinen Projekten eine Regel: Nach jeder Aktion wird der Zustand zurückgelesen, der Exit-Code belegt nichts.

Daran musste ich diese Woche denken, als Addy Osmani einen langen Text auf X veröffentlicht hat: Critical thinking when agents do the work. Er schreibt ausdrücklich als Befürworter von Agenten-Workflows, nicht als Kritiker. Ein Satz ist bei mir hängen geblieben: Auch wer viele Agenten gleichzeitig laufen lässt, hat nur ein Paar Augen für die Ergebnisse.

Ich lasse jeden Tag mehrere Coding-Sessions parallel laufen. Eine Lead-Session koordiniert sie, Prüfungen laufen automatisch, Fragen an mich kommen gesammelt an. Das ist angenehm, und genau da liegt das Problem. Schnelle, gut formulierte und meistens richtige Antworten fordern keinen zweiten Blick ein. Beim Lesen habe ich mich deshalb gefragt, wo ich eigentlich gar nicht mehr prüfe.

Kritisch denken mit KI-Agenten: delegieren, übernehmen, kapitulieren

Osmani beschreibt drei Stufen. Ganz oben steht das Delegieren: Der Agent macht die Arbeit, das Ergebnis bleibt meine Sache. In der Mitte steht das Übernehmen, bei dem die Ausgabe des Werkzeugs zu meinem neuen Ausgangspunkt wird und keine Hypothese mehr ist. Ganz unten steht die kognitive Kapitulation: Die Antwort der KI wird still zu meiner eigenen, und ich spüre kein Bedürfnis mehr, sie zu prüfen.

Den Begriff „cognitive surrender“ haben Steven Shaw und Gideon Nave an der Wharton School geprägt. In ihren Experimenten mit mehr als 1.300 Teilnehmenden bekam eine Gruppe einen Chatbot, der mal richtig und mal überzeugend falsch antwortete. Lag die KI richtig, stieg die Trefferquote um 25 Prozentpunkte über die Gruppe ohne KI. Lag sie falsch, fiel sie 15 Prozentpunkte darunter. Das Selbstvertrauen stieg trotzdem, auch als die KI rund die Hälfte der Zeit falsch lag.

Für meine Arbeit ist ein anderes Ergebnis der Studie wichtiger. Wer für Genauigkeit belohnt wurde und zu jeder Antwort sofort eine Rückmeldung bekam, hinterfragte falsche Antworten deutlich häufiger. Die Bedingungen machen also einen Unterschied. Genau dort setze ich an: Eine Prüfung, die sofort anschlägt, hilft mir mehr als der Vorsatz, beim nächsten Mal genauer hinzuschauen.

Ein grünes Häkchen beweist genau eine Sache

Ein grüner Test sagt, dass dieser eine Test bestanden hat. Das habe ich nicht nur bei den Browser-Werkzeugen gelernt, und inzwischen sind daraus mehrere Regeln geworden.

Ein Prüfskript, das einen Wert nicht messen konnte, meldet bei mir „nicht messbar“ und nicht Grün. Ein gemergter Stand ist noch nicht live, also prüfe ich die Produktivseite gegen das Repo, bevor ich ein Issue schließe. Ein Text, der meinen Stil-Check besteht, ist deshalb noch nicht faktisch richtig. Und eine neue Prüfung zählt erst, wenn ich sie einmal absichtlich rot gesehen habe: Ich baue den Fehler ein, den sie fangen soll, und schaue, ob sie anschlägt. Wie ich daraus begrenzte Arbeitsschleifen baue, steht in Loop Engineering.

Osmani bringt das auf eine Frage, die ich mir merke: Wenn eine Prüfung grün wird, was hat sie bewiesen, und was nicht? Dazu gehört, vorher festzulegen, was „verifiziert“ heißt, weil man hinterher für jedes Ergebnis eine Begründung findet. Bei mir trägt deshalb jeder offene Punkt, den eine Session an die nächste übergibt, ein „Fertig wenn“.

Erst die Belege, dann die Zusammenfassung

Wenn eine Session „fertig“ meldet, lese ich zuerst, welcher Befehl gelaufen ist und was er zurückgegeben hat, und erst danach die Zusammenfassung. In meinen Sessions prüft außerdem ein Review-Agent mit frischem Kontext die Arbeit, bevor sie zu mir kommt. Das steht fest im Ablauf, damit es nicht davon abhängt, ob ich daran denke.

Wie genau das sein muss, habe ich bei diesem Text gemerkt. Eine automatische Recherche meldete mir, dass sich das Zitat zum „Paradox der Aufsicht“ aus Anthropics Studie über die eigenen Engineers nicht bestätigen lasse. Im Original stand es wörtlich. Hätte ich der Zusammenfassung geglaubt, hätte ich eine richtige Quelle gestrichen.

Osmani geht noch einen Schritt weiter, und hier ist er mir voraus. Eine Zusammenfassung, in der alles gut gelaufen ist, zeigt nicht, was der Agent unterwegs entschieden hat: welche Voreinstellung er gewählt hat, was er aus dem Umfang gestrichen hat und welche Anforderung er umgedeutet hat, als zwei sich widersprachen. Er lässt sich diese Entscheidungen deshalb auflisten und fragt am Ende noch: „Habe ich etwas übersehen?“ Meine Abschlussberichte sagen bisher, was erledigt ist, aber nicht systematisch, was dabei für mich entschieden wurde und was keine Prüfung abdeckt. Dafür habe ich mir eine Aufgabe angelegt: Der Abschlussbericht meiner Sessions soll genau diese beiden Abschnitte bekommen.

Die Orchestrierungssteuer

Den ehrlichsten Abschnitt bei Osmani finde ich den über die Menge. Er nennt es „orchestration tax“: den Abstand zwischen dem, was meine Agenten erzeugen, und dem, wofür ich mit meinem Namen geradestehen kann. Wenn fertige Arbeit schneller anfällt, als ich sie durchsehen kann, hilft eine weitere Session nicht. Ab dann wird nicht mehr geprüft, sondern gehofft.

Bei mir hat das zu zwei Regeln geführt. Fragen an mich werden gebündelt, pro Vorgang und Tag höchstens eine, mit Optionen und einer Empfehlung. Und was routinemäßig wiederkehrt, wandert in eine automatische Prüfung, damit es mich gar nicht erst erreicht. Wie das im Alltag aussieht, habe ich in Vom iPhone zur Coding-Session beschrieben, und die Grundsätze dahinter stehen unter Arbeitsweise. Was bei mir ankommt, soll meine Aufmerksamkeit wirklich brauchen.

Was ich vor dem Auftrag noch zu selten mache

Eine von Osmanis Gewohnheiten setze ich am wenigsten systematisch um: Bevor er einen Agenten auf eine nicht triviale Aufgabe setzt, schreibt er auf, was er als Ergebnis erwartet. Die Erwartung darf falsch sein. Sie erfüllt ihren Zweck trotzdem, denn nach einer gut geschriebenen Antwort fällt es schwer, sich überhaupt eine andere Möglichkeit vorzustellen.

Dazu gehört ein Auftrag in eigenen Worten: wer das Ergebnis nutzt, was ausdrücklich nicht dazugehört und woran man erkennt, dass es fertig ist. Osmani nennt die Lücke dahinter „intent debt“. Ein Agent widerspricht einem unscharfen Auftrag selten, er füllt die Lücken selbst und liefert etwas, das fertig aussieht. Sein Rat: Wenn zwei Korrekturrunden nicht reichen, den Auftrag neu schreiben, statt weiter nachzubessern. Das deckt sich mit meiner Erfahrung, dass ein Agent, der im Kreis läuft, meistens einen unklaren Auftrag hat und kein schlechtes Modell.

Wo ich bewusst ganz abgebe

Nicht alles verdient diese Sorgfalt. Ob ein Agent eine Variable umbenennt, eine Liste sortiert oder aus drei ähnlichen Optionen eine Kleinigkeit auswählt, prüfe ich nicht im Detail. Wo ein Fehler billig ist, gebe ich ganz ab, und das ist vernünftig.

Die Grenze ziehe ich dort, wo andere die Folgen tragen: was eine Änderung für Nutzer bedeutet, ob etwas sicher ausgeliefert werden kann, was öffentlich unter meinem Namen erscheint. Das bleibt bei mir, auch wenn ein Agent mir hilft, die Frage durchzudenken. Osmanis Maßstab passt gut: Würde ich darauf wetten, vor der Person, die es danach warten muss?

Was man nicht mehr übt, verlernt man

Anthropic hat für die eigene Studie 132 Engineers und Researcher befragt. Die Studie beschreibt dabei ein „Paradox der Aufsicht“: Um Claude gut zu beaufsichtigen, braucht man genau die Fähigkeiten, die durch zu viel Delegieren verkümmern können. Osmani rät deshalb, einmal im Monat aufzuschreiben, was man nicht mehr selbst macht, und bewusst zu entscheiden, worauf man verzichten will. Die Frage nehme ich mit. Wer eine ganze Flotte von Agenten beaufsichtigt, braucht die Fähigkeit, einen Diff wirklich zu lesen, eher mehr als früher.

Was du morgen ausprobieren kannst

Du musst dafür kein neues System bauen. Schreib vor dem nächsten größeren Auftrag auf, was du als Ergebnis erwartest. Lies nach dem Lauf zuerst, was tatsächlich ausgeführt wurde, und dann die Zusammenfassung. Notiere eine Sache, die der Agent nicht geprüft hat. Und wenn etwas nicht gut genug war, halte den Grund dort fest, wo er beim nächsten Mal automatisch greift: in einer Regel, einem Hook oder einem Test.

Wenn du das systematisch lernen willst, mit Risikoklassen, Prüfprompts gegen die Quelle und Stichproben, findest du das im Kurs KI-Output prüfen, Halluzinationen erkennen auf agenticbuilders.at; der Newsletter dort fasst neue Beiträge aus meiner Praxis zusammen, auch die, in denen etwas nicht funktioniert hat. Warum Prüfen inzwischen der knappere Skill ist als Tippen, steht in Der knappe Skill ist nicht Tippen, sondern Verifikation. Und wenn du das für dein Team aufsetzen willst, erreichst du mich über den Kontakt.