Wenn die KI ihr eigenes Review filmen muss

Wenn ein Pull Request aufgemacht wird, mein eigener oder einer, den ich für einen Kollegen reviewen soll, sind das die Zeilen, die ich in den Agenten einfüge:

Jetzt reviewen wir diesen hier: [GitHub-Link des PR einfügen]

Aber ich will, dass du ihn lokal E2E laufen lässt und schaust, ob alles gut läuft, und Playwright-Aufnahmen davon machst. Ich will auch, dass du ihn angreifst, versuchst, ihn kaputtzumachen, UND ihn gründlich testest [hier bei Bedarf mehr Kontext ergänzen, z. B. sowohl im persönlichen als auch im Org-Scope].

Dann lasse ich ihn arbeiten: Er lässt die Änderung auf meinem Rechner End-to-End laufen, und Playwright nimmt dabei den Browser auf. Playwright ist eine Bibliothek zur Browser-Automatisierung, die der Agent steuern kann, und sie kann die Seiten filmen, die sie öffnet. Zurück kommt ein schriftlicher Bericht, daneben die Aufnahmen und Screenshots der Momente, auf die er verweist.

Seit ich im Juli darüber geschrieben habe, wann das Lesen von KI-Code kein Review ist, hat sich viel verändert, auch, wie ich Pull Requests reviewe. Diese Form des Reviews hat mich in letzter Zeit beeindruckt, und ich glaube, die meisten Entwickler wären überrascht, wie gut sie geworden ist.

Was ich im Juli gesagt habe und was sich geändert hat

Damals ging es mir darum: Wenn der Agent den Code für dich laufen lässt, verschwindet das Review nicht. Es verschiebt sich zum Beleg, und als Gegenmittel habe ich empfohlen, die Logs selbst zu öffnen und darin zu finden, was laut Agent dort stehen sollte.

Dieses Gegenmittel wirkt noch immer, aber meistens brauche ich es nicht mehr. Im Juli habe ich auch geschrieben, zur langsamen Art von Review gehöre, es laufen zu lassen, es nachzuverfolgen und zu versuchen, es kaputtzumachen, und den Agenten seine Arbeit zeigen zu lassen. Neu ist ein Weg, all das in einer einzigen Nachricht zu verlangen und die Arbeit in einer Form zurückzubekommen, die ich prüfen kann, ohne sie selbst zu wiederholen. Den Lauf übernimmt der Agent, und die Aufnahmen zeigen mir, was auf dem Bildschirm passiert ist.

Die Modelle neigen zur schnellsten Antwort. Fragst du sie, ob eine Änderung funktioniert, sagen sie lieber ja, als nachzusehen, und ich habe auch schon erlebt, wie eines von ihnen Logs beschrieb, die es nicht gab. Eine Antwort, die fertig klingt, ist der kürzeste Weg, den eigenen Zug zu beenden.

Das ist nicht nur meine Erfahrung. Die System Card, die Anthropic für Claude Opus 4.8 veröffentlicht hat, listet Fehler aus dem Einsatz im eigenen Haus auf, und einer davon trifft fast genau meinen Fall. Das Modell behauptete, es babysitte gerade die Pull Requests eines Forschers, obwohl es das nicht tat. Dieselbe Liste hält fest, wie es behauptete, etwas überprüft zu haben, das es nicht überprüft hatte.

Einem Modell zu sagen, es solle sorgfältiger sein, ist eine Bitte, und eine Bitte ist das, was es auslässt, wenn es in Eile ist. Eine Aufnahme ändert, was das Modell abliefern muss.

Warum sich eine Aufnahme schwerer fälschen lässt

Einen Satz darüber, was passiert ist, kann man schreiben, ohne dass irgendetwas passiert. Eine Aufnahme setzt voraus, dass tatsächlich etwas gelaufen ist, und was auch immer gelaufen ist, sehe ich auf dem Bildschirm und kann es beurteilen.

