Fast jeder verfällt bei der Arbeit mit Coding-Agenten in ein bestimmtes Muster, das leise den ganzen Sinn ihres Einsatzes untergräbt. Der Agent erstellt eine Änderung, und Sie stellen die naheliegende Frage: „Funktioniert das?" Der Agent sagt Ja. Sie glauben ihm, weil es überzeugend klingt und meist auch stimmt. Und hin und wieder liegt er selbstbewusst und vollkommen falsch — und Sie merken es erst in der Produktion.
Das Problem ist nicht, dass der Agent lügt. Das Problem ist die Frage.
Warum „Funktioniert das?" die falsche Frage ist
Wenn Sie einen Agenten fragen, ob seine eigene Änderung funktioniert, bitten Sie ihn, sein Ergebnis mit genau der Logik zu bewerten, die es hervorgebracht hat. Er korrigiert seine eigene Arbeit mit demselben Stift. Hat er beim Schreiben des Codes einen Grenzfall übersehen, wird er denselben Grenzfall auch bei der Beurteilung übersehen, denn es ist nichts Neues hinzugekommen — dasselbe Modell, derselbe Kontext, dieselben blinden Flecken.
Schlimmer noch: Sprachmodelle neigen zur Zustimmung. Formulieren Sie die Frage als „Das behandelt Null-E-Mails doch korrekt, oder?", dann haben Sie keine Einschätzung erbeten, sondern eine Schlussfolgerung geliefert und den Agenten eingeladen, sie zu bestätigen. Das wird er in der Regel auch tun. Was Sie zurückbekommen, ist keine Verifizierung. Es ist ein sehr geschmeidiges Echo Ihrer eigenen Hoffnung.
Fordern Sie stattdessen Beweise
Die Korrektur ist klein, verändert aber alles: Bitten Sie den Agenten nicht länger zu behaupten, dass die Änderung funktioniert, sondern es Ihnen zu zeigen. Ein Beweis ist ein Artefakt, das Sie selbst überprüfen können — hervorgebracht vom System, nicht von der Meinung des Agenten über das System. Nicht jeder Beweis ist gleichwertig — es gibt eine grobe Hierarchie:
- Ausführungsbeweis ist der stärkste: Der Agent hat den Code tatsächlich ausgeführt und zeigt Ihnen die echte Ausgabe — den Test, der bestanden hat, den Befehl, der das zurückgegeben hat, was er sollte.
- Vorher-Nachher-Beweis ist fast ebenso gut: eine konkrete Veränderung im beobachtbaren Zustand. Die Anzahl der Abfragen sank von 47 auf 2; die zuvor fehlschlagende Anfrage liefert jetzt 200 zurück.
- Ein vom Agenten geschriebener Test ist schwächer, denn derselbe blinde Fleck, der den Fehler übersehen hat, kann ihn auch im Test übersehen — aber ein Test, den Sie lesen und ausführen können, ist immer noch weit besser als eine Behauptung.
- Eine mündliche Erklärung ist am schwächsten. Manchmal ist das alles, was Sie bekommen können, aber „So war meine Überlegung" ist kein Beweis; es ist genau das, was ein Beweis eigentlich überprüfen soll.
Der Schritt ist in jedem Fall derselbe: Verwandeln Sie die Ja/Nein-Frage in die Bitte um etwas Beobachtbares.
So sieht das in der Praxis aus
Fragen Sie nicht „Wird diese Migration Null-E-Mails korrekt behandeln?", sondern bitten Sie den Agenten, eine Zeile mit einer Null-E-Mail anzulegen, die Migration auszuführen und Ihnen die Ausgabe zu zeigen. Fragen Sie nicht „Hat das die N+1-Abfrage behoben?", sondern bitten Sie ihn, Query-Logging hinzuzufügen, den Endpunkt aufzurufen und Ihnen die Anzahl vorher und nachher zu zeigen. Fragen Sie nicht „Setzt sich der Rate-Limiter zurück?", sondern bitten Sie ihn, das Limit zu erreichen, zu warten, es erneut zu versuchen und Ihnen die erfolgreiche Anfrage zu zeigen. In jedem Fall haben Sie eine Behauptung, der Sie vertrauen müssten, durch ein Ergebnis ersetzt, das Sie lesen können.
Deshalb läuft unser Agent in einer Sandbox
Beweise funktionieren nur, wenn der Agent tatsächlich Dinge ausführen kann, und das ist eine bewusste Designentscheidung, kein nachträglicher Einfall. Jeder TaskGoblin-Lauf findet in einer Sandbox statt, in der das Repository geklont und die Toolchain verfügbar ist — der Agent überlegt also nicht nur, was der Code tun würde, sondern kann Tests ausführen, Befehle ausführen und das tatsächliche Ergebnis beobachten. Wenn er einen Merge Request überprüft, verweisen seine Befunde auf konkretes Verhalten, und wenn Sie mit @taskgoblin fix antworten, ist die Änderung eine, die er tatsächlich prüfen kann, statt nur dafür zu argumentieren.
Das ist auch der Grund, warum sich eine gute Entwicklungsumgebung heute mehr auszahlt als je zuvor. Ein Agent, der Ihre Dienste hochfahren, Seed-Daten laden und Ihre Testsuite ausführen kann, kann echte Beweise liefern; ein Agent, der nur den Code lesen kann, kann Ihnen nur eine Meinung geben. Je ausführbarer Ihr Projekt ist, desto mehr von der Ausgabe des Agenten können Sie überprüfen, statt sie einfach zu glauben.
Die Ein-Satz-Version
Fragen Sie einen Agenten nicht, ob seine Arbeit korrekt ist. Bitten Sie ihn, es Ihnen zu zeigen — und bevorzugen Sie die Arten des Zeigens, die Sie selbst überprüfen können. Der Agent, der den Code ausführt und Ihnen die Ausgabe übergibt, tut das eine, was der Agent, der nur für den Code bürgt, niemals kann: Er gibt Ihnen etwas zu glauben, das nicht nur sein eigenes Selbstvertrauen ist.
