When a coding agent enters your workflow, the artifacts of version control shift in meaning, not drastically or all at once, but enough to require deliberate adaptation. Simon Willison’s guide on using git with coding agents covers the operational patterns well: commit before invoking an agent, keep sessions bounded, use worktrees for parallel work. Those practices are correct and worth internalizing.
What the guide leaves open is the subtler question of what git history is for after those sessions have run. The operational discipline produces a log, and that log now has different properties than one produced by human commits. Understanding those differences changes which git habits are still valuable, which need updating, and which can be mostly ignored.
The git blame problem
The first thing that changes is what git blame tells you.
Traditionally, git blame on a function answers: who wrote this, when, and why (via the commit message). The who is useful for knowing who to ask questions; the when is useful for understanding what environment constraints shaped the code; the why, if the commit message is good, explains the decision.
When an agent writes code, the who becomes less useful. If the blame annotation shows Claude or Aider as the author, that tells you the code was generated, but not much else. The model version is rarely recorded, the prompt is rarely preserved, and the agent’s reasoning is not stored anywhere accessible from the blame view.
This does not make git blame useless, but it shifts what you should look for. The useful signals in agentic blame annotations are the commit message (what was the task) and the timestamp relative to surrounding human commits (what was happening in the codebase when this was generated). Both require good commit discipline to be meaningful.
Commit messages have two audiences now
The practice that matters most, and is least discussed, is writing commit messages as context for future agent sessions, not just for human readers.
When you work in a codebase over weeks, you accumulate an agent-readable history. Many workflows pass recent git log output to coding agents at session start to give them temporal context, a sense of what changed recently and why. If your commit messages are terse, the agent learns nothing useful from that history.
The difference between these two messages is significant when an agent reads them:
# too sparse
fix auth bug
# useful as agent context
fix null dereference in auth middleware when session token expires mid-requestThe second message tells a future agent what was wrong, where, and under what condition. That specificity helps the agent avoid reintroducing the same class of bug or proposing changes that conflict with the fix.
Some teams take this further and embed the original prompt or task description in the commit body:
git commit -m "add exponential backoff to token refresh endpoint
Agent task: The token refresh endpoint returns 429s during traffic spikes
but the caller retries immediately. Add exponential backoff with jitter,
capped at 32 seconds, aborting after 5 attempts."This makes the commit body searchable with git log --grep and preserves the stated intent alongside the code. It also creates a record of what the agent was asked to do, distinct from what it produced, which is useful for debugging divergences between intent and implementation.
The noise problem
A medium-complexity agent session can produce dozens of commits, several of which are false starts that the agent immediately reverts or supersedes. This is useful within the session for granular rollback, but produces noisy permanent history when it lands in the main branch.
Three strategies for managing this:
Squash merge: git merge --squash agent/feature-branch collapses all agent commits into a single staged changeset, which you then commit with a clean message. This discards the intermediate history entirely, which loses rollback granularity but keeps the main branch log readable. Appropriate when the agent session was exploratory and the intermediate commits are noise.
Interactive rebase before merging: git rebase -i main on the agent branch lets you squash, fixup, or reword specific commits, preserving useful checkpoints while collapsing the false starts. More work than squash merge, but retains commits that represent genuine logical steps.
Convention-based filtering: If you suffix agent commits consistently, git log --grep="\[agent\]" can filter them out of general log views. Teams using Aider get this automatically because Aider prefixes every commit message with aider:. You can achieve the same with a CLAUDE.md instruction for Claude Code:
## Commit messages
Suffix every commit message with [agent].
Valid format: `type: description [agent]`The resulting log is filterable, and the annotation makes clear at a glance which commits were agent-generated for anyone who runs git log --oneline on the branch.
Where git bisect gets easier
One place agent commits are unexpectedly useful is git bisect.
Agents tend to commit at logical boundaries because each commit represents a completed subtask, not just a save point. A human working through a feature may save ten times during a single logical change; an agent typically produces one commit per discrete operation. This means agent commit history tends to be more semantically granular, even if it is noisier overall.
When a regression appears in agentic code, bisect finds it efficiently:
git bisect start
git bisect bad HEAD
git bisect good main
git bisect run npm testBecause agent commits correspond to discrete changes, the bisect result points to a specific operation rather than an accumulation of edits. The commit message, if written well, tells you what that operation was and why it was made.
Interactive staging as the review checkpoint
Interactive staging is among the more underused practices in agentic git workflows. Before committing any agent-produced changes, walking through them hunk by hunk is worth the time:
git add -pAgents add debug statements they forget to remove, touch files outside their stated scope, and occasionally write changes to the wrong location. git add -p forces you to look at each change individually rather than staging the session wholesale.
This step also lets you accept partial session output, staging the correct hunks and leaving the problematic ones for cleanup. The result is a commit that contains exactly the changes you have reviewed, not everything the agent happened to produce.
The interactive staging step is also where you might catch the agent having committed to a particular implementation approach worth reconsidering before making it permanent. The diff-hunk view surfaces implicit decisions that are easy to miss in a full-file read.
Pre-commit hooks as the automatic layer
Pre-commit hooks run before every commit regardless of whether a human or agent triggered it. That automaticity makes them more valuable in agentic workflows.
With Aider’s auto-commit mode, every agent operation triggers any pre-commit hooks you have configured. A hook that runs type checking catches Aider introducing type errors before they are committed, without any human attention:
#!/bin/bash
npx tsc --noEmit
npm run lint --silent
git secrets --scanIf the hook fails, the commit fails, and Aider sees the failure and attempts to fix it. This creates a feedback loop that operates below the human review layer. Tools like pre-commit, husky, and lefthook all work here and integrate cleanly with both auto-committing and manual-committing agents.
One caveat specific to this pattern: when a pre-commit hook fails, the commit did not happen. If you then fix the issue and commit again, create a new commit rather than amending. Amending in this situation modifies the last successful commit, not the failed attempt, which silently corrupts the history you are trying to maintain.
What the history tells you
Git history becomes a different kind of document when agents write code. It is still a record of changes, but the provenance annotations from git blame shift from answering “who should I ask about this” to “what was the state of the codebase when this was generated.” Commit messages shift from communicating to future human reviewers to also communicating to future agent sessions. The log becomes as much an input to the next agent invocation as a record of the last one.
This does not require different tools. It requires using existing tools more deliberately: writing commit messages that preserve intent as well as describing changes, tagging agent commits consistently, using git add -p to review before staging, and letting pre-commit hooks catch the automated errors that agents introduce without announcing. The workflow infrastructure was already there; the agentic context gives you better reasons to use it.