Was ist KI-Debugging?

Am 9. September 1947 entdeckten Ingenieure des Harvard Mark II-Computers eine Motte in einem seiner Relais und klebten sie in ihr Logbuch – „erster tatsächlicher Fall eines gefundenen Bugs“ –, eine Seite, die sich heute im Smithsonian befindet.¹ Die Informatikerin Grace Hopper vom Mark II-Team machte die Geschichte bekannt, obwohl der Begriff schon vor ihrer Zeit existierte: Thomas Edison beklagte sich in einem Brief von 1878 über „Bugs“, und das Oxford English Dictionary lässt diese Verwendung des Begriffs in der Ingenieurssprache auf die 1870er und 1880er Jahre zurückführen.²

Technische Fehler lassen sich in der Regel in drei Typen einteilen.³ Syntaxfehler verletzen die Grammatik einer Programmiersprache (ein Beispiel wäre eine fehlende Klammer) und werden erkannt, bevor das Programm ausgeführt wird. Laufzeitfehler treten auf, wenn gültiger Code während der Ausführung fehlschlägt, etwa beim Teilen durch Null. Logikfehler sind am heimtückischsten: Das Programm läuft ohne Beschwerden, gibt aber die falsche Antwort.

Entwickler können mit automatisierten Tests – Unit-Tests, die jedes kleine Codefragment auf die erwarteten Ergebnisse überprüfen – und mit Debuggern, die ein laufendes Programm zur Überprüfung anhalten, gegensteuern. Ein Breakpoint – eine markierte Zeile, an der die Ausführung stoppt – ermöglicht es dem Entwickler, das Programm durchzugehen und Variablen zu untersuchen. Das integrierte PDB von Python ist ein typisches Beispiel. Ein vollständiger Absturz erzeugt üblicherweise einen Stack-Trace – eine Auflistung der Funktionsaufrufe, die zum Fehler geführt haben.⁴

Eine Studie der Cambridge Judge Business School aus dem Jahr 2013 schätzte, dass Entwickler im Durchschnitt die Hälfte ihrer Programmierzeit damit verbringen, Fehler zu finden und zu beheben, was weltweit etwa 312 Milliarden Dollar pro Jahr kostet.⁵ KI-gestütztes Debugging verspricht natürlich, diese Kosten zu senken.

Ein LLM ist ein System für maschinelles Lernen, das anhand riesiger Mengen an Text und Code trainiert wird, um das nächste „Token“ (Wort, Wortteil oder Symbol) vorherzusagen – die gleiche Technologie zur Verarbeitung natürlicher Sprache, die auch hinter KI-Chatbots wie ChatGPT oder Claude steckt. Im Training „liest“ es effektiv Milliarden von Zeilen öffentlichen Codes sowie zugehörige Fehlermeldungen, Fehlerberichte und Fixes. Bis ein LLM auf den Markt kommt, hat es wahrscheinlich Millionen von Bugs gesehen und ihre Lösungen verdaut. 

Dokumentierte Open-Code-Trainingsdaten umfassen GitHub-„Issue“- und „Pull Request“-Gespräche – Datensätze, in denen Entwickler Fehler und Fehlerbehebungen melden –, die speziell geschulten Modellen Zugang zu einer Papierspur geben, die zeigt, wie fehlerhafter Code von menschlichen Programmierern repariert wird.

In einem typischen KI-Debugging-Workflow gibt der Entwickler dem Modell den relevanten Code und die Fehlermeldung oder den Stacktrace; das Modell erklärt dann die wahrscheinliche Ursache und schlägt mögliche Korrekturen vor. Forschungssysteme wie ChatDBG gehen noch einen Schritt weiter und verbinden LLMs mit Standard-Debuggern wie GDB, LLDB und Pythons pdb, sodass ein Entwickler Fragen in einfacher Sprache stellen kann – „Warum ist x null?“ – während das Modell das laufende Programm untersucht, eine Ursachenanalyse durchführt und Korrekturen vorschlägt.⁶

Es gibt einige Einschränkungen, die Neulinge im Bereich KI-Debugging beachten sollten. Erstens ist der Kontext wichtig – eine Praxis, die mit Prompt Engineering verbunden ist. Unklare Prompts führen eher zu unklaren Diagnosen; hilfreicher ist es, den genauen Fehler, den fehlgeschlagenen Test und den verdächtigen Codeabschnitt anzugeben. Benutzer müssen sich auch über das Kontextfenster eines Modells im Klaren sein: die maximale Textmenge (gemessen in „Tokens“ oder Blöcken von jeweils wenigen Zeichen), die ein Modell gleichzeitig berücksichtigen kann. Echte Fehler in komplexen Codebasen erstrecken sich oft über mehrere Dateien, wie der SWE-bench-Benchmark realer GitHub-Issues zeigt, und ein Modell, das nicht den gesamten relevanten Code in seinen Kontext einbeziehen kann, hat möglicherweise Schwierigkeiten, dies logisch Durchzudenken.

KI-Debugging erfolgt meist über KI-Codierungsassistenten, die in den Coding Workspace des Entwicklers eingebettet oder darum herum aufgebaut sind – in der Regel eine integrierte Entwicklungsumgebung (oder IDE). GitHub Copilot zum Beispiel ist ein Codierungsassistent, der Code in beliebten IDEs vorschlagen kann; Cursor und Windsurf sind KI-orientierte Coding Workspaces, die ähnliche Unterstützung näher ins Zentrum des Programmiererlebnisses bringen. ⁷ Angesichts dessen, dass der Aufstieg des „Agentic Engineering“ zur Norm wird, ist manche Software darüber hinaus so konzipiert, dass das Chatfenster des Codierungsassistenten als primäres Fenster dient, in dem der menschliche Benutzer mit der IDE interagiert. Dies ist unter anderem eine Möglichkeit, IBM Bob zu nutzen.