Wenn der Agent sich filmen muss, während er die Änderung laufen lässt, erfüllt er die Bitte am billigsten, indem er den Lauf tatsächlich durchführt. Für alles, was vor der Kamera passiert, gibt es keinen Platz mehr, an dem ein selbstsicherer Absatz die Arbeit ersetzen kann. Für sich allein ist ein Bericht die einzige Darstellung dessen, was passiert ist, und einen Test von einem Satz über einen Test kann ich nur unterscheiden, indem ich ihn selbst wiederhole. Die Aufnahme trennt den Satz vom Ereignis. Sagt der Agent, er habe das leere Formular getestet, dann ist das leere Formular im Video oder eben nicht. Was im Bericht steht und nie vor die Kamera kam, ist wieder eine bloße Behauptung.

Der Film zeigt, was der Agent versucht hat, und was darin fehlt, markiert, wofür ich keinen Beleg habe: die Ansicht, die er nie geöffnet hat, das Formular, das er nie mit ungültigen Eingaben abgeschickt hat, das zweite Konto, in das er sich nie eingeloggt hat.

Es gibt einen zweiten Effekt, und der ist genauso wichtig. Vor der Kamera ist es für den Agenten keine sichere Abkürzung mehr, so zu tun, als sei ein Problem nie aufgetreten, oder eines zu erfinden, denn das Video ist da und lässt sich überprüfen. Wenn er also eins findet, macht er mich darauf aufmerksam, statt es in der Zusammenfassung zu vergraben.

Damit das alles funktioniert, muss ich mir selten ein ganzes Video ansehen. Der größte Teil der Wirkung entsteht, bevor ich irgendetwas öffne, denn erst die Bitte um den Film bringt den Agenten dazu, den Lauf überhaupt durchzuführen. Was ich mir tatsächlich ansehe, sind die Screenshots der Momente, auf die es ankommt, und dazu gehören auch die Erfolge. Ich sehe den Ablauf gern so enden, wie er soll, in jedem Scope, nach dem ich gefragt habe, genauso wie den Fehler auf dem Bildschirm oder eine Seite, die sich für ein Konto geöffnet hat, das sie nie hätte erreichen dürfen. Das Video steht dahinter bereit, falls ein Screenshot eine Frage aufwirft.

Der Bericht wird zum Verzeichnis der Belege, und das ist eine bessere Aufgabe für eine Zusammenfassung, als die Belege zu ersetzen. Ich frage weiterhin "stimmt das", aber jetzt beantwortet das ein Screenshot, schlimmstenfalls ein kurzes Stück Video, und mehr meiner Zeit fließt in die Frage "ist das wichtig".

Wenn es darauf ankommt, was der Server geantwortet hat, lohnt es sich, zusätzlich zum Video nach dem Trace von Playwright zu fragen. Das Video, das sind die Pixel. Ein Trace hält für jede Aktion einen Snapshot der Seite davor und danach fest, dazu die Netzwerk-Requests, ihre Response-Bodys und die Browser-Konsole. Sagt der Agent, der Server habe mit einem 403 geantwortet, dann steht die Antwort im Trace.

Playwright MCP von Microsoft, eines der Werkzeuge, mit denen ein Agent einen Browser steuern kann, arbeitet nicht über Pixel, sondern über den Accessibility Tree der Seite, eine strukturierte Textansicht von ihr. Der Film ist für mich, und deshalb ist er nützlich: Der Agent arbeitet mit einer Textansicht der Seite, und der Film zeigt mir die Pixel, auf die er nicht geschaut hat, ohne dass sein Kommentar darüberliegt. Der Agent kann immer noch auswählen, welchen Take er mir gibt, oder einen Ablauf so lange wiederholen, bis er grün durchläuft, deshalb lohnt es sich, nach jeder Aufnahme zu fragen, die er gemacht hat, misslungene Takes eingeschlossen.

Angreifen und testen

Der Prompt verlangt zwei Dinge, die in verschiedene Richtungen ziehen, und zwar mit Absicht.

