Simon Willison’s guide on using Git with coding agents is part of his broader agentic engineering patterns series, and it documents something that takes a while to notice: Git usage shifts when you work with agents, not dramatically, but in ways that compound over time if you don’t make them deliberate.
The underlying mechanics of Git haven’t changed. What changes is the purpose each operation serves.
Commits as Checkpoints, Not Just History
In a solo workflow, commits are semantic units. You commit when a feature is complete, a bug is fixed, or a refactor reaches a coherent state. The message describes intent. The diff is the work.
When an agent is writing code, that contract loosens. An agent working through a multi-file change might correctly modify six files and introduce a subtle error in a seventh. The agent’s reasoning may look sound in the terminal output, and the change may even pass tests, but something is wrong that only surfaces later. Without frequent commits, your recovery path is reading a large diff and manually reverting changes. With commits at each meaningful step, you can git bisect your way to exactly where things diverged, or simply reset:
git reset --hard HEAD~2The mental model shift is from “commit when done” to “commit before the agent does something I can’t fully predict.” You commit before you prompt, then again after you review what came back. The commit becomes a snapshot of a known good state, not a record of completed work.
Willison describes this as committing atomically and often. The “atom everything” pattern he references is about granularity: small, frequent commits give you a fine-grained undo history that matches the agent’s task boundaries rather than your own logical units.
Start Clean, Stay Clean
Every agent session should start from a clean working tree. git status showing nothing is the prerequisite. If you have uncommitted work in flight when you start an agent session, the resulting diff will mix your changes with the agent’s changes, and separating them later is tedious.
git stash # preserve any WIP
git status # confirm clean
# now prompt the agentThis discipline also makes the post-session review meaningful. A clean starting state means git diff shows exactly what the agent did. Nothing else. The diff becomes the ground truth, separate from any terminal output or explanation the agent produced.
git diff and git add -p as the Review Interface
Agent output in the terminal can be verbose: reasoning chains, status messages, summaries of what was changed. The diff is what actually matters. Making git diff the first thing you look at after an agent session is a habit worth forming early.
git diff # full picture
git diff src/auth/ # scoped to a directory
git diff --stat # files changed, line countsgit add -p is the most useful tool here for cases where the agent’s output is mostly right but not entirely. The -p flag (or --patch) stages changes interactively, one hunk at a time. You can accept the hunks you trust and skip the ones you don’t, then commit only the subset of changes you’ve reviewed:
git add -p # stage hunk by hunk, y/n/s to split
git commitThis is a forcing function. You cannot accidentally commit a file you didn’t look at. The physical act of reviewing each hunk is the review step, not something you do separately afterward. For large agent-generated diffs, this turns an overwhelming wall of changes into a manageable triage process.
Branches as Task Boundaries
Using a dedicated branch per agent task is good practice for the same reasons it’s good practice in general, but with agents it also serves as a naming convention for the work. A branch called agent/add-rate-limiting or agent/refactor-auth-middleware makes it visible in git log --oneline --all which changes originated from agent sessions.
git checkout -b agent/add-pagination
# run the agent session
git diff
git add -p
git commit -m "Add cursor-based pagination to /api/posts endpoint"
git checkout main
git merge agent/add-paginationOver time, the branch naming convention gives you a lightweight audit trail. It also makes the review story cleaner when you’re merging back: the diff between main and the agent branch is the full scope of what the agent produced, visible at a glance.
Worktrees for Parallel Agent Sessions
The structurally interesting change that coding agents introduce is the possibility of running multiple sessions in parallel. You might want one agent working on a frontend component while another implements the corresponding backend endpoint, or you might want to run two different prompting strategies on the same problem to compare the results.
Git worktrees make this practical without the overhead of cloning the repository multiple times. A worktree is an additional working directory linked to the same .git repository. Each worktree can be on its own branch:
git worktree add ../project-agent-a -b agent/feature-a
git worktree add ../project-agent-b -b agent/feature-b
# list active worktrees
git worktree list
# clean up when done
git worktree remove ../project-agent-aEach directory functions as a full working tree. File edits in one worktree don’t affect the other. The .git directory is shared, so the branches are visible from both, and merging the results back is a standard merge or rebase.
Claude Code implements this pattern natively via an isolation: "worktree" parameter in its Agent tool. When set, a subagent gets its own temporary worktree, works in complete isolation, and the worktree is cleaned up automatically if no changes were made. If changes were made, the worktree path and branch name are returned so you can review and merge them. This makes speculative agent sessions, where you’re not sure if an approach will work, much less risky. You can let the agent explore without worrying about partial changes contaminating your main working tree.
Using Git History as Context
One pattern that gets less attention is giving agents access to the repository’s history as input context. An agent that can run shell commands can call git log, git blame, and git diff to understand not just what the code currently looks like, but why it looks that way.
Prompting an agent with “check the git log for src/auth.ts before making changes” tends to produce more considered edits than just handing it the current file. The history surfaces things that aren’t in the code: a conditional added after a security incident, a pattern that’s intentionally kept for compatibility, a module that was recently migrated and still has some rough edges.
git log --follow -p src/auth.ts # full history with diffs
git log --oneline src/auth.ts # summary view
git blame src/auth.ts # per-line attributionIn long-lived codebases, a significant portion of the context that explains the code lives in commit messages rather than comments. Giving an agent access to that history is giving it the archaeology of the codebase. This is especially true for files that have been through multiple owners or significant refactors.
What Git Doesn’t Cover
These patterns work well for managing file-level changes, which is the majority of what coding agents do. They don’t help when an agent takes actions with external side effects: sending API requests, modifying a database, writing to environment configuration, running scripts that change system state.
For those cases, Git records the code that enabled the action, not the action itself. A commit showing that a migration script was added doesn’t tell you whether the agent ran it. The safety model for external effects is elsewhere, typically in how you configure what actions the agent is allowed to take and whether those actions are reversible before they’re confirmed.
The Git workflow Willison describes is a solid foundation. It covers the case where the agent’s work is edits to files in a repository, and it covers that case well. The patterns, committing frequently, starting clean, reviewing diffs actively, using branches and worktrees for isolation, are worth making habitual even on small projects. The marginal cost is low, and the cost of not having a clean git history when something goes wrong with an agent session is high.
The underlying shift is treating git operations as active parts of the agent workflow rather than bookkeeping you do afterward. The commit-before-you-prompt, diff-before-you-commit loop is the interface through which you stay in control of what the agent is actually adding to your codebase.