Zwei Debugger in einer Woche. Sie sind sich nicht einig, was Debugging bedeutet.

Montagmorgen. Du tippst einen Prompt in Cursor, Claude Code oder Copilot. Drei Minuten später landet ein Feature in deinem PR — dem Pull Request, den dein Code erstellt, bevor er in den Hauptzweig gemergt wird. CI ist grün. Ticket geschlossen. Dopamin-Kick. Du bist jetzt ein 10x-Entwickler.

Eine Woche später bricht genau dieses Feature um 3 Uhr nachts zusammen. Du öffnest die Datei. Du kannst den Bug nicht nachverfolgen. Du hast diesen Code nicht geschrieben. Das war die KI. Und die hat null Brotkrumen hinterlassen. Du brauchst einen Debugger. Aber nicht alle Debugger meinen heutzutage dasselbe.

Zwei Debugging-Tools kommen in eine Woche

Zwischen dem 14. und 16. April, während der Rest der Branche weiter an schnelleren Code-Generatoren bastelte, haben zwei Tools endlich zugegeben, dass KI-generierter Code anders kaputt geht als handgeschriebener — und andere Werkzeuge braucht, um ihn zu reparieren.

Am 14. April lieferte Cursor 3.1 sowohl einen /debug-CLI-Befehl als auch Background Agents aus, die automatisch PRs aus GitHub Issues erstellen — ein Release, das beide Seiten der Kluft bedient. Am 16. April brachte Visual Studio 18.5 einen agentischen Debugger, der Fehler-Hypothesen generiert und Breakpoints für dich setzt. Parallel dazu lief die Generierungsseite auf Hochtouren: Claude Code launchte Routines am 14. April, und OpenAI aktualisierte Codex am 16. April auf 3 Millionen wöchentliche Nutzer mit Desktop-Computer-Use und über 90 Plugins.

Verhältnis Generierung zu Debugging diese Woche: 3:2 (Cursors Background Agents auf der Generierungsseite, sein /debug auf der Debugging-Seite gezählt). Fortschritt, wenn man die Augen zusammenkneift.

Gleiches Wort, zwei verschiedene Philosophien

Cursors /debug und Visual Studios Debugger-Agent behaupten beide, zu debuggen. Sie tun grundlegend verschiedene Dinge.

Cursors /debug liest deine Terminal-Fehlerausgabe — Stack Traces, gescheiterte Assertions, Compiler-Schreie — korreliert sie mit deinen geöffneten Dateien und dem Projektkontext und generiert dann einen Patch. Unter der Haube ist es ein Re-Prompting mit besserem Kontext. Die KI schluckt den Fehler, rät, was kaputt ist, und gibt Ersatzcode aus. Wenn der Patch nicht hält, promptest du nochmal. Wenn das nicht hält, löschst du die Funktion und generierst von Grund auf neu. Der Workflow optimiert auf Geschwindigkeit: Fehler → Patch → Ausliefern. Dein Job ist, das Ergebnis zu bewerten, nicht den Weg zu verstehen.

Das ist eine legitime Design-Entscheidung. Die Background Agents im selben Cursor-3.1-Release — die in Cloud-Sandboxen laufen und GitHub Issues ohne menschliches Zutun in PRs verwandeln — zeigen die Produktphilosophie glasklar. Der Code ist Wegwerfware, das Ergebnis zählt, Iteration ist billig. /debug ist konsistent mit dieser Weltsicht. Versteh den kaputten Code nicht. Ersetze ihn durch funktionierenden Code. Weiter.

Visual Studios agentischer Debugger setzt auf das Gegenteil. Wenn du einen Bug beschreibst oder eine Exception reinkopierst, generiert der Agent keinen Fix. Er generiert Hypothesen — gerankte Erklärungen dafür, warum der Fehler aufgetreten ist. Dann instrumentiert er deinen Code: setzt bedingte Breakpoints an den Stellen, die jede Hypothese als fehlerhaft vorhersagt, konfiguriert Watch-Ausdrücke für verdächtige Variablen und führt dich Schritt für Schritt durch den tatsächlichen Ausführungspfad.

Microsofts Ankündigung beschreibt, wie der Agent "relevanten Code, kürzliche Änderungen und häufige Fehlermuster" auswertet, um seine Hypothesenliste zu erstellen. Der Debugger tritt dann in eine sogenannte Untersuchungsschleife ein: Breakpoint treffen, Zustand inspizieren, Hypothese bestätigen oder verwerfen, zur nächsten weiter. Du liest keinen KI-generierten Code. Du liest das tatsächliche Verhalten deiner Laufzeitumgebung, geführt von einer KI, die den Suchraum eingrenzt.

Der entscheidende mechanische Unterschied: Cursors /debug operiert auf Text — Quellcode als String, der umgeschrieben wird. Visual Studios Debugger operiert auf Ausführung — Laufzeitzustand als Beweismaterial. Das eine behandelt Code als Dokument. Das andere behandelt Code als Maschine.

Warum der Unterschied tatsächlich wichtig ist

Bei einem Null-Pointer in einer Utility-Funktion ist er es nicht. Cursors /debug patcht das in Sekunden. Visual Studios Debugger wäre Overkill.

