How to Debug AI Coding Agents When They Change the Wrong Thing

The Real Challenge: Proving What the Agent Did

When you give a coding agent a request, the hard part is not always writing code. The hard part is showing that the agent understood the request, changed the right place, and verified the right result.

An agent can do many things during a run and still end with a short answer like “fixed.” That answer hides the important details: what it inspected, what it changed, what it ran, and what proved the fix worked. Without evidence, you cannot tell whether the final check matched the user’s original complaint.

This gap shows up in ordinary coding requests. A passing build can show the app still compiles, even though the button is still broken. A passing test can mean the assertion got weaker. A plausible route change can still miss the handler that serves the response.

A coding agent should change code and prove what it inspected, what it changed, what it ran, and what result made the fix acceptable.

Software engineering already has a name for part of this problem: traceability. Torkar et al. describe requirements traceability as the ability to follow a requirement from its emergence to its fulfillment. In coding agent work, the same idea becomes more immediate: can you connect the user’s request to the files inspected, the patch applied, the command result, and the final verification check?

Model Context Protocol (MCP) provides a standard way for artificial intelligence applications to connect to files, tools, data sources, and other external systems. That standard only helps if the tool run leaves evidence a developer can review.

A Practical Example: The Overlapping Button

This tutorial tackles a problem both developers and vibe coders run into: the agent changes something, sounds confident, and leaves you guessing whether it touched the right part of the app.

The example uses a user interface bug because visual fixes are easy to get wrong and easy to verify in a browser. A pricing card has a primary button that overflows on a mobile screen size. The repair is a targeted Cascading Style Sheets (CSS) change. The useful part is the saved evidence around the repair: file reads, a wrong selector attempt caught by the browser check, a targeted patch, build output, Document Object Model (DOM) measurements, and before and after screenshots.

By the end, you should have a review pattern you can adapt to common coding-agent failures: the wrong file, the wrong selector, the wrong function, a skipped command, an edited test, a broken route, a missed edge case, or a fix that passes one check but fails the user’s actual request.

The Developer Problem Is Broader Than UI

Here is the kind of request many developers now give to Codex, Claude Code, Cursor, or another coding agent:

Fix the button in the pricing card. It overflows on mobile.

That prompt sounds clear to a human. It is not enough evidence for an agent.

The same review problem appears outside user interface work:

• “Fix the checkout bug” can change the wrong payment branch. The agent might edit the PayPal flow when the bug is actually in the Stripe flow, or patch guest checkout when the failure is in logged-in checkout.
• “Make this test pass” can weaken the assertion instead of fixing the behavior. Instead of fixing the broken code, the agent might change the test so it checks less. The test passes, but the real bug remains.
• “Update the API response” can edit a type but miss the handler. The agent might update a TypeScript type or schema, but forget to change the backend function that actually returns the response.
• “Fix auth redirect” can patch the frontend while the backend still returns the wrong status. The agent might change React routing, but the real issue is the server returning 401 instead of 302, or missing a session cookie.
• “Clean up this function” can change behavior while looking like a refactor. A refactor should preserve behavior. The agent might rename, reorder, or simplify code in a way that changes what the function does.

The common thread is that the agent’s final response—“I fixed it”—doesn’t tell you whether the change actually addressed the user’s intent. In 2026, as AI coding agents become more autonomous and are integrated into CI/CD pipelines, this traceability gap becomes a critical risk. Teams can no longer afford to trust a passing build or a confident message; they need evidence that ties the request to the patch and the verification.

Why Traceability Matters Now More Than Ever

With the rise of agentic development tools in 2026, the ability to trace a request from user intent to final verification is not just a nice-to-have—it’s a requirement for reliable software delivery. Agents like Codex, Claude Code, and Cursor are increasingly used for production changes, and they operate with a level of autonomy that can outpace human review. Without a structured approach to evidence, even a simple fix can introduce subtle regressions or security vulnerabilities.

The MCP standard, which has become the de facto protocol for connecting AI models to external tools, empowers agents to leave a trail of what they did. But it’s up to developers to demand and inspect that trail. The following debugging pattern gives you a concrete way to do that.

The Debugging Pattern: Inspect, Patch, Verify, Evidence

To turn a vague “fixed” into a verifiable change, structure your review around four stages:

1. Inspected files. Which files did the agent read or modify? This shows you whether it looked in the right place. For example, a UI fix should involve the relevant component style, not a random global stylesheet.
2. Patch applied. What exact change did it make? A minimal patch indicates a targeted fix, while a large, sweeping diff raises red flags.
3. Command run. What build, test, or lint command did it execute? A skipped command is a warning sign that the agent didn’t check its work.
4. Result that justified the fix. What output or measurement proved the issue was resolved? This could be a screenshot, a DOM measurement, or a specific test assertion. The result should match the original complaint.

When an agent changes the wrong thing, one of these four stages will reveal the disconnect. If the agent edited the wrong file, the inspected files list will show it. If it weakened a test, the patch will show it. If it forgot to run a command, the log will be empty.

Applying the Pattern to the UI Example

Let’s walk through a real scenario. You have a pricing card component with a button that overflows on mobile. You ask the agent to fix it. Here’s what a traceable run looks like:

• Inspection: The agent reads PriceCard.tsx and its associated PriceCard.css. It also checks the browser at mobile viewport width to reproduce the overflow.
• First attempt: The agent tries a selector like .button in the CSS, but the browser check shows it didn’t resolve. The agent corrects to .pricing-card .primary-button.
• Patch: The final patch is a two-line change in PriceCard.css.
• Command run: The agent runs npm run build and gets a success output.
• Verification: The agent takes a before screenshot, applies the patch, takes an after screenshot, and uses a DOM measure to confirm the button fits within the card width at 320px.

Now, when you review, you can see exactly what happened. The browser check caught a wrong selector, the build passed, and the DOM measurement proves the fix. You don’t have to guess.

Adapting the Pattern to Other Failures

The same four-stage review works for non-UI bugs. Here’s how to apply it to the examples above:

• Wrong payment branch: Inspect the files list. If you asked to fix Stripe checkout and the agent touched only PayPal logic, you’ll see it. Then check the command run: did it actually run a checkout test for Stripe?
• Weakened test: Look at the patch. If the diff includes test files, scrutinize the assertions. Did it change expected values to looser ones?
• Missed handler: The inspected files list will show a type file but not the backend function. The patch will be incomplete.
• Auth redirect: The command run might show a frontend build, but no backend tests. The result should be a status code check, not just a visual snapshot.
• Refactor gone wrong: The patch might show a large diff. Run the full test suite yourself and compare behavior before and after using a baseline.

The Reviewer’s Checklist

To wrap up, here’s a checklist you can use next time an AI coding agent says “fixed”:

• Did the agent inspect files that logically relate to the request?
• Is the patch minimal and targeted, or does it include unrelated changes?
• Did it run any command, and does the output support the claim?
• Is the final verification specific to the original complaint?
• Did it save evidence you can review later (logs, screenshots, test results)?

By insisting on this level of evidence, you turn coding agents from black boxes into accountable collaborators. The next time an agent says “fixed,” you’ll be able to say, “prove it.” And that’s how you debug the wrong changes before they reach production.

via Towards Data Science