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.

What is a goal-based agent?

A goal-based agent is an artificial intelligence agent that incorporates a proactive, goal-oriented approach to problem-solving and decision-making. It is an example of agentic AI, in which AI systems actually take actions on behalf of users (as distinct from, say, a simple LLM customer support chatbot).

In the five-level hierarchy of agent complexity, goal-based agents sit squarely in the middle. They are more complex than both simple reflex agents (which follow predefined rules) and model-based reflex agents (which add in an internal model of the world). But they are less complex than both utility-based agents (which can compute tradeoffs using a so-called utility function) and learning agents (which can adapt and improve over time, often through reinforcement learning or deep learning).

Goal-based agents exceed simpler reflex agents by adding a planning function that considers future states — but they stop short of employing the dynamic assessments of more sophisticated agents, instead relying on preprogrammed strategies or decision trees in pursuit of their goals.

A real-world use case

One example of a goal-based agent comes from the realm of robotics, specifically warehouse automation. A warehouse robot that needs to pick a certain item from a certain shelf could just react to immediate obstacles, like a robot vacuum bumping against walls (a purely “reactive agent”). More efficient though would be to plan a path that minimizes detours and avoids known obstacles. For instance, in a dynamic environment like a modern warehouse, a planning module can consult its knowledge base, observe the current state and map future states (e.g., by awareness of other bots’ planned motions), all the better to reach its desired outcome efficiently.

How goal-based agents work

Goal-based agents operate in four stages:

1. Goal definition

2. Planning

3. Action Selection

4. Execution

Goal definition [H3]

First, the agent is given a precise definition of success. Unlike utility-based agents, goal-based agents operate under binary, logical conditions. But while a goal-based agent may define success as the flipping of bits from one state to another, there is nothing to prevent such an agent’s singular “goal” from being a moderately complex set of propositional and first-order logic. For instance, a robot might set the goal of “for each package currently marked urgent, deliver each from its respective inventory location to the shipping dock.” The goal is fundamentally binary (one can either succeed or fail at this goal), but it also has multiple components, allowing complexity.

While it would be nice for a human user to define goals precisely, it is also possible for a human to enter a vaguer objective (“optimize holiday fulfillment”) and for an LLM to bridge the gap and define this into a more precise goal or set of goals (for example, “estimate daily throughput of system,” “define P packages as highest-priority," “set goal to deliver P packages within 24 hours”).

Planning [H3]

Having formed its goal, the goal-based agent engages in a bit of planning before moving to execution. For instance, in the warehouse example, the agent will spend some time modeling current and potential conditions in order to choose an optimal path to fulfill the highest-priority orders in time—deciding, for instance, just how often it should make trips from inventory shelves to the shipping bay.

Action selection [H3]

Of course, plans are only as good as the reality they encounter. While some goal-based agents are “conservative” and prefer to stick to plans until they are rendered literally impossible, more flexible approaches come from “opportunistic” agents which, if they encounter impediments to their plans, flexibly calculate a better next action: much like when Google Maps routes around an unexpected traffic jam.

Execution and monitoring [H3]

In the case of a warehouse robot, sensors on the machine can help monitor the situation in real-time, feeding back crucial data to the planning module. For instance, if a sensor detects that the sub-goal “grasp package” has failed for some reason, a goal-based agent can attempt to diagnose the cause, plan an alternate approach or call for backup.

When to use goal-based agents versus more complex agent types

The decision of which type of AI agent to use comes down to what type of problem one must solve. So long as they are given specific goals, the AI models underlying goal-based agents can make informed decisions and handle complex tasks—but the criteria for success must be straightforward (often binary).

However, in situations where real-time adaptability is crucial, or where there are multiple goals to optimize among, businesses may want to graduate from goal-based agents to a more sophisticated option, like utility-based agents. A canonical example here would be a autonomous vehicle. When a passenger hails a self-driving car, there are multiple goals to balance: duration, pricing, traffic avoidance, safety. To deliver the best customer experience, an AI-powered vehicle must undergo complex decision-making processes, computing various tradeoffs of possible actions. The resulting utility function will dictate the agent’s actions.

Multi-agent systems