Launch offer: the first 1,000 users get Settl free for a year*Claim your spot
settlbuilding in public

The git safety net for AI coding: checkpoints, branches, undo

The scariest prompt in AI coding is "refactor this", and the fear has almost nothing to do with the AI. I build Settl, an expense-splitting app, solo with Claude, and I let it rewrite entire subsystems without flinching, because one git habit makes every change reversible.

The fear is not about the AI

"What if it breaks something" is really "what if I can't get back". Those are different problems. The first one is guaranteed: any programmer, human or AI, breaks things. The second one is entirely optional, and git solves it for free.

Once undo is guaranteed, your delegation changes character. You stop writing timid prompts like "carefully change only this one function" and start writing the prompts that actually use the tool: "restructure the whole auth module". Bold delegation is not a personality trait. It is a side effect of having checkpoints.

Habit 1: commit before every big AI change

Before any prompt that will touch more than one file, checkpoint:

git add -A && git commit -m "wip: checkpoint before auth refactor"

That is the entire habit. Some notes on doing it without friction:

The test of whether you are doing this enough: when an AI change goes sideways, is the answer "revert one commit" or "spend an hour untangling"? If it is ever the second, you are checkpointing too rarely.

Habit 2: branch for experiments

For anything you are not sure you want, do not experiment on your working branch. Branch, try it, then keep it or torch it:

git checkout -b try/zustand-instead-of-context
# ... let Claude do the whole migration here ...

Liked it? Merge. Hated it?

git checkout main && git branch -D try/zustand-instead-of-context

The try/ prefix is a signal to yourself: branches under it carry no obligation. Half my try/ branches die, and that is the point. An experiment that costs nothing to abandon is an experiment you will actually run. "Rewrite this in another state library so I can compare" goes from a week of dread to an afternoon of curiosity.

The recovery moves

Three commands cover almost every "the AI made a mess" scenario.

Review what it did before you trust it:

git diff          # unstaged changes since your checkpoint
git diff HEAD     # everything since your checkpoint, staged or not

Read the diff like a reviewer, not a proud parent. The diff is ground truth; the AI's summary of what it changed is marketing.

Surgically revert one file when the change was 80% good:

git checkout -- src/auth/login.ts

That file snaps back to the checkpoint; everything else survives. This move alone kills the all-or-nothing anxiety. A mostly-good AI change does not have to be accepted or rejected wholesale.

Find lost work when it all went wrong:

git reflog
# 3f2a1c9 HEAD@{2}: commit: wip: checkpoint before auth refactor
git reset --hard HEAD@{2}

Reflog records where HEAD has been, even through resets and deleted branches. If a commit existed at any point in the last 90 days, reflog can get you back to it. It is the reason "I destroyed the repo" is almost never true.

Let Claude drive git

You do not have to run any of this yourself. Claude Code runs shell commands, so put the habit in the loop:

Before you start: commit the current state as a wip checkpoint.
Then do the refactor. When you're done, show me git diff and wait.
Do not commit the new work until I say so.

The AI making the mess and the AI operating the safety net are fine being the same AI. The checkpoints are what make that safe: even the worst case, a confused model running git commands, is bounded by "reflog gets it all back". Two rules keep it boring: commits are cheap and always allowed, while reset --hard, push --force, and branch deletion happen only when you ask.

Run this on your codebase

Paste this into a Claude session in your repo to install the whole safety net in five minutes:

Set up the git safety net for AI-assisted coding in this repo:
1. Run git status. If the tree is dirty, commit what's there now as
   "wip: checkpoint before safety-net setup".
2. From now on in this session: before any change touching more than one
   file, make a wip checkpoint commit and tell me you did.
3. When I ask for anything experimental, create a branch named
   try/<short-name>, work there, and show me the diff before I decide to
   merge or delete.
4. Never run reset --hard, push --force, or delete a branch unless I
   explicitly ask.
5. Finally, print a cheat sheet for this repo: the command to review your
   last change, to revert a single file to the last checkpoint, and to
   recover via reflog. Keep it to six lines.

Rebase your branch, merge shared history

Use one question: does anybody else depend on these commits?

Situation Safe default Why
Your local feature branch, never pushed Rebase or squash Only your references move.
Your pushed branch, nobody else has pulled it Rebase, then --force-with-lease if policy allows The lease refuses to overwrite a remote change you did not see.
A branch another person has based work on Merge Existing commit IDs remain valid.
main or another protected branch Merge or pull request Never rewrite shared history.

Before a rebase, create a recoverable reference:

git status
git branch backup/my-feature-before-rebase
git fetch origin
git rebase origin/main
git log --graph --oneline --decorate -20

Run the project checks after the rebase. Keep the backup branch until the rewritten branch is verified. If you must update a remote private branch, use git push --force-with-lease, never a plain force push. The lease is not magic, but it prevents overwriting a remote tip that changed since your last fetch.

Download the runnable pack

Get the next one in your inbox