You changed something and the app got worse, not better. You have poked at it for twenty minutes and it is still broken, and you have done real work since that change that you do not want to throw away. This chapter gets you out clean: undo the one bad change, keep everything else, and land back on a version that runs.
6.5.1Undo without losing unrelated work
Undoing a bad change does not mean throwing away the good work you did after it. Your history is a line of saved snapshots, and you can lift out exactly one of them while the rest stay put.
The trap is treating undo as all-or-nothing: deleting the last hour to kill one five-minute mistake. You never have to pay that price. Point your agent at the single change that broke things and leave everything else standing.
6.5.2Revert the one change
A revert is a new commit that cancels out one specific past commit and nothing else. The work you did after the bad change stays exactly where it is, because you are adding to history, not erasing it.
Your agent runs it against the commit that caused the trouble:
git revert a1b2c3d
Contrast that with the bulldozer. A hard reset back to the last good commit throws away every change since, including the unrelated work you want to keep:
git reset --hard 9f8e7d6 # deletes ALL work after 9f8e7d6
Revert is surgical and safe to run. A hard reset destroys history, so it is the move you almost never want here.
6.5.3Get back to a working state
Sometimes you do not need surgery, you need to stop the bleeding. If the last few changes are tangled and you cannot say which one broke things, get back onto the last version you know ran, then move forward from there.
If the work was on its own branch, the cleanest path is to throw that branch away and return to main, which never felt the damage. If the mess is already on main, revert the last commit to land back on solid ground without erasing anything.
Either way the goal is the same: a version that runs right now, so you can think clearly instead of debugging in a panic.
6.5.4Roll back vs fix forward
Every broken change forces one call: roll back or fix forward. Fix forward means leaving the change in and patching the problem on top. Roll back means undoing it now and retrying later with a clear head.
The rule is about time and understanding, not pride.
| The change... | Do this |
|---|---|
| broke in a way you understand, one-line fix | Fix forward |
| has you stuck, or you cannot explain why | Roll back |
| left you debugging in a panic | Roll back, then diagnose |
6.5.5Hand the undo to your agent
When a change goes bad, hand the cleanup to your agent with clear rules:
Act as a senior engineer doing damage control.
A recent change made things worse and I need it
undone safely. Rules:
- Find the exact commit that caused the problem.
- Undo ONLY that commit with a revert, a new
commit that cancels it out. Never hard-reset
or delete work I did after the bad change.
- If several recent changes are tangled, get me
back to the last commit that ran, and tell me
which one that is.
- Confirm the app runs again before we move on,
then advise: fix forward now, or roll back and
retry the change later.
The bad change I need to undo:
Do this now: the next time a change makes things worse, paste the prompt above with that change, and let your agent revert just that one commit instead of throwing away your afternoon.
