Don't ask the agent to fix its own damage: freeze, grade, and salvage a damaged working tree

Boundaries first, method second. This guide is not a repeat of three neighboring guides already on this site. First, "Solo AI Git Workflow" covers everyday branching, commit messages, and rollback moves for normal development — getting back to a previous good state during ordinary work. This guide covers a different situation: an agent has already damaged your working tree, and you must salvage good code from uncommitted changes. Second, "Canary Release and Rollback" covers rolling back a version that already shipped; this guide covers salvaging local, uncommitted changes that never shipped. Third, "Indie Developer Incident Runbook" covers stopping the bleeding within 15 minutes after production goes down and communicating outward; this guide covers cleaning up a local working tree before any user is affected. One more neighbor mentions worktrees: "One Person Commanding Four Agents" uses worktree isolation as a setup step before work begins. This guide uses a worktree as a quarantine zone after damage. One is prevention; the other is triage. Boundaries stated — now the method.

The scene will be familiar: you asked an agent to "quickly refactor this module," and came back to 23 changed files, five of which you never asked it to touch; four tests failing; one button missing from the interface; and no clear sense of which changes are good and which are bad. The worst response is to immediately ask the agent to "fix it." A second round of edits builds on the first round's mistakes, burying errors deeper until even "what it looked like before" is unrecoverable. The correct response is the opposite: stop, freeze the scene, separate good changes from bad ones, and only then decide the fate of each change.

Minutes 0 to 5: stop, freeze, preserve evidence

In the first minute after discovering damage, do exactly three things and nothing else. First, stop the agent. Do not let it keep running, do not let it "fix the tests first," do not let it commit anything. A still-running agent is the largest ongoing source of damage at the scene; it will keep changing files while you investigate. Second, freeze the scene: run no cleanup commands, no git checkout, no git clean, no file deletions. Your goal is to preserve the complete state of "after damage, before rescue." Third, preserve evidence: run git status and git diff --stat immediately and save the output to a file; then save the full git diff as well. Those two files are your photographs of the scene, and every later decision refers back to them.

One part of the evidence is easy to forget: the agent's own execution record. Save the conversation from this run, what the agent claimed to change, and the full text of the failing tests. In many postmortems it turns out the agent actually said it changed a file you did not want touched — nobody noticed at the time. The conversation record is not for blame; it is for triage speed. It tells you which files to look at first instead of reading all 23 from the top.

There is one absolute prohibition in these five minutes: no "restoring" without a backup. Commands like git checkout -- ., git reset --hard, and git clean -fd are everyday tools in normal work and evidence-destroying tools at a rescue scene. Once run, good and bad uncommitted changes vanish together, and you lose even the ability to tell which was which. The order is fixed: back up first, act second. Any restore without a backup is off the table.

Minutes 5 to 20: grade the changes, not the files

Once the scene is frozen, do not start by reading files one by one. Grade the changes — and grade at the level of changes, not files, because a single file can contain good and bad changes at once. Use three grades, each with its own handling.

Grade A is "clearly good": changes that match your original intent, pass tests, and belong to the task. If you asked for a function refactor and the agent genuinely extracted duplicated code into a shared function with tests passing, that is Grade A. Handling: keep it, but do not commit yet; commit everything together only after rescue is complete.

Grade B is "suspicious": changes you are unsure about, or that exceed the task's scope. An agent that quietly edited a configuration file you never mentioned, or changed a function signature without updating all callers, produces Grade B changes. Handling: isolate them. Set them aside untouched, and return to judge them one by one only after Grades A and C are dealt with.

Grade C is "clearly bad": changes that break tests, break the interface, delete code, or get logic wrong. Handling: remove them — but only after confirming they are not tangled with Grade A changes in the same block. If they are tangled, do not delete the whole block; split it line by line, keeping Grade A lines and removing Grade C lines. That splitting looks slow, and it is the most important step in the whole rescue: deleting the whole block throws good code away with bad, and keeping the whole block keeps bad code with good.

One special category must be pulled out separately during grading: any change touching secrets, tokens, passwords, or .env files. If agent changes contain any credential, whether intentional or not, treat it as leaked immediately: rotate first, then clean up — never clean up first and consider rotation later. Once a credential has passed through an agent context or a diff, you cannot assume it was "not yet seen." There are no exceptions and no "let's wait and see."

The quarantine zone: a worktree that separates rescue from the main battlefield

After grading, do not start editing in the original working tree. Build a quarantine zone: create a clean worktree with git worktree pointing at the last good commit before the damage, and perform the rescue there. The original tree stays frozen as evidence; the quarantine zone is the operating table; the two never interfere. Even if an operation in the quarantine zone goes wrong, the original scene is intact and you can start over.

The procedure: first identify the last good commit, usually the HEAD before the agent started. Create a worktree at that commit, then apply the Grade A changes from the original tree as patches into the quarantine zone. Apply one file or one block at a time, run the relevant tests after each application, and count a Grade A change as truly "rescued" only when its tests pass. Grade B changes are not applied yet and stay on the list; Grade C changes are discarded and never enter the quarantine zone.

