What is AI debugging?

On September 9, 1947, engineers on the Harvard Mark II computer found a moth in one of its relays and taped it into their logbook—“first actual case of bug being found”—a page now in the Smithsonian.¹ Computer scientist Grace Hopper of the Mark II team popularized the story, though the term predates her: Thomas Edison complained of “bugs” in an 1878 letter, and the Oxford English Dictionary traces this engineering usage to the 1870s and 1880s.²

Engineering bugs typically come in three types.³ Syntax errors break a programming language’s grammar (an example might be a missing parenthesis) and get caught before the program runs. Runtime errors strike when valid code fails mid-run, like dividing by zero. Logic errors are the most insidious: the program runs without complaint but gives the wrong answer.

Developers can fight back with automated testing—unit tests that check each small piece of code against expected results—and with debuggers, which pause a running program for inspection. A breakpoint—a marked line where execution halts—lets the developer step through the program, examining variables; Python’s built-in pdb is a typical example. An outright crash usually produces a stack trace—a report of the function calls that led to the error.⁴

A 2013 Cambridge Judge Business School study estimated that developers spend on average half their programming time finding and fixing bugs, costing roughly $312 billion a year globally.⁵ The promise of AI-assisted debugging, of course, is to reduce that cost.

An LLM is a machine learning system trained on vast amounts of text and code to predict the next “token” (word, bit of word or symbol)—the same natural language processing technology behind AI chatbots like ChatGPT or Claude. In training, it effectively “read” billions of lines of public code, plus surrounding error messages, bug reports and fixes. By the time an LLM comes to market, it has likely seen millions of bugs and digested their resolutions. 

Documented open-code training data includes GitHub “issue” and “pull request” conversations—records where developers report bugs and fixes—giving specially trained models access to a paper trail showing how broken code gets repaired by human coders.

In a common AI-debugging workflow, the developer gives the model the relevant code and the error message or stack trace; the model then explains the likely cause and suggests candidate fixes. Research systems such as ChatDBG go further, connecting LLMs to standard debuggers like GDB, LLDB and Python’s pdb so a developer can ask plain-language questions—“why is x null?”—while the model inspects the live program, performs root-cause analysis and proposes fixes.6.

There are a few limitations those new to AI debugging should be aware of. First, context matters—a practice associated with prompt engineering. Vague prompts are likelier to yield vague diagnoses; a more helpful approach is to provide the exact error, failing test and bit of suspect code. Users also need to be aware of a model’s context window: the maximum amount of text (measured in “tokens,” or chunks of a few characters each) that a model can consider at once. Real bugs in complex codebases often span multiple files, as the SWE-bench benchmark of real GitHub issues shows, and a model that cannot fit all the relevant code in its context may struggle to reason about it.

AI debugging usually happens through AI coding assistants embedded in, or built around, the developer’s coding workspace—typically an integrated development environment (or IDE). GitHub Copilot, for example, is a coding assistant that can suggest code inside popular IDEs; Cursor and Windsurf are AI-oriented coding workspaces that put similar assistance closer to the center of the programming experience.⁷ And as the rise of “agentic engineering” becomes the norm, some software is designed with the coding assistant’s chat window intended as the primary pane in which the human user interacts with the IDE; this is one way to use IBM Bob, among others.

Often, the coding assistants are model-agnostic; GitHub Copilot, for instance, can use models from providers including OpenAI, Anthropic and Google; xAI has also described its Grok Code Fast 1 model as built for coding-agent workflows and available through tools including Copilot, Cursor and Windsurf.^{8 9} For its part, IBM Bob uses various models, auto-routing queries to an appropriate model based on complexity and cost; 2026 release materials refer to “a mix of frontier models including Anthropic Claude, Mistral open source models, and IBM Granite, alongside specialized fine-tuned models for code reasoning, security, and next-edit prediction.”

Some AI debugging agents are generalists; others are specialists. On the generalist side of the spectrum, GitHub’s Copilot coding agent, introduced in 2025, can be assigned a GitHub issue, work in the background using GitHub Actions, and submit its proposed changes as a pull request (a bundle of code changes for a human developer to review).¹⁰ With its mix of models, IBM Bob also leans generalist. On the specialist side is Copilot Autofix, which specifically targets security vulnerabilities. It does this by pairing CodeQL, GitHub’s code-scanning engine, with AI-generated explanations and suggested fixes. The time savings can be impressive; GitHub reports a median fix time of 28 minutes versus 1.5 hours manually.¹¹

While impressive, the results at the frontier of generative AI are uneven. IBM’s recent CEO Study of 2,000 chief executives found that only 25% of AI initiatives had delivered their expected return on investment in recent years.

The mixed results apply to AI debugging as well. In a 2024 DebugBench study, researchers found that closed-source models still fell short of human performance overall, and that logic errors were significantly harder to repair than syntax and reference errors.¹²

Better and more specialized tools, though, are improving the outlook. ChatDBG, for example, connects an LLM to a live debugger, giving it visibility into what exactly the program was doing when it failed (instead of only the text of the suspect code). In one evaluation, a single ChatDBG query produced an actionable fix for Python programs 67% of the time; allowed just one follow-up question, the rate rose to 85%.¹³

Complicating the picture, the goalposts by which models are evaluated are constantly moving. A harder successor to the famed SWE-bench¹⁴, SWE-bench Pro, was designed to be more realistic and contamination-resistant; in a recent evaluation, the best frontier models remained below 25%, with GPT-5 at 23.3%.¹⁵  

Developer behavior may be changing faster than it can be scientifically measured. METR’s early-2025 randomized trial found that experienced open-source developers took 19% longer when using AI tools, but METR rapidly called those results out of date; a 2026 continuation found some evidence of accelerated productivity, adding that this acceleration was difficult to measure precisely.¹⁶ METR’s explanation that difficulty is telling: “We have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI, which likely biases downwards our estimate of AI-assisted speedup.” 

AI-assisted development—and debugging—is clearly not going anywhere. But for now, AI debugging tools are probably best understood as powerful assistants, not reliable autopilots. They can explain stack traces, catch syntax errors and draft candidate patches rapidly. But the hardest cases—logic errors, complex codebases and security-sensitive code—still demand tests, breakpoints and a skilled human reviewing the fix before it merges to a codebase.