AI AI Tools Guidebook
AI Tool Tutorials

AI Coding Rollback Workflow

Don't fear letting AI edit — fear losing the ability to undo.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

The worst AI coding session isn’t the one where the AI makes a wrong change — it’s the one where the AI makes 47 wrong changes spread across 12 files and you can’t reverse any of them cleanly because you let it run on a dirty tree. This workflow gives you the four-step git discipline that keeps every AI edit reversible, the commit cadence that makes “undo” cheap, and the recovery playbook for the moments when you still end up needing to peel back a tangled diff.

What this covers

A git-centered rollback discipline for AI-assisted coding: commit before AI runs, review the diff before committing AI output, commit between agent steps for long tasks, and use stash for “maybe later” changes. Same git you already know — applied with stricter cadence because AI changes more files faster.

Who this is for

Anyone with an AI assistant editing code: Cursor / Copilot / Claude Code / Cody users, indie devs running autonomous agents, teams adopting AI coding workflows, and engineers who have ever said “wait, how do I undo this?”

When to reach for it

Before letting any AI assistant or agent touch code. Especially before long autonomous runs, multi-file refactors, or any session where you intend to accept multiple AI suggestions in a row.

When this is NOT the right tool

Greenfield prototypes where you don’t care about reverting (and have nothing to lose). Real-time pair-programming where every suggestion is immediately accepted or rejected (the IDE handles undo). Read-only sessions where the AI is only explaining, not editing.

Before you start

  • Confirm working tree is clean: git status shows nothing. Stash or commit anything in progress first.
  • Confirm tests pass on the current state. You need a known-good baseline before AI changes anything.
  • Set a commit cadence rule: minimum one commit per logical AI suggestion. Long agent runs need a commit every 3-5 steps.
  • Know your remote state. If you haven’t pushed in a week and the agent goes wrong, you can lose work. Push your baseline first.

Step by step

  1. Commit before AI runs. Even “WIP” is fine — the goal is a clean diff after AI changes appear. Use git commit -am "wip: baseline before AI refactor of userService".
  2. After AI runs, ALWAYS git diff before committing. Look line by line for changes you didn’t ask for: deleted error handling, removed null checks, renamed exports, “improved” loops that subtly change semantics.
  3. If the diff is clean: stage and commit with a descriptive message. “ai: refactor callbacks to async/await in userService”.
  4. If the diff has problems but most is good: stage only the good parts with git add -p, then commit. Discard the rest with git checkout -- <files> or git restore.
  5. For multi-step agent tasks, force a commit between steps. Tell the agent: “Stop after each ticket. I will commit before you proceed.” Long agent runs without intermediate commits are how 4-hour disasters happen.
  6. Use git stash for “maybe later” changes the AI produced that you don’t want to drop entirely. git stash push -m "ai: extracted helper, may reuse".
  7. For agent runs going off the rails, abort and git reset --hard HEAD to the last known-good commit. Cheaper than untangling 40 unwanted changes.
  8. Push frequently. Local commits aren’t backed up. Push your baseline before long agent runs, push after each clean checkpoint.

First-run exercise

  1. Pick a small AI task you’d normally do casually — rename a function across a module, or extract a helper.
  2. Run the full discipline: clean tree, baseline commit, AI runs, diff review, selective commit, push.
  3. Time it vs. your normal “just let it edit” approach. The overhead is small (2-3 minutes); the safety is huge.
  4. The second time, deliberately accept a bad AI suggestion, then practice the rollback. git reset and git restore are muscle memory you want before you need them under pressure.

Quality check

  • Every AI session starts from a clean git status. No exceptions.
  • Every AI diff is reviewed line by line before commit. No “looks fine, commit all”.
  • Long agent runs have intermediate commits — never one giant final commit.
  • Tests pass after every commit. Broken commits make bisect useless.
  • Baseline is pushed to remote before high-risk runs (large refactors, autonomous agents).

How to reuse this workflow

  • Bind the four commands to muscle memory: git status, git diff, git add -p, git restore. These are your AI safety toolkit.
  • Build a per-project “pre-AI checklist” snippet you paste before any session: “Clean tree, baseline committed, baseline pushed, tests green”.
  • For agent runs, write a system prompt that forces stops between steps: “After each task, output a diff summary and pause for human confirmation.”
  • Re-evaluate the cadence per model release. Some agents are reliable enough for longer autonomous runs; others still need step-by-step approval.

Clean tree → baseline commit → push baseline → run AI → review diff → selective stage → commit → repeat. For autonomous agents, add explicit step boundaries with forced commits between.

Common mistakes

  • Letting AI work on a dirty tree — you can’t distinguish your in-progress edits from AI changes. Stash first.
  • Long agent runs without intermediate commits — when something goes wrong (and it will), you lose hours of work or untangle a mess.
  • “Looks fine, commit all” without reviewing the diff — AI’s silent changes (deleted error handling, removed guards) ship to production this way.
  • No remote push before high-risk runs — your local commits aren’t backed up; agent runs that wreck your repo can lose work entirely.
  • One giant final commit — bisecting failures becomes impossible. Commit per logical step.
  • Skipping the tests-green baseline — you can’t tell if AI broke something or if it was already broken.

FAQ

  • What if I’m not using git?: Use git. There’s no comparable rollback story for AI-edited code outside source control.
  • Can I use git stash instead of commit?: For short-term hiding, yes. For checkpoints during long runs, commits are stronger — stashes are easy to lose.
  • What about IDE undo history?: Helpful for single edits, useless for multi-file agent runs. Git is the source of truth.
  • How do I review huge AI diffs efficiently?: Use git diff --stat for the file map, then git diff <file> for each touched file. Look for surprise files first — they hint at scope drift.
  • Can I script the workflow?: Yes. A pre-AI commit hook (pre-ai.sh) that does git status; git diff --stat; git stash is common in teams adopting AI coding.

Tags: #AI coding #Tutorial

Related Articles