Aber KI-generierte Bugs sind normalerweise keine Null-Pointer. Die Studienlage verdichtet sich — GitClears Code-Qualitätsdaten, diverse akademische Replikationen — und zeigt, dass KI-co-verfasster Code signifikant mehr Logikfehler und Performance-Probleme mitbringt als handgeschriebener Code. Die Bugs, die zählen, sind keine Syntaxprobleme. Es sind subtile Verhaltensabweichungen: Ein API-Handler, der in Tests funktioniert, aber unter gleichzeitigen Requests doppelt schreibt. Eine Datenbankabfrage, die bei kleinen Datensätzen korrekte Ergebnisse liefert, aber bei Skalierung O(n²)-Joins erzeugt. Eine State Machine, die den Happy Path abdeckt, aber bei Retries stillschweigend Daten korrumpiert.

Diese Bugs melden sich nicht im Terminal-Output. Sie zeigen sich als schleichende Degradation, sporadische Ausfälle, Dateninkonsistenzen, die erst Tage später an die Oberfläche kommen. Cursors /debug braucht eine Fehlermeldung als Input. Was fütterst du rein, wenn das Symptom lautet: "Checkout-Umsatz ist am Dienstag um 4% gefallen und keiner weiß warum"?

Visual Studios hypothesengetriebener Ansatz handhabt das anders. Du beschreibst das Symptom. Der Agent schlägt mögliche Ursachen vor — vielleicht berechnet die Payment-Retry-Logik doppelt, vielleicht gibt es eine Race Condition zwischen Bestandsprüfung und Warenkorb-Update, vielleicht schneidet die Rabattberechnung ab statt zu runden. Er setzt Breakpoints an jeder verdächtigen Stelle. Du reproduzierst das Szenario und beobachtest, wie der Ausführungspfad enthüllt, welche Hypothese stimmt.

Langsamer? Enorm. Erfordert Gehirneinsatz? Leider ja. Aber es ist das einzige Tool, das diesen Monat erschienen ist und Debugging als Ermittlung behandelt — nicht als eine weitere Runde Generierung.

Der Workflow-Split

Hier gabelt sich die Branche.

Pfad A: Cursors Modell. Code ist billig. Debugging ist Regenerierung. Wenn etwas kaputt geht, wirf es weg und prompte nochmal. /debug macht diese Schleife enger. Background Agents machen sie autonom. Der logische Endpunkt ist Code, den niemand jemals liest — generiert, getestet, deployt und von Maschinen in einer Endlosschleife ersetzt. Entwickler werden zu Produktmanagern, die Absichten beschreiben und Ergebnisse bewerten.

Pfad B: Visual Studios Modell. Code ist Infrastruktur. Debugging ist Verstehen. Wenn etwas kaputt geht, versteh warum, bevor du es fixst, weil derselbe strukturelle Fehler in der nächsten Generation wieder auftaucht, wenn du es nicht tust. Der logische Endpunkt sind Entwickler, die insgesamt weniger Code verstehen, ihn aber tiefer verstehen — Spezialisten für Systemverhalten statt Syntax-Produktion.

Keiner der beiden Pfade ist dumm. Aber sie sind inkompatibel in derselben Codebase. Ein Team, das durch Regenerierung debuggt, baut kein institutionelles Wissen darüber auf, wie sein System tatsächlich funktioniert. Ein Team, das durch Untersuchung debuggt, verbringt Zeit, die Regenerierungs-Teams als Verschwendung bezeichnen.

Ratet mal, welcher Ansatz gewinnt

Cursors, natürlich. Er ist schneller. Er erfordert weniger Denken. Er passt zum Vibe-Coding-Workflow, den die Branche einhellig umarmt hat. Löschen, neu prompten, ausliefern, wiederholen. Nachforschung ist das Problem von jemand anderem — bis die Produktion brennt und "jemand anderes" du um 3 Uhr nachts bist, wie du auf drei Services starrst, die drei verschiedene Prompts geschrieben haben, und dabei zuschaust, wie deren Zusammenspiel den Checkout crasht.

Du kannst dich nicht aus einem verteilten Systemausfall rausprompten. Du brauchst jemanden, der die Ausführungspfade kartiert hat. Und wenn deine Debugging-Kultur "ersetzen bis grün" lautet, existiert diese Person in deinem Team nicht.

Visual Studios Ansatz ist schwerer zu verkaufen. "Lass mich dir beim Denken helfen" verliert gegen "lass mich das für dich fixen" — in jeder Demo, jedem Tweet, jedem Hype-Zyklus. Aber Verstehen hat Zinseszins-Effekt. Regenerierung nicht.

Der unangenehme Teil

Die Frage ist nicht, welcher Debugger besser ist. Die Frage ist, welche Debugging-Philosophie dein Team verfolgt — und ob ihr bewusst gewählt habt oder einfach zu dem Tool gegriffen habt, das schneller ist.

Wenn dein Stack aus zustandslosen Funktionen und kurzlebigen Services besteht, ist Cursors Regenerierungsschleife möglicherweise tatsächlich ausreichend. Ersetze das kaputte Lambda. Weiter. Niemand muss eine Funktion verstehen, die einen Release-Zyklus lang lebt.

Wenn dein Stack Zustand hat, verteilte Transaktionen hat, Verhalten hat, das aus der Interaktion von Komponenten emergiert — dann muss jemand die Laufzeitumgebung verstehen. Nicht den Quelltext. Die Laufzeitumgebung. Visual Studios Debugger ist das erste KI-Tool, das anerkennt, dass dieser Job existiert.

Montagmorgen tippst du den nächsten Prompt. Irgendetwas wird kaputt gehen. Die Frage ist nicht ob du debuggst. Die Frage ist, ob Debugging "nochmal generieren" oder "verstehen warum" bedeutet. Entscheide dich bewusst. Der Default ist Regenerierung. Und um 3 Uhr nachts sind Defaults alles, was du hast.