Version control as your safety net

Commit before you generate, keep one intent per commit, branch per experiment, and read the diff before you accept it.

Commit before the agent starts

The cheapest insurance in agent-assisted development is a clean working tree. With everything committed, any bad agent run costs one command to undo. Without it, you are diffing the agent's changes against your own uncommitted work, and you cannot tell which is which.

# before asking for anything
git status --short
git add -A && git commit -m "checkpoint before agent session"

# or, if the work is not ready to commit
git stash push -u -m "wip before agent session"

# after a bad run
git checkout -- .
git clean -fd
⚠️
git clean -fd deletes untracked files permanently. Check what it will remove with git clean -nd first - an agent may have created files you want to keep, and this command does not ask twice.

Read the diff

# what did the agent actually change?
git diff --stat
git diff

# just the files, when the diff is large
git diff --name-only

# stage selectively instead of accepting everything
git add -p
  • Check every file in the stat list. A change to a file you did not discuss is the most common sign of scope creep.
  • Look for deleted tests, loosened assertions and swallowed exceptions - the three ways generated code makes a failure disappear.
  • Read the diff as a reviewer, not as the author. You did not write it, so you have no reason to trust it.
  • If the diff is too large to read, it is too large to accept. Split the work and try again.
Diff smellWhat it usually means
Assertions removed or relaxedThe test was made to pass, not the code fixed
catch with an empty bodyAn error was silenced to get green
New dependency for something smallUnreviewed supply-chain addition
Reformatting across unrelated filesReview noise hiding the real change
Config or CI file touchedSomething outside the requested task
A file you did not mentionThe agent decided the scope

Branches and commit shape

# one experiment, one branch, one intent
git switch -c experiment/new-checkout-flow

# after a good increment
git add -p
git commit -m "checkout: validate stock before creating the order"

# abandon without touching main
git switch main && git branch -D experiment/new-checkout-flow
  1. One intent per commit. 'Add validation and rename the model and upgrade the test runner' is three commits hiding in one.
  2. Commit working increments, not working days. A commit that reverts cleanly is worth more than a tidy history.
  3. Do not let the agent write the commit message from a diff summary - it will describe what changed, not why.
  4. Keep generated code and hand-written code in separate commits, so review attention goes where it is needed.
  5. Merge only what you have read.
# keep the agent out of history rewriting
"Commit your work with a short message. Do not amend, rebase or force push."

FAQ

Should I let the agent commit?
Let it commit only inside a branch you created and only after you have read the diff. The risk is not the commit itself but the history rewriting that sometimes follows - forbid amend, rebase and force push explicitly, and keep a copy of the branch on the remote.
How often should I commit during a session?
After every increment you have verified. If a session produces a lot of work between commits, you have lost the ability to bisect the failure and you are one bad run away from redoing the whole thing.

Reviewing generated code like an owner Debugging when the agent goes in circles

Last refreshed 2026-09-18.