Why Undo’s Explain Extension is Agentic Debugging, Not Just a Natural Language Interface

If you’ve been following developments in AI-assisted debugging, you might assume the approach is straightforward: let an LLM issue debugger commands through natural language. “Set a breakpoint at line 47.” “Step into this function.” “Print the value of this variable.”

This approach is so limited it’s not even just suboptimal. For the sake of a little documentation reading, you can drive a time travel debugger yourself with the correct commands and syntax.

Undo’s explain extension for UDB rejects this model entirely and implements true agentic debugging, where the AI receives problem context and operates autonomously to find answers, rather than executing commands it doesn’t understand. Understanding this difference is critical if you want AI-assisted debugging to actually solve real problems.

The natural language debugger interface: why this model is so limited

Treating an LLM as a natural language interpreter for debugger commands seems intuitive. You tell it what you want to do, and it translates your intent into GDB commands or IDE actions. For single commands maybe while you learn the syntax, this might help, but it’s a waste of the AI’s capabilities.

Where it starts to add some value is when you want to give compound instructions, “take me to the 42nd time this function was called with 0xCAFE as the 1st argument”, or “take me back to when this data structure was allocated”. In this case the AI is at least starting to act as a more labor saving tool, and this can definitely accelerate the understanding process when exploring what happened, but it is still being a tool to navigate, it’s not doing any of the understanding or diagnosing of the issue.

So, even while this can be useful at times, it is still the wrong abstraction. The problem is that low-level commands strip away the debugging context the AI needs to reason effectively.

With the simplest commands, such as “Set a breakpoint at line 143,” you’re not explaining why line 143 matters. You’re not describing what you’re investigating or what hypothesis you’re testing. The AI is basically only saving you having to read the documentation to figure out the correct command syntax. The AI can only guess what you were thinking when you decided that command was useful (and at least today’s LLMs are really not very good at that).  

Even the more complicated examples, the AI gets a little more context as to what you are looking for, the specifics of the request highlight a little of what you are interested in, but it’s still not helping the AI to really understand the debugging session’s purpose or the hypothesis you are trying to explore.

This creates a frustrating dynamic:

• The AI can’t understand your reasoning, so it executes commands blindly.
• When results don’t match your expectations, the AI doesn’t know what you expected or why.
• You try asking the AI for help but get frustrated as it doesn’t understand what it was you have been trying to achieve up to this point (and likely guesses very poorly).
• You start simplifying instructions further to avoid the guessing game and don’t take advantage of one of the key strengths on today’s LLMs, understanding complex systems and state.
• Eventually, the AI degrades into nothing more than a debugger command syntax lookup tool, or maybe a tool that accelerates a little of the navigational grunt work, but doesn’t do any of the diagnosis or problem solving.

At this point, you’ve wasted the AI’s most valuable capability: its ability to process complex state, understand causality, and generate viable explanations. You’re using an LLM as a glorified autocomplete for GDB commands.

Agentic debugging: how ‘explain’ can help

Undo’s explain extension takes a fundamentally different approach. Instead of accepting debugger commands, it accepts high-level questions about program behavior:

• “Why did this crash?”
• “What happened to my hash table?”
• “Where did this incorrect value come from?”
• “How did we get into this inconsistent state?”

These questions give the AI what it needs: context about the problem you’re trying to solve. With this context, the AI can leverage its real strengths: understanding complex state, reasoning about causality, and generating explanations.

Here’s what the AI actually does when you ask such a question:

1. Understanding the context

The AI reviews the complete problem context: the crash or failure point, the surrounding code, the program state at failure, and your high-level question. It’s not executing commands; it’s building a mental model of what the software was supposed to do and what actually happened. Existing AI code understanding techniques will manage exploring huge codebases and identifying relevant code for the behavior being explored to avoid overflowing the context limitations in the LLMs.

2. Hypothesis generation

