- Book: Prompt Engineering Pocket Guide
- The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
The agent says it's done. You open the branch: 40 files changed, a couple of thousand lines, two hours of work. The tests are green and the summary at the bottom reads well. You scroll for a few minutes, nothing jumps out, and you merge.
You didn't review that branch. You signed it.
Agents made writing code cheap. Reading it didn't get cheaper, and the final diff is the worst possible shape to read it in. My take: stop treating the branch as the unit of review. Review the agent one turn at a time, while it works, and keep the final diff for a last look.
Review is where the time went
This isn't only a feeling. Fiona Chen and James Stratton at Harvard studied about 300 million work events across 718 firms, from GitHub, Jira and calendar data (working paper, current version August 4, 2026). After firms adopted AI coding agents, lines of code went up 30%, commits 20% and pull requests 23%. Resolved Jira issues and epics showed small, statistically insignificant gains.
Their explanation is a review bottleneck. In the paper's words, "the average time to review a pull request increases by 49%, the share of pull requests with changes requested nearly doubles, and the number of comments per pull request increases by 35%." The share of workers doing code review went up 14%. It's a job market paper, observational, and not yet peer-reviewed, so treat the exact numbers with care. The direction will look familiar if you work with agents: the agent finishes fast, then the branch waits for a human.
Human attention hasn't scaled to match. SmartBear's guidance from its study of a Cisco team says to review "no more than 200 to 400 lines of code" at a time, that "beyond 400 LOC, the ability to find defects diminishes," to stay under 500 lines an hour, and to stop after about 60 minutes. That research predates coding agents, but the reader hasn't changed. A 2,000-line branch is several review sessions of work. Nobody books several sessions for a branch the agent already called done, so it gets the skim.
The unit of review is the turn
A branch mixes everything the agent did for two hours: the feature, the refactor it decided on along the way, the test it rewrote to pass, the lockfile it bumped, and the fix for its own mistake from forty minutes earlier. Reading that as one diff, you're reconstructing intent from the code.
A turn has one intent, and you wrote it. You typed "add a date filter to the orders endpoint," the agent worked, and it replied. The diff for that turn should look like a date filter. That gives you three quick questions per turn:
- Does this diff do what I asked, and only that?
- Did it touch anything I didn't ask about (config, lockfiles, CI, tests it made easier)?
- Does it undo or fight something from an earlier turn?
Those questions are easy on 150 lines and almost impossible on 2,000. A package-lock.json change in a turn about a date filter stands out. In the final diff it's one file among 40.
One small card you can actually read, next to the stack that gets stamped.
There's a second win. If you review turn 3 while the agent works on turn 4, review stops piling up at the end. When you catch a wrong turn early, you correct one prompt instead of untangling everything built on top of it.
Commit every turn with plain git
You don't need any new tool for this. Claude Code and Codex both have a Stop hook that fires when the agent finishes its reply. Both pass the hook a JSON object on stdin with the session's cwd and the agent's last_assistant_message. A short script can turn every reply into a commit.
Run the agent on its own branch, ideally in its own git worktree, then add this. It needs jq:
#!/usr/bin/env bash
# .hooks/commit-turn.sh: commit what changed this turn
set -euo pipefail
input=$(cat)
cd "$(jq -r '.cwd' <<<"$input")"
git add -A
# nothing changed this turn: exit quietly
git diff --cached --quiet && exit 0
msg=$(jq -r '(.last_assistant_message // "" | split("\n")[0])
// "agent turn" | .[0:72]' <<<"$input")
git commit --quiet --no-verify -m "turn: ${msg:-agent turn}"
Make it executable with chmod +x .hooks/commit-turn.sh, then register it in .claude/settings.json. Stop takes no matcher, so the handler sits directly in the group, as in the hooks reference:
{
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "\"${CLAUDE_PROJECT_DIR}\"/.hooks/commit-turn.sh"
}
]
}
]
}
}
Codex reads the same Stop shape from .codex/hooks.json, under a top-level hooks key. Codex runs hook commands from the session's working directory, so use .hooks/commit-turn.sh as the command there instead of the ${CLAUDE_PROJECT_DIR} path. It also asks you to review and trust project hooks before they run, and skips a changed hook until you trust it again.
Now every reply is one commit, and review is plain git:
# one entry per turn, oldest first, with files touched
git log --reverse --stat main..HEAD
# read one turn
git show <sha>
# drop one turn, keep the rest
git revert <sha>
# land it as a single commit
git switch main
git merge --squash agent/date-filter
git commit
Know what this script does before you trust it. git add -A stages everything git doesn't ignore, including edits you made yourself during the turn and any untracked secret file your .gitignore misses. --no-verify skips your own pre-commit hooks so a slow linter doesn't run after every reply. Drop the flag if you want those checks per turn. The commit message is the first line of the agent's reply, cut to 72 characters, which is usually a decent summary and sometimes just "Done."
Claude Code also has its own checkpoints: /rewind restores code to an earlier prompt in the session. It's good for quick undo inside a session. Its docs say it doesn't track files changed by Bash commands and isn't a replacement for version control, which is why the hook commits to git instead.
Each turn gets checked on its own, while the next one is still being made.
How Hermes IDE does it
I build Hermes IDE, so weigh this section with that in mind.
Hermes saves every agent turn, so you can diff or restore any single turn, with undo. It works the same way for every vendor's agent, so there's no hook to write per agent. The Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows a task's changes by turn or by file, with risk flags, and a line comment you leave there goes back to the agent that wrote that line.
Hermes 2.3.1, released October 13, 2026, makes the per-reply strip under each session easier to read. The strip is now labelled "Agent replies". Each chip is one reply from the agent with the lines it changed (+added −removed), so a reply that changed 600 lines when you asked for a typo fix stands out. Click a chip to see that reply's changes or restore your files to that point. When there are more replies than fit, the newest are shown and a "+N earlier" chip opens a list of every reply with its time, files and lines changed. In a task with extra folders, the strip says it tracks changes in the main project only, so you know what it isn't covering.
When the turns look right, Land commits, opens a pull request or merges locally in one step, and can be undone. Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.
Where the final diff still earns a look
Per-turn review doesn't replace a last look at the whole branch. Turns can cancel each other out: turn 2 adds a helper, turn 6 deletes it, and neither diff tells you whether the design that's left makes sense. After you've seen every turn, read git diff main...HEAD once. By then you're only confirming what you've already read, so it goes fast.
It also isn't free. On a task that took one or two replies, the final diff is the turn, and the hook is overhead. Agents that end many tiny replies in a row produce a long list of small commits, so read those in groups and squash when you land. None of this replaces tests or CI. Tests still decide whether the code works. This only moves the point where a human reads it.
How does your team review a long agent run today: the whole branch at the end, or piece by piece? Tell me in the comments.
If this was useful
Try the hook on your next agent task, or download Hermes IDE and open the Review Desk after a few replies. If per-turn review helps, star it on GitHub so other developers find it. Per-turn review only works when each prompt carries one clear intent, and the Prompt Engineering Pocket Guide covers how to write those prompts, the project instructions around them and the context the agent sees. It's one of 8 short Pocket Guides on agents, RAG, prompts, observability, events, databases and system design.
Top comments (0)