The key discipline is "one change at a time, tested before it counts." Many rescues go wrong through haste: applying all Grade A changes at once, watching tests fail, and having no idea which change broke them — which simply reproduces the original mess inside the quarantine zone. Slow is fast here: one application at a time means a failure implicates exactly one change, and the rollback scope is exactly one change. The quarantine zone exists so you can afford cheap trial and error instead of gambling on the main battlefield.

The quarantine zone has a side benefit: it forces rescue into reproducible operations. Every step is "apply patch, run tests, confirm," a loop that can be recorded, reviewed, and handed to someone else. Editing directly in the original tree is not reproducible; interrupt it halfway and nobody can pick it up again.

Three levels of rollback, in order: file, hunk, branch

Rescue often needs "rollback," but rollback has three levels, and picking the wrong level expands the damage. Level one is file-level rollback: restore a single file to its pre-damage state, for example with git checkout <good-commit> -- <path>. It fits when a whole file is Grade C, or when that file's Grade A changes have already been salvaged into the quarantine zone. Its advantage is minimal blast radius; its limitation is that it cannot handle files where good and bad changes are tangled.

Level two is hunk-level rollback — the line-by-line salvage: use git diff to find tangled blocks, keep the good lines and remove the bad ones by hand, or use git checkout -p to select hunks interactively. This level costs the most time and delivers the most value, because it determines how much good code you ultimately keep. After each hunk, run the relevant tests; do not batch them to the end. Batching to the end means that when tests fail, you cannot tell which of twenty hunks caused it.

Level three is branch-level rollback: abandon the current branch's work, start a fresh branch from the good commit, and cherry-pick only the salvaged Grade A changes from the quarantine zone. It sounds drastic, but it is the cleanest finish when changes are too tangled to grade, or when the agent mixed in so much unrelated refactoring that line-by-line salvage is not worth it. Branch-level rollback is not failure; it is the rational choice once you admit that salvage costs more than redoing the Grade A work. The test is simple: if estimated salvage time exceeds the time to redo the Grade A changes, go straight to branch-level rollback without hesitation.

The order is fixed: file level first, then hunk level, then branch level. Do not start with branch-level rollback — that discards salvageable good code. Do not use hunk-level work where file-level suffices — that wastes time. Get the level right and rescue costs stay controlled; get it wrong and the rescue becomes a second round of damage.

Letting the agent back in: scope first, exclusion zone second, acceptance criteria third

Sooner or later the agent must return to finish the remaining work. But its return must not be "continue the previous task." It must be a fresh start under new constraints, and all three constraints are mandatory. First, scope: state exactly which files and functions this task may change; anything outside scope is forbidden. Second, exclusion zone: list the files and directories it must never touch — configuration files, database migrations, authentication code, and anything containing credentials. The exclusion zone belongs in the task description, not just in your head. Third, acceptance criteria: state what "done" means, for example "all related tests pass," "no changes to the public interfaces of these files," or "no more than N files changed." Without acceptance criteria, the agent judges completion by its own standard, which is usually "the code runs," not "the changes are correct."

One more operational detail for re-entry: have the agent work in the quarantine zone first, and merge to the main branch only after you have reviewed and approved the result — never directly on the main branch. That way, even if the second attempt goes wrong again, the damage is confined to a disposable zone while the main branch stays clean. Once this habit is in place, "agent damage" downgrades from disaster to inconvenience: trouble in a quarantine zone can be discarded and redone at any time, while disaster on the main branch costs several times longer to rescue.

Finally, write this rescue's lessons into the project's agent instructions. What exactly? The damage pattern from this incident: did the agent exceed scope, get logic wrong, or delete code it should not have? The grading outcome: which files are exclusion zones, which change patterns are high-risk? The acceptance criteria you set this time. The agent will not remember lessons by itself, but lessons written into documentation get read every time it starts.

Afterward: a 30-minute drill that turns rescue into muscle memory

A rescue procedure only counts as learned once it has been drilled. Spend 30 minutes on a drill; you do not need to wait for a real incident. The drill: on a throwaway branch, deliberately let the agent perform an out-of-scope refactoring, then walk the full procedure — freeze, preserve evidence, grade, build a quarantine zone, salvage hunk by hunk, re-enter with constraints. The goal is not to get the refactoring right; it is to get the procedure fluent. Can you freeze and preserve evidence within five minutes? Can you complete grading within twenty? Can you create a quarantine worktree without thinking?

After the drill, check three indicators. First, does the project have a ready exclusion-zone list for agents? Second, does everyone involved — even if that is only you — know the order "freeze first, grade second, act last" after damage? Third, does the project always commit a clean state before each agent task, so that "the last good commit before damage" always exists? If any indicator is negative, the drill is not complete; fix it before finishing.

One last thought. An agent damaging code is not proof that "AI is unreliable." It is a signal that working methods have not yet caught up with tool capability. A tool that can change 23 files at once demands a working method that can review 23 files' changes at once; a tool that can refactor a module in a minute demands a rescue procedure that can freeze the scene in a minute. Practice the rescue until it is habit, and agent damage downgrades from a "project-stopping incident" to a "half-hour cleanup." That half hour, deciding which changes deserve to stay and which must go, is precisely the part of the work that remains irreducibly yours.