Based on this understanding, the AI generates hypotheses about what might have caused the problem. For a crash, it might hypothesize: “This pointer was null because the initialization function returned early due to a failed allocation.”

Crucially, the AI comes up with this hypothesis itself by reasoning about the state and code. You didn’t tell it to check the initialization function; it determined that was relevant based on the program state it observed.

3. Prediction derivation

Crucially, the AI doesn’t just stop at a hypothesis. It derives testable predictions from that hypothesis. If the hypothesis is correct, then:

• The allocation should have failed at a specific point in time.
• There should be evidence of low memory or a specific error code.
• The initialization function should have taken a particular code path.

4. Validation against the recording

The AI then uses the recording to test these predictions. It can navigate to the relevant points in time and check: Did the allocation actually fail? Was that error code present? Did that code path execute?

The time travel recording provides ground truth. This is where the closed loop happens: the AI’s hypothesis generates predictions, and the recording validates or refutes them.

5. Autonomous refinement

If a prediction doesn’t match reality, the AI doesn’t need you to tell it what to try next. It adds this information to its understanding of the problem and generates a new hypothesis. Perhaps the allocation didn’t fail, but the pointer was corrupted later by an out-of-bounds write. The AI pivots autonomously and tests this new hypothesis.

This process continues until the AI either solves the problem or exhausts reasonable hypotheses. The AI is working independently, making mistakes but correcting them itself, refining its understanding with each iteration.

This is agentic debugging: the AI acts as an autonomous investigative agent with a clear goal (answer your question) but the freedom to determine its own investigation strategy. You’ve given it the problem context and the tools (the recording) to test its theories. It takes care of the exploration.

You can monitor its progress and redirect if it goes down an unproductive path, but you’re not micromanaging every step. The agentic debugger takes your high-level question and delivers an answer (potentially after extensive autonomous exploration you never had to specify).

Why this requires time travel debugging

You might wonder: couldn’t you build this kind of system with a traditional forward-only debugger?

No. Not in any practical sense.

The closed-loop approach requires the AI to explore different parts of the execution history based on what it learns. When a hypothesis proves wrong, it needs to jump to a different point in time and examine different state. With a traditional debugger, each exploration requires:

1. Restarting the program
2. Reproducing the bug (which might be non-deterministic)
3. Setting up the right conditions to examine the hypothesis
4. Hoping you can capture the relevant state before it changes

This makes iterative exploration impossibly slow. Worse, for non-deterministic bugs (race conditions, timing issues, memory corruption), you can’t reproduce the same execution at all. Each run might take a different path, making systematic hypothesis testing impossible.

Time travel debugging solves both problems. The recording is:

• Deterministic: The same execution every time, guaranteed
• Navigable: Jump to any point in history with predictable, repeatable behavior
• Complete: Every thread, every variable, every instruction is captured

This transforms debugging from a careful, sequential process into an exploration problem, exactly the kind of problem that LLMs can tackle effectively when given the right tools.

What works vs. what doesn’t in agentic debugging

Given this understanding, the difference between effective and ineffective use of explain becomes clear:

Questions that enable agentic behavior (use these)

• “Why did this program crash?”
• “What caused this assertion to fail?”
• “How did this data structure become corrupted?”
• “Where did this unexpected value originate?”
• “What caused this thread to deadlock?”

These questions define investigation goals. They tell the AI what you need to understand, not how to understand it. This enables true agentic behavior; the AI can autonomously explore, form hypotheses, and validate them against the recording.

Commands that deprive the AI of context (don’t do this)

• “Set a breakpoint at line 143”
• “Step into the next function call”
• “Navigate to the process_request() function”
• “Print the current value of buffer”

These commands tell the AI what to do but not why. The AI doesn’t know what problem you’re investigating, what you expect to find, or what would constitute a useful answer. It’s flying blind, reduced to command syntax lookup.

When you issue commands this way, you’re depriving the AI of the very context it needs to help you effectively. Without understanding the problem, the AI can’t reason about causality, can’t generate hypotheses, and can’t recognize when something unexpected or significant appears in the data.

