Warum eine Sitzung mit dem Cursor Debugging Tool ins Stocken gerät
Debugging ist eine Schleife: beobachten, Hypothese bilden, ändern, erneut beobachten. Ein Agent, der nur mit Ihren Dateien arbeitet, beherrscht drei dieser vier Schritte. Beobachten kann er nicht. Jedes Mal, wenn Sie einen Stacktrace einfügen oder beschreiben, was Sie auf dem Bildschirm gesehen haben, übernehmen Sie von Hand genau den Schritt, den er nicht leisten kann – und die Qualität der gesamten Schleife ist dadurch begrenzt, wie gut Sie beschreiben.
Deshalb ist die dritte Runde meist schlechter als die erste. Sie sind müde, Ihre Beschreibung wird kürzer, und der Agent argumentiert inzwischen über die Zusammenfassung einer Zusammenfassung.
Die drei Beschreibungen, die einen Agenten in die Irre führen
„Es funktioniert nicht"
Der Agent muss raten, welchen von fünf plausiblen Fehlerfällen Sie meinen.
Meist wählt er den, der sich am leichtesten beheben lässt – und das ist selten Ihrer.
„Es wirft diesen Fehler"
Ein Fehler ist ein Symptom, das nach dem eigentlichen Problem auftritt, oft mehrere Schichten davon entfernt.
Wer die Stelle repariert, an der er geworfen wird, lässt das Symptom verschwinden und den Defekt bestehen.
„Ich habe X schon probiert"
Ohne zu wissen, was X in der Anwendung tatsächlich bewirkt hat, kann der Agent nichts ausschließen.
Also schlägt er X erneut vor, nur in anderer Form.
Was die Schleife schließt
Geben Sie dem Agenten den Beobachtungsschritt, statt ihn selbst zu übernehmen. Das heißt: Etwas bedient die deployte Anwendung so, wie ein Mensch es täte, und meldet zurück, was passiert ist – als Nachweis, nicht als Fließtext.
Die Form dieses Nachweises zählt mehr als sein Umfang. Was versucht wurde, was die Anwendung tatsächlich getan hat und an welcher Stelle beides auseinanderging. Damit kann ein Agent unmittelbar arbeiten. Ein Screenshot und ein Stacktrace müssen weiterhin von einem Menschen interpretiert werden – und damit sind Sie wieder in genau der Schleife, aus der Sie heraus wollten.
Die Einrichtung installiert einen Verifizierungs-Skill direkt in Cursor, sodass es weiß, wie man einen Testfall anlegt, ausführt und das Ergebnis liest, ohne dass Sie den Ablauf jedes Mal erklären müssen.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Dasselbe können Sie im TestSprite Dashboard erledigen. Alles Weitere, was die CLI leistet, finden Sie im CLI-Repository.
Ein Reproduktionsfall zum Weitergeben schlägt jede Beschreibung
Die wirksamste Gewohnheit überhaupt: den Bug nicht mehr zu beschreiben, sondern ihn zu reproduzieren. Ein schriftlicher Testfall nennt die Seite, die geöffnet werden soll, die auszuführenden Schritte und den Zustand, der danach gelten muss. Drei Zeilen davon bringen mehr als drei Absätze Erklärung – weil sie eindeutig sind und weil sie sich erneut ausführen lassen.
Auch das Gespräch mit dem Agenten verändert sich dadurch. Statt „das Dropdown ist kaputt" ist die Eingabe ein Durchlauf, der bis Schritt vier kam und dort die falsche Option ausgewählt vorfand. Es bleibt nichts mehr zu interpretieren.
Schreiben Sie den Testfall vor dem ersten Korrekturversuch, nicht nach dem dritten. Zu diesem Zeitpunkt wissen Sie noch genau, womit Sie den Fehler ausgelöst haben – ein Wissen, das schneller verfliegt, als alle erwarten.
Ein durchgespieltes Beispiel: die Schleife schließt sich
Nehmen Sie einen konkreten Fall. Ein Nutzer meldet, dass die Bearbeitung eines gespeicherten Filters manchmal zurückspringt. Sie beschreiben das, der Agent findet eine Race Condition zwischen zwei State-Updates und schlägt eine Absicherung vor. Sie übernehmen sie, probieren es einmal, es funktioniert, Sie machen weiter. Zwei Tage später kommt die Meldung zurück.
Schiefgegangen ist nicht die Korrektur. Schiefgegangen ist, dass ein einzelner manueller Versuch bei einem sporadischen Bug eine Stichprobe der Größe eins ist – und sporadische Bugs bestehen einen einzelnen Versuch etwa genauso oft, wie sie an ihm scheitern. Die Schleife, die tatsächlich konvergiert, sieht anders aus: Schreiben Sie die Schrittfolge als Testfall auf, führen Sie sie mehrfach aus und lesen Sie die Quote ab. Vier Fehlschläge von zehn sind für den Agenten eine völlig andere Anweisung als „es ist kaputt", weil damit eine ganze Klasse deterministischer Ursachen ausscheidet und der Hinweis auf das Timing zeigt.
Das Zweite, was sich ändert, ist das, was nach der Korrektur passiert. Derselbe Testfall läuft erneut, zehnmal, und entweder geht die Quote auf null oder eben nicht. Sie haben jetzt einen Nachweis statt eines Eindrucks – und der Testfall bleibt in der Suite, sodass die dritte Meldung nie eintrifft.
Die Behauptung, der Sie misstrauen sollten
„Ich habe das Problem behoben" ist der teuerste Satz im agentengestützten Debugging. Er entsteht aus derselben Argumentation, die auch die Änderung hervorgebracht hat, und trägt deshalb keine unabhängige Information. Eine Korrektur ist dann bestätigt, wenn das Verhalten beobachtbar korrekt ist – und der Agent, der sie geschrieben hat, kann diese Bestätigung per Definition nicht liefern.
Das ist keine Kritik am Modell. Ein Mensch, der einen Patch schreibt und ihn dann für korrekt erklärt, ohne irgendetwas auszuführen, bekäme im Review dieselbe Antwort.
Sorgen Sie dafür, dass die Prüfung die Sitzung überdauert
Der Testfall, den Sie zum Reproduzieren des Bugs geschrieben haben, ist nach der Korrektur mehr wert als währenddessen. Behalten Sie ihn und führen Sie ihn bei jeder Änderung aus, damit derselbe Defekt nicht drei Wochen später klammheimlich zurückkommt.
Die GitHub App ist ein Webhook, den Sie im TestSprite Dashboard einrichten. Er lauscht auf das Deployment-Event, das Ihre Pipeline ohnehin erzeugt – in Ihrem Repository ändert sich also nichts.
GitHub Actions bringt den Schritt in Ihren eigenen Workflow, konfiguriert über das Terminal.
Was sich mit einem Verifizierungsschritt in der Schleife ändert
TestSprite liefert die Beobachtung, die der Schleife fehlt. Die Einrichtung installiert einen Verifizierungs-Skill direkt in Cursor, sodass der Agent einen Testfall anlegen, ihn gegen Ihre deployte App ausführen und das Ergebnis lesen kann, ohne dass Sie etwas weitergeben müssen.
Praktisch bedeutet das für eine Debugging-Sitzung: Die Runden wiederholen sich nicht mehr. Der Agent argumentiert nicht länger über Ihre Erinnerung an das Gesehene, sondern hat eine Aufzeichnung davon, was versucht wurde, was die Anwendung getan hat und wo beides auseinanderging. Eine Korrektur, die er vorschlägt, wird von etwas anderem bestätigt als von der Argumentation, die sie hervorgebracht hat – nur so wird aus „Ich habe es behoben" eine Information.
Auch die Reproduktion überdauert die Sitzung. Der Testfall, der den Bug gefunden hat, bleibt in der Suite und läuft bei jeder Änderung mit, sodass derselbe Defekt nicht in sechs Wochen klammheimlich zurückkommt.
Kann Cursor debuggen, ohne die Anwendung auszuführen?
Cursor kann Code analysieren und den Defekt auf diesem Weg oft finden, besonders bei Logikfehlern mit klarer Spur. Bestätigen kann es eine Korrektur nicht, und es sieht keine State-, Timing- oder Integrationsprobleme, die erst beim Ausführen der App auftreten.
Warum kommt derselbe Bug wieder?
Weil die Reproduktion meist im Chat steht und nicht in einem Test. Sobald das Gespräch endet, prüft nichts mehr dieses Verhalten.
Ersetzt das den Debugging-Workflow in Cursor?
Nein. Es liefert den fehlenden Beobachtungsschritt. Cursor schlägt weiterhin die Änderung vor, Sie entscheiden weiterhin, ob sie sinnvoll ist, und die Verifizierung sagt Ihnen beiden, ob sie funktioniert hat.
Wie viel von meinem Code sieht es?
Die Verifizierung läuft über deren Schnittstelle gegen die deployte Anwendung und berichtet damit über Verhalten, statt Ihr Repository zu lesen.
Was ist, wenn der Bug nur in der Produktion auftritt?
Richten Sie einen Durchlauf auf eine Umgebung, in der er sich reproduzieren lässt. Unterscheidet sich das Verhalten zwischen den Umgebungen, ist dieser Unterschied meist der eigentliche Bug – und es lohnt sich, ihm vor der Codeänderung nachzugehen.
Geben Sie dem Agenten Augen, nicht längere Prompts.
Cursor als Debugging Tool gerät ins Stocken, weil nichts in der Schleife die laufende App beobachtet. Liefern Sie diesen Schritt nach, bestehen Sie auf einem Nachweis statt auf einer Erfolgsmeldung, und behalten Sie die Reproduktion als Test, damit die Korrektur hält.