Oft sind die Codierungsassistenten modellunabhängig. GitHub Copilot kann beispielsweise Modelle von Anbietern wie OpenAI, Anthropop und Google verwenden, und Angaben von xAI zufolge wurde sein Grok Code Fast 1-Modell für Codierungsagenten-Workflows entwickelt und ist über Tools wie Copilot, Cursor und Windsurf verfügbar. ^{8 9} IBM Bob wiederum verwendet verschiedene Modelle, die Abfragen automatisch zu einem passenden Modell basierend auf Komplexität und Kosten routen. Die Materialien zur Release 2026 beziehen sich auf „eine Mischung aus Frontier Models, darunter Claude von Anthropic, Open-Source-Modelle von Mistral und IBM Granite sowie spezialisierte, fein abgestimmte Modelle für Code Reasoning, Sicherheit und Next-Edit-Vorhersage“.

Einige KI-Debugging-Agenten sind Generalisten, andere Spezialisten. Im Generalisten-Bereich des Spektrums kann der 2025 eingeführte Codierungsagent Copilot von GitHub einem GitHub-Issue zugewiesen werden, im Hintergrund mithilfe von GitHub Actions arbeiten und seine Änderungsvorschläge als Pull Request (ein Paket von Codeänderungen zur Prüfung durch einen menschlichen Entwickler) absenden.¹⁰ Mit seinem Modellmix tendiert IBM Bob ebenfalls in Richtung Generalist. Auf der Spezialistenseite steht Copilot Autofix, das sich speziell mit der Behebung von Sicherheitslücken befasst. Dies geschieht durch die Kombination von CodeQL, der Code-Scanning-Engine von GitHub, mit KI-generierten Erklärungen und vorgeschlagenen Fixes. Die Zeitersparnisse können beeindruckend sein – GitHub meldet eine mittlere Behebungszeit von 28 Minuten im Vergleich von 1,5 Stunden bei manuellem Vorgehen. ¹¹

Die Ergebnisse an der Spitze der generativen KI sind zwar beeindruckend, aber uneinheitlich. Eine kürzlich von IBM durchgeführte CEO-Studie unter 2.000 Geschäftsführern ergab, dass lediglich 25 % der KI-Initiativen in den letzten Jahren die erwartete Kapitalrendite erzielt haben.

Die gemischten Ergebnisse gelten auch für das KI-Debugging. In einer DebugBench-Studie von 2024 stellten Forscher fest, dass Closed-Source-Modelle insgesamt immer noch hinter der menschlichen Leistung zurückblieben und dass Logikfehler deutlich schwerer zu beheben waren als Syntax- und Referenzfehler.¹²

Bessere und spezialisiertere Tools verbessern jedoch die Aussichten. So verbindet ChatDbg zum Beispiel ein LLM mit einem Live-Debugger und gibt ihm Einblick, was genau das Programm gemacht hat, als es fehlgeschlagen ist (und nicht nur den Text des verdächtigen Codes). In einer Auswertung lieferte eine einzelne ChatDBG-Abfrage in 67 % der Fälle eine umsetzbare Lösung für Python-Programme, wobei die Quote auf 85 %, wenn eine einzige Anschlussfrage erlaubt war. ¹³

Erschwerend kommt hinzu, dass sich die Kriterien, nach denen Modelle bewertet werden, ständig verändern. Der anspruchsvollere Nachfolger des bekannten SWE-bench¹⁴, der SWE-bench Pro, wurde darauf ausgelegt, realistischer und unempfindlicher gegenüber Kontaminationen zu sein – in einer kürzlich durchgeführten Bewertung kamen auch die besten Frontier Models nicht über 25 %, wobei GPT-5 23,3 % erreichte.¹⁵  

Das Verhalten der Entwickler ändert sich möglicherweise schneller, als es wissenschaftlich gemessen werden kann. Eine randomisierte Studie von METR Anfang 2025 ergab, dass erfahrene Open-Source-Entwickler bei der Nutzung von KI-Tools 19 % länger brauchten. METR erklärte diese Ergebnisse jedoch schnell für überholt. Eine Folgestudie im Jahr 2026 fand zwar Hinweise auf eine beschleunigte Produktivität, merkte aber an, dass diese Beschleunigung schwer präzise zu messen sei.¹⁶ Die Erklärung von METR für diese Schwierigkeit ist aufschlussreich: „Wir haben einen deutlichen Anstieg der Entwickler beobachtet, die sich gegen die Teilnahme an der Studie entscheiden, weil sie nicht ohne KI arbeiten möchten, was wahrscheinlich unsere Schätzung der KI-gestützten Beschleunigung nach unten verzerrt.“ 

KI-unterstützte Entwicklung – und KI-unterstütztes Debugging – werden eindeutig nicht verschwinden. Doch vorerst sind KI-Debugging-Tools wohl am besten als leistungsstarke Assistenten zu verstehen, nicht als zuverlässige Autopiloten. Sie können Stack-Traces erklären, Syntaxfehler erkennen und Kandidaten-Patches schnell entwerfen. Doch die schwierigsten Fälle – Logikfehler, komplexe Codebasen und sicherheitsrelevanter Code – erfordern nach wie vor Tests, Breakpoints und eine Prüfung des Fixes durch einen erfahrenen Menschen, bevor dieser in die Codebasis übertragen wird.