This doesn’t mean you should withhold useful information. If you have ideas about where the problem might be, share them as suggestions: “I think the issue might be in the initialization path, particularly around the memory allocator” or “The hash table seems to be corrupting, possibly related to the recent changes in the resize logic.” These give the AI helpful starting points without reducing it to command execution.

You can also provide acceptance criteria beyond the basic failure. For example: “Why did this crash? Note that a correct explanation should account for why this only happens with more than 1000 concurrent connections, and why it’s more frequent on ARM than x86.” This helps the AI understand what constitutes a complete answer and focuses its investigation on the aspects that matter to you.

The difference this makes

This isn’t just a philosophical distinction: it fundamentally changes your relationship with the debugging process.

When debugging unfamiliar code, you often don’t know:

• Which modules are involved in the bug
• What the relevant data structures are called
• Where in the codebase to look
• What the normal behavior should look like

With command-driven debugging, you have to figure all this out before you can make progress. You’re stuck because you lack context about the system.

With agentic debugging, the AI discovers these things as part of solving your problem. You give it the high-level question (“Why did this crash?”) and monitor its investigation. If it goes down an unproductive path (chasing a red herring or exploring an irrelevant module) you can redirect it. But you’re not specifying every step.

For example, you ask “Why did this crash?” and the AI might autonomously discover:

1. The crash occurred in a memory allocator deep in a third-party library.
2. The allocator was corrupted by an out-of-bounds write.
3. That write happened in a module you weren’t aware was even involved.
4. The bug was triggered by a specific sequence of API calls that violated an undocumented invariant.

You didn’t need to know any of this to ask the question. You didn’t need to tell the AI to check the allocator, examine the write, or trace the API call sequence. The agentic debugger figured out what to investigate by reasoning about the problem context and testing its hypotheses against the recording.

Your role shifts from micromanaging a command interface to reviewing the AI’s reasoning and occasionally steering its investigation. The AI does the exploration; you provide the problem understanding and course corrections. Or just go do something else, let it do its job, and come back in half an hour! 

Looking forward

This explain functionality is actually fairly basic. There’s room to go deeper.

Future iterations might:

• Better understand program semantics and invariants
• Automatically detect entire classes of bugs without being prompted
• Learn from patterns in previous investigations
• Integrate with source code analysis to suggest fixes

But even at this “shallow” level, agentic debugging represents a fundamental step beyond natural language command interfaces.

The bottom line

If you’re evaluating AI debugging tools (whether Undo’s or anyone else’s), the critical question isn’t about features or UI. It’s about fundamental architecture: does this tool give the AI the context to reason about your problem, or does it reduce the AI to command translation?

Natural language command interfaces are a dead end. They’re intuitive to build, which is why people keep trying, but they strip away the very context that makes AI valuable. When you issue low-level commands, the AI doesn’t know why you chose those commands or what you’re trying to understand. It degrades into a debugger syntax lookup tool.

What works is agentic debugging: giving the AI your problem context and letting it autonomously explore, hypothesize, test, and refine. This requires:

• High-level problem descriptions rather than low-level commands
• A queryable execution history that the AI can test hypotheses against (not just logs or snapshots)
• Deterministic, repeatable navigation through that history
• The freedom to make and correct its own mistakes

Time travel debugging provides the infrastructure for hypothesis testing: the closed loop that lets the AI validate its theories and refine them when wrong. That’s why agentic debugging works.

When you ask “Why did this crash?” instead of “Set a breakpoint here,” you’re not just using different words. You’re giving the AI the problem context it needs to reason effectively: enabling true agentic behavior rather than reducing it to a voice-controlled command executor.

The explain extension is currently available as a tech preview for UDB 8.2.2 and later. If you’re interested in trying agentic debugging with a closed-loop approach, check out the documentation on getting started with the explain command and MCP integration. Or just get in touch for a demo!