Checkpoints & Git Worktrees: Let AI Code Fearlessly

Playbook

Here's the thing nobody tells you about coding with agents: the real productivity killer isn't the model being wrong. It's you being afraid the model might be wrong. Fear makes you approve every edit one at a time, babysit runs that don't need babysitting, and stop the agent right before it would have finished. You bought a power tool and you're using it like a butter knife because you can't afford the damage.

The fix isn't a better model. It's making damage cheap. Two git features you already have — relentless checkpoint commits and worktrees — turn "the agent might wreck something" from a catastrophe into a thirty-second inconvenience. Once rollback is free, you can let agents actually run, and that's where the productivity everyone talks about really lives.

Checkpoints: commit like it's free, because it is

A checkpoint is a commit whose only purpose is to mark a known-good state you can return to. Not a crafted, reviewed, well-messaged commit — a savepoint. The command is one line:

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

Run it before every autonomous agent run. Every one. The moment you're about to say "go ahead and implement the whole thing," checkpoint first. The commit costs three seconds; the absence of it costs an afternoon of untangling which of the agent's forty edits were good.

Then, when a run goes sideways, the recovery is instant:

# See what the agent actually did
git diff

# Throw it all away, back to the checkpoint
git reset --hard

# Or keep the run but rewind to any earlier checkpoint
git log --oneline
git reset --hard abc1234

The objection is always aesthetic: "my history will be full of garbage commits." Correct, and irrelevant — squash before you merge:

# Collapse the last 12 checkpoints into one real commit
git reset --soft HEAD~12
git commit -m "Add passwordless auth flow"

History stays clean, and during the work you had a savepoint every few minutes. Checkpoint relentlessly, squash later. There is no downside; there is only the memory of the one time you didn't.

One rule of thumb we hold hard: the 30-second rollback beats the 3-hour archaeology. Without a checkpoint, a bad agent run means reading diffs across a dozen files trying to separate the agent's good ideas from its bad ones, reconstructing what worked from memory. With a checkpoint, you reset, restate the task with what you learned, and re-run. The re-run usually finishes before the archaeology would have.

Worktrees: parallel agents without collisions

Checkpoints solve time — getting back to before. Worktrees solve space — running more than one agent at once without them destroying each other.

The failure they prevent is mundane and brutal: two agents in one directory. Agent A refactors a module while Agent B edits the same files for a different feature; A runs the tests and gets B's half-finished breakage; both spiral trying to fix problems the other one is actively creating. We've watched this burn an evening. The rule is absolute: never two agents in one working copy.

A git worktree gives each agent its own directory, checked out to its own branch, all backed by the same repository:

# From your main repo directory:
git worktree add ../proj-builder feature/auth
git worktree add ../proj-experiment feature/auth-alt

# Each is a full working directory on its own branch.
# Point one agent at ../proj-builder, another at ../proj-experiment.

git worktree list

Now the agents are physically incapable of colliding. Each has its own files, its own build artifacts, its own test runs. Branches, commits, and history all flow into the one shared repo, so when the runs finish, harvesting is ordinary git:

# Merge the winner
git checkout main
git merge feature/auth

# Delete the failure - directory and branch, gone
git worktree remove ../proj-experiment
git branch -D feature/auth-alt

That harvest step is where worktrees quietly change your strategy. Because failures are free to discard, you can run competing approaches: two agents, two worktrees, same task, different instructions — merge whichever solution survives review, delete the other without ceremony. You'd never do this with one working copy; with worktrees it's Tuesday. The full team-shaped version of this idea is in our multi-agent coding teams field guide.

The rules, as a checklist

1. Everything lives in a git repo. No repo, no safety net, no autonomous runs. git init is free.
2. Checkpoint before every autonomous run. git add -A && git commit -m "checkpoint: ..." — before, not after.
3. Never two agents in one working copy. Second agent means second worktree. No exceptions, including "it's just a quick fix."
4. One worktree per agent, one branch per worktree. Name them so you can tell them apart at a glance: proj-builder, proj-reviewer.
5. Harvest, then clean up. Merge winners promptly, git worktree remove losers immediately. Stale worktrees become mystery state.
6. Squash checkpoints before merging. Savepoints are for you; history is for the team.

What changes when damage is cheap

The habits above take a day to install and then they're automatic. What you notice afterward isn't the mechanics — it's the psychology. You stop hovering. You give agents bigger, more ambitious tasks because a failed run costs a reset instead of an evening. You experiment with approaches you'd never have risked, because the experiment lives in a disposable worktree. The agents didn't get better; you stopped driving with the handbrake on.

In our own setup the checkpoint-before-run and worktree-per-agent steps are automated — it's one of the things The Vibe Father handles so we can't forget — but everything in this playbook is plain git, and plain git is enough. If you're gearing up to actually ship something with this workflow, ship your first product with AI agents walks the whole road, guardrails included.