Ein Modell, das bestätigen soll, bestätigt in der Regel. "Schau, ob alles gut läuft" lädt es ein, nach Dingen zu suchen, die gut laufen, also geht es den Pfad, für den das Feature gebaut wurde, sieht die erwartete Ansicht und meldet Erfolg. Diesen Lauf auf Film zu haben lohnt sich, denn ein Grün ohne Beleg dahinter ist genau die Behauptung, vor der der Juli-Beitrag gewarnt hat. Aber er deckt nur den Fall ab, den der Autor ohnehin im Kopf hatte.

Bitte es, die Sache kaputtzumachen, und es muss woanders suchen: ein Pflichtfeld, das leer bleibt, zweimal auf Absenden geklickt, dieselbe Seite in zwei Tabs offen, die ID in der Adresszeile durch eine ersetzt, die jemand anderem gehört, mitten in einem Ablauf auf Zurück gedrückt. An solchen Stellen verstecken sich Bugs gern.

Ein Agent, der nur Dinge kaputtmachen soll, hat das umgekehrte Problem. Er kann die ganze Session an einem cleveren Grenzfall verbringen und nie bestätigen, dass der normale Ablauf, der, den jeder Nutzer durchläuft, noch End-to-End funktioniert. Ich will den Rundgang durch den normalen Ablauf und den Angriff darauf im selben Lauf, deshalb steht das UND in Großbuchstaben.

Die beiden Anweisungen funktionieren auf Film auch besser als in einem schriftlichen Bericht. Ein Satz wie "Ich habe versucht, es kaputtzumachen, und es ging nicht" sagt mir nichts darüber, wie sehr sich der Agent bemüht hat, und die Aufnahme der Versuche sagt mir viel. Ich sehe, ob er einmal am Formular gerüttelt und dann weitergemacht hat oder ob er mit einem anderen Konto oder einer anderen Reihenfolge der Schritte zurückgekommen ist. Die Angriffe, die gescheitert sind, gehören zum Beleg, dass die Änderung hält.

Die Zeile, die nur ich schreiben kann

Der letzte Teil des Prompts ist ein Platzhalter, der sich mit jedem Pull Request ändert. Dort sage ich dem Agenten, wo das Risiko liegt.

Mein eigenes Beispiel ist "sowohl im persönlichen als auch im Org-Scope". Wenn ein Feature in einem persönlichen Konto und innerhalb einer Organisation funktionieren muss, sitzt das meiste, was schiefgehen kann, in der Naht zwischen beiden: etwas, das zu einem Scope gehört, taucht im anderen auf, oder eine Seite funktioniert für den Eigentümer und scheitert bei einem Mitglied. Der Agent kann den Diff lesen und Vermutungen darüber anstellen. Er weiß nicht, welche Pfade die Nutzer tatsächlich gehen oder welcher Fehler peinlich wäre und welcher ernst. Ich schon, weil ich das Produkt kenne und weiß, was ich von ihm will.

Diese Klammer ist mein Teil des Reviews. Sie lenkt den Agenten weg von dem, was der Diff nahelegt, hin zu dem, wovon ich weiß, dass es Schaden nehmen kann, und die Aufnahme zeigt mir, ob er tatsächlich dorthin gegangen ist.

Was der Film nicht zeigt

Der Film hat seine Grenzen.

Der Agent wählt aus, was er filmt: die Pfade, die er geht, und je nach Werkzeug auch, wann die Aufnahme beginnt und endet. Wenn der Org-Scope, nach dem ich gefragt habe, nicht auf dem Band ist, habe ich keinen Beleg, dass er getestet wurde, was auch immer im Bericht steht.

Alles, was Playwright aufnimmt, passiert im Browser. Server-Logs, die Zeilen in der Datenbank und der Hintergrundjob, der eine Minute später läuft, sind weder im Video noch im Trace. Eine Ansicht kann grün werden, während darunter eine Zeile im falschen Konto gelandet ist. Auf dem Server kann eine Autorisierungsprüfung fehlen, während die Oberfläche den Button vor der Kamera perfekt versteckt, und die API dahinter würde den Request trotzdem von jedem annehmen, der ihn direkt schickt.

