An AI coding agent broke my app and now what

The AI agent was supposed to fix something specific. You ran the prompt. The agent did what it does. Now more is broken than was broken before. The instinct is to prompt again, ask the agent to fix what it broke, maybe add some clarifying constraints. The instinct is wrong. The first move is to stop the agent from doing anything else.

Every additional prompt at this stage compounds the damage. The agent doesn't know what state the system was in before, doesn't know what the new failures are, and is going to make changes that interact with the existing damage in ways that are increasingly hard to trace. Stop the loop. Then find out where you actually are before deciding what comes next.

I want to walk through the first-response sequence: how to stop the damage, how to find the real state of the system (which is often different from what the agent reported and different from what your local server is showing), and how to decide between rollback, targeted patch, or escalation. The discipline is the same whether the agent that broke things was Claude Code, Cursor, an autonomous agent like Devin, or any other tool.

Step one: stop generating

Close the agent's session. Don't ask it one more question. Don't try to clarify. The agent has already demonstrated that its current context has produced wrong output, and additional context is unlikely to recover. More importantly, you don't yet know what the agent has actually done, and you can't reason about further changes until you know.

This is the hardest step because the instinct is to fix what's broken. The instinct is wrong because you don't yet know what's broken, what's working that you might break further, or what state your codebase is actually in. Fix-mode is premature.

Take whatever time you need to detach from the urgency of the moment. The damage is already done. Acting fast won't undo it; acting deliberately might.

Step two: capture the current state

Before doing anything else, capture what the system looks like right now. This is the baseline you'll work from regardless of what comes next.

• A git status showing what files are modified, added, or deleted in the working tree.
• A git log showing the recent commits, especially anything the agent committed.
• A git diff HEAD if the changes aren't committed yet, or git diff HEAD~N to see the changes across recent commits.
• Screenshots or text capture of any error messages the system is currently producing.
• A description of what behavior is now wrong that wasn't wrong before.

This artifact set is the diagnostic baseline. Without it, every subsequent move is guessing. With it, you have something to reason about.

If the agent has been making changes outside version control (modifying files without committing, working in branches you didn't authorize, changing configuration that lives outside the repo), the capture is more involved. Document what you can see directly. The lack of version control under the agent's changes is itself one of the problems.

Step three: run the stale-server diagnostic

The most common cause of "the agent fixed it but it's still broken" is that the agent worked against a stale view of the system. The agent changed source files. The running server is still serving the old build. The agent reports success because its tests pass against the new source; you see failure because you're testing against the old running instance.

The diagnostic is to compare three places where the system's behavior lives:

The source code. What the agent actually wrote to the files. Inspect directly.

The build artifact. What the build process produced from the source. Often different from source if the build has caching, intermediate transformations, or unwatched files.

The live server output. What your running instance is actually serving. Often different from the build artifact if the server is running an older build, has cached intermediates, or is reading from a stale location.

When all three agree, the agent's claim that something is fixed can be trusted (at least for the surface behavior). When they disagree, the agent is reporting success against the source while you're seeing failure against an old runtime. The fix is to rebuild and restart, not to ask the agent to try again.

The stale-server diagnostic is one of the most consistent rescue tools, covered in the nav that almost wasn't as an in-context case study. The pattern of "looks fixed in code, still broken at runtime" appears in nearly every rescue session.

Step four: run the surface-vs-semantic check

The second most common cause of agent-introduced damage is that the agent fixed the surface (what's visible) without fixing the semantic (what's actually happening underneath). The page renders the right text. The data underneath is wrong. The button looks correct. Clicking it does the wrong thing.

The check is to verify both layers for each thing the agent claimed to fix:

Surface check. Does the visible output look right? Render the page, view the output, read the result.

Semantic check. Does the underlying behavior match? Inspect the data, trace the action, verify the actual state.

When surface and semantic agree, the fix is real. When surface says fixed and semantic says broken, the agent papered over the problem rather than addressing it. This is often more dangerous than the original breakage because it hides the real failure.

The discipline is documented in three catches at the surface vs semantic boundary. The pattern is so consistent across rescue cases that the explicit surface-vs-semantic gate is now part of my standard promotion discipline.

Step five: decide between rollback, patch, or escalation

With the baseline captured and the diagnostic complete, you have enough information to choose a path.

Rollback is the right move when:

• The agent's changes are isolated to a small number of files.
• A clean prior state exists in version control.
• The damage exceeds the value of whatever the agent was trying to add.
• You don't have time to investigate further.

A rollback restores a known-good state. The lost work is the work the agent did between then and now, which by hypothesis is producing more damage than value. Accept the loss and resume from a known position.

Targeted patch is the right move when:

• The agent's changes are mixed: some good, some bad.
• Reverting everything would lose work that was actually correct.
• You can identify specifically which changes broke things versus which changes helped.
• You have the discipline to apply only the corrective changes without re-engaging the agent broadly.

A targeted patch means writing the specific fix yourself, or specifying it precisely enough that the next agent invocation has zero discretion. Not "fix the bug." Specifically: change line X in file Y from this exact value to this exact value, then verify the surface-vs-semantic check passes.

Escalation is the right move when:

• The system is in a state you don't fully understand.
• The agent's changes touched things you can't easily inspect.
• Production or critical data is at risk.
• The pattern of breakage suggests the agent was operating against incorrect context that further prompting won't fix.

Escalation means stopping the AI-driven work entirely and bringing in human review. A rescue diagnostic from someone who's seen this pattern before will usually find the right path faster than continued solo work with the agent.

What not to do

Several things look helpful in the moment and aren't.

Don't keep prompting. The agent doesn't know what state you're in. More prompts produce more changes that interact with the existing damage in increasingly opaque ways.

Don't ask the agent to "undo what you just did." The agent doesn't have a reliable model of what it just did. It will produce changes it thinks are the undo, which may or may not match.

Don't accept the agent's claim that something is fixed without running the surface-vs-semantic check. Agents reliably report success that doesn't survive contact with reality.

Don't push the changes to production. Whatever state you're in, production is the wrong place to discover its consequences.

Don't blame yourself for the pattern. This pattern emerges with every AI coding agent because the agents don't carry reliable state across runs. Operator discipline is what catches it, not operator skill in prompting.

What this looks like applied

A clean rescue session, even one that started with broken code, usually runs through this sequence in 15-30 minutes. Stop. Capture. Diagnose. Decide. The investment in not generating more code pays back in the clarity of the decision that follows.

The systems I rescue most often were systems where this sequence didn't happen. The operator kept prompting. Each prompt added damage. By the time someone outside intervenes, the damage spans dozens of files and a clear baseline doesn't exist. Recovery from that state is genuinely harder than recovery from the original break.

If you're in that situation now and the damage has spread further than the first incident, the rescue process is still available; it just takes longer. The same sequence applies: stop, capture, diagnose, decide. The decision is more likely to be "rollback to a known state and re-do the work deliberately" than "patch in place," but the process is the same.

---

If you're staring at an AI-built app that just broke and the next prompt isn't making it better, send the repo state, the error messages, what the agent said it did, and what's actually happening. VibeKoded can scope a rescue diagnostic, stabilization sprint, or rebuild plan. → Work with VibeKoded