Most conversations about AI coding agents focus on the prompt, the model, or the context window. The git workflow is treated as an afterthought, something you deal with after the agent finishes. That framing has it backwards. How you structure your git history before, during, and after an agent run determines whether you stay in control of the codebase or end up chasing a tangle of changes you can’t confidently review.
Simon Willison’s guide on using git with coding agents makes this concrete. The core idea is simple: git is not just a safety net for agent output; it is the interface through which you understand what the agent did and communicate expectations back to future runs. That reframe changes what practices actually matter.
Commit Before You Run Anything
The first discipline, and the one that pays off most immediately, is committing a clean working state before you hand control to an agent. This sounds obvious until you realize how often it gets skipped in the flow of a session.
When an agent runs against an already-dirty working tree, the resulting diff mixes your half-finished edits with everything the agent touched. Reviewing that becomes genuinely hard. Worse, if the agent takes the session in a direction you want to abandon, git checkout . is only clean if you had a clean baseline to begin with.
The practice is: git add -A && git commit -m "checkpoint before agent run" before every nontrivial agent session. Some people use git stash for shorter runs where they expect to pop the stash immediately afterward, but a real commit is more durable. You can always squash or clean up the history later; you cannot reconstruct a baseline you forgot to save.
This also gives the agent a well-defined starting point to describe in its own commits, which matters if you ask it to commit as it goes.
Branches Are the Minimum; Worktrees Are Better
For any agent task that will touch more than a handful of files, or that you want to keep separate from your main development thread, branches are the baseline. Create a branch named for the task, run the agent on it, review the diff against main before merging.
git checkout -b agent/refactor-auth-module
# run agent session
git diff main...HEADBut branches have a limitation that becomes visible the moment you want to run two agents in parallel. Two agents cannot work in the same working tree simultaneously without stepping on each other’s file modifications. This is where git worktrees come in.
A worktree is a second (or third, or fourth) checkout of the same repository at a different path, each on its own branch, all sharing the same .git object store. The objects and refs are shared; the working files are independent.
# Create a worktree for a parallel agent task
git worktree add ../my-project-agent-task agent/task-name
# List active worktrees
git worktree list
# Remove when done
git worktree remove ../my-project-agent-taskWith two worktrees open, you can run one agent session in ../my-project-agent-task and another in the main working directory simultaneously. Each has its own staged changes, its own untracked files, its own branch. When each agent finishes, you review its branch in isolation and merge or discard independently.
This is the setup that makes parallel agentic workflows feel manageable rather than chaotic. Tools like Claude Code, which can run as background processes, benefit directly from this: you fire off multiple tasks to separate worktrees, do other work, then come back to review the results.
How Agents Should Commit (and Why Most Don’t By Default)
Out of the box, most coding agents complete a task and leave all their changes uncommitted in the working tree. You get a big diff, you review it, you commit it yourself. This works for small tasks.
For longer sessions, it breaks down. An agent that makes fifty file changes across a two-hour session leaves you with a monolithic diff that is genuinely difficult to audit. You lose the narrative of what the agent decided and in what order. Bugs introduced mid-session get buried in noise.
The better pattern is instructing the agent to commit incrementally as it works. Claude Code supports this: you can tell it in the system prompt or per-session to commit after each logical step. The instructions might look like:
After completing each distinct step, commit your changes with a descriptive message
explaining what you changed and why. Keep commits focused on one change at a time.The result is a git history that reads like a record of decisions. When you run git log --oneline at the end of a session, you can see the agent’s reasoning arc, spot where it went off track, and cherry-pick or revert individual decisions without having to unpick a monolith.
This also interacts well with post-run review. Instead of git diff HEAD~1, you can do git log -p and step through the agent’s work commit by commit, approving or adjusting at each step.
The Diff Is the Primary Review Surface
One discipline that feels obvious but is worth stating explicitly: always read the full diff before merging or deploying agent-generated code. The agent’s summary of what it did is not a substitute. Models describe their intentions; the diff shows what actually happened.
# Compact overview
git diff main...agent/feature-branch --stat
# Full diff with context
git diff main...agent/feature-branch
# Per-commit if agent committed incrementally
git log -p main..agent/feature-branchThis is where the earlier investment in clean baselines pays out. A clean git diff against a known good commit is fast to review. A diff contaminated with pre-existing noise takes much longer and is easier to misread.
For teams using pull request workflows, the PR diff is the natural review surface. Agents that can open PRs directly (several tools support this) fit cleanly into existing review processes, which is an underrated advantage: your code review tooling, CI, and approval requirements all apply to agent output the same way they apply to human output.
Git Hooks and Agent Behavior
Pre-commit hooks introduce an interesting dynamic with coding agents. Hooks that run formatters, linters, or type checkers on commit are generally beneficial when combined with agents, because they catch a class of errors the agent might introduce and provide immediate feedback that the agent can act on.
The tension arises when hooks fail and the agent, attempting to continue, passes --no-verify to bypass them. This is a signal to watch for. An agent that bypasses hook checks to make progress is trading short-term task completion for correctness guarantees. It’s worth including in your agent instructions an explicit instruction not to skip hooks, and to treat hook failures as errors requiring investigation rather than obstacles to route around.
Some teams go further and write hooks specifically for agentic workflows: a pre-commit hook that checks commit message format (useful for distinguishing agent commits from human ones in the log), or a post-checkout hook that logs which worktree a branch is active in.
Recovering from Agent Mistakes
The git tools for recovering from agent errors are the same ones you use for recovering from your own errors, which is a feature. git revert for published changes, git reset --hard for local ones, git bisect for tracking down when a regression was introduced across a sequence of agent commits.
Because agents can produce changes at a rate that exceeds careful review, it is worth developing the habit of checking git diff HEAD periodically during a long session rather than waiting until the end. Catching a bad turn in the middle of a session is cheaper than untangling it after twenty more commits have built on top of it.
Wilson’s framing from his guide is useful here: think of each git commit as a save point in a video game. The cost of saving frequently is low; the cost of losing progress because you didn’t save is not.
The Broader Point
Coding agents are fast at generating changes. The bottleneck shifts to review, integration, and verification. A git workflow designed for human-paced development, where the working tree accumulates changes over hours and a commit happens at a natural milestone, does not scale well to agent-paced development where the working tree can be rewritten in minutes.
The adaptations are not exotic. Commit before running. Use worktrees for parallel work. Ask the agent to commit incrementally. Read the full diff before merging. Respect your hooks. These are mostly existing git disciplines applied more consistently.
What changes with agents is the consequence of skipping them. A developer who forgets to commit before a refactor can usually reconstruct intent from memory. An agent session that runs untracked for two hours against a dirty tree leaves you with something much harder to reason about. The practices matter more because the pace is higher and the agent has no stake in making the history readable.
Git was designed for collaboration across time and across contributors who don’t share context. Coding agents are, in a meaningful sense, a new kind of contributor without persistent context. The existing tooling handles this well if you let it.