Hier macht sich die Angriffshälfte des Prompts bezahlt. Ein Film vom Happy Path berührt diese Prüfung nie, ein Film, in dem der Agent einen Datensatz öffnet, der zu einem anderen Konto gehört, oder den Request bei verstecktem Button schickt, dagegen schon. Bei allem, was den Zugriff berührt, lohnt es sich, diesen Angriff in der Kontextzeile zu nennen. Wenn die Änderung bis zur Datenbank oder zum Server reicht, gehören die Queries und die Logs aus demselben Lauf neben die Aufnahme, gespeichert dort, wo der Bericht auf sie verweisen kann.

Eine Aufnahme kann auch aus dem falschen Grund richtig aussehen. Hat der Agent das Backend durch einen Stub ersetzt, damit die Seite lädt, dann ist die Aufnahme eine Aufnahme des Stubs. Der Prompt verlangt lokal und End-to-End, und womit die App tatsächlich gesprochen hat, ist wichtiger als alles, was sie gezeigt hat. Die Netzwerk-Requests im Trace beantworten das.

Ein praktischer Hinweis: Ein Playwright-Video wird erst auf die Platte geschrieben, wenn der Browser-Kontext geschlossen wird. Sagt der Agent, er habe den Lauf aufgenommen, und die Datei fehlt oder ist leer, dann ist auch das ein Beleg.

Innerhalb dieser Grenzen ist der Film die langsame Art von Review aus dem Juli, wobei der Agent die Läufe übernimmt und das Urteil bei mir bleibt.

Noch immer meine Entscheidung

Die Modelle sind viel besser geworden, seit ich den Juli-Beitrag geschrieben habe, und mein Beleg dafür sind meine eigenen Reviews. Mir fällt auf: Wenn der Agent die Sache laufen lassen und filmen muss und etwas kaputtgeht, dann sagt er das, und ich kann es mit eigenen Augen sehen. Auch die Verbesserung glaube ich ihm nicht einfach aufs Wort.

Entwickler, die KI-Review nur als Bot kennen, der Kommentare in einem Diff hinterlässt, haben die kleinste Version davon gesehen. Das hier ist eher ein Tester an meinem Rechner, der es sich leicht machen würde, wenn ich ihn ließe: Er benutzt die Änderung so, wie ein Nutzer es täte, versucht, sie kaputtzumachen, und lässt das Band da, damit ich sehen kann, wo er es sich leicht gemacht hat.

Den Code zu lesen ist weiterhin wichtig, und die Aufnahme deckt ab, was Lesen nicht erreicht: das Verhalten der Sache, sobald sie läuft. Umsonst ist das nicht. Ein Lauf dauert länger als das Lesen, die App braucht Daten, gegen die sich das Testen lohnt, und irgendjemand muss sich immer noch ansehen, was zurückkommt.

Nichts davon macht den Agenten zum Reviewer. Er erledigt die Fleißarbeit. Am Ende bin immer noch ich derjenige, der entscheidet, was richtig ist und was ich will. Wenn die Aufnahme einen Ablauf zeigt, der funktioniert, aber nicht das ist, was das Produkt tun soll, kann der Agent das nicht wissen, und wenn er gewolltes Verhalten als Bug markiert, bin ich es, der das klarstellt.

Der Juli-Beitrag endete mit der Linie zwischen dem Diff, den du verstanden hast, und dem Diff, den du nur gesehen hast. Die Aufnahmen machen es billiger, auf die verstandene Seite dieser Linie zu kommen. Ich muss mir nicht jeden Lauf ganz ansehen, sondern nur die Momente sehen, auf die es ankommt, und wissen, welche Pfade das Band abdeckt. Geändert hat sich, dass ich die Maschine inzwischen ihre Arbeit filmen lasse, und so gilt meine Aufmerksamkeit weniger der Frage, ob sie getan hat, was sie gesagt hat, und mehr der Frage, ob sie an den richtigen Stellen nachgesehen hat. Beurteilen kann ich das nur, weil ich weiß, wofür das Produkt da ist, und wenn sie an den falschen Stellen sucht, schicke ich eine weitere Zeile Kontext und lasse sie noch einmal laufen.