How to Review a CLI Agent's Changes Before Committing

How do you actually check an AI agent's work before you commit it — beyond skimming the diff and hoping? It's the question that separates people who trust agents from people who get burned by them, and the honest answer is that most developers review the wrong thing. They read the agent's explanation of what it did and nod along, when what they should read is the diff itself. Effective cli agent review changes discipline starts from one rule: the agent's account of its work is a hypothesis, and the diff is the evidence. Trust the evidence.

Let's break down what a real review looks like, because "just read the diff" is necessary but nowhere near sufficient.

What Is Reviewing a CLI Agent's Changes?

Reviewing an agent's changes means verifying, against the actual diff, that the change does what was asked, does only what was asked, and doesn't quietly do something else. Three separate checks: correctness, scope, and hidden side effects. Skip any one and you're not reviewing, you're rubber-stamping.

The reason this needs its own discipline is that agent changes fail differently than human changes. A human who's asked to fix a bug fixes the bug. An agent asked to fix a bug might fix the bug and reformat the file, reorder imports, "improve" an unrelated function, and delete a comment it judged unnecessary — all in the same diff, all reported as "fixed the bug." The extra stuff is where the risk hides.

git diff --,[object Object],   ,[object Object],

What this does: Shows the shape of the change before you read a single line of it. If you asked for a one-line fix and the stat shows eight files touched, stop — the scope is already wrong, and you know that in two seconds instead of twenty minutes.

Why It Matters

The stakes are that an unreviewed agent change carries risks a human change usually doesn't. The dropped helper function that passes tests because nothing calls it yet. The subtly weakened assertion that makes a test pass dishonestly. The reformatting that buries the one real line of logic in fifty lines of whitespace churn. None of these show up if you review by reading the agent's summary, because the agent's summary describes its intent, not its actual output — and the gap between the two is exactly the bug.

There's also a compounding effect over time. If you rubber-stamp agent changes, you train yourself to stop looking, and the one dangerous change in fifty gets the same reflexive approval as the forty-nine safe ones. Good cli agent review changes habits are a defense against your own future complacency as much as against any single bad diff.

⚡ Pro tip: Always commit your own work before the agent starts. If your working tree is dirty when the agent runs,

git diff

The CLI Agent Review-Changes Checklist

Run every agent change through the same five checks, in order.

Check one: scope.

git diff --stat

Check two: the real change. Read the diff and find the lines that actually accomplish the task. Confirm they do what was asked. This is the correctness check.

Check three: everything else. Read the rest of the diff — the parts that aren't the core change. Reformatting, reordering, "helpful" edits to unrelated code. Each one is untracked scope creep that should be questioned or reverted.

Check four: deletions. Search the diff specifically for removed lines. Deletions are the most dangerous edit because they're the easiest to miss — a removed function or a deleted branch of logic doesn't announce itself the way an addition does.

git diff | grep ,[object Object], | grep -v ,[object Object],   ,[object Object],

What this does: Isolates every line the agent deleted, stripped of additions and file headers. Deletions are where silent damage hides, so reviewing them explicitly — not just scrolling past them in the full diff — catches the dropped-function class of bug.

Check five: tests as evidence, not proof. Green tests are necessary but not sufficient. Read whether the agent changed the tests themselves — a fix that "passes" because it weakened an assertion isn't a fix.

⚠️ Common mistake: Approving because the tests pass and the summary sounds right. Tests only cover what they cover, and the summary describes intent, not output. The dropped-helper bug passes every test and reads perfectly in the agent's summary. Only the diff — specifically the deletions — reveals it. Read the evidence, not the story.

Making the Review Faster Without Making It Weaker

The objection to all this is speed: five checks per change sounds slow. The trick is to automate the mechanical checks so your human attention goes only to judgment.

A

--stat

[object Object],
files=$(git diff --cached --name-only | ,[object Object], -l)
[ ,[object Object], -gt 5 ] && { ,[object Object], ,[object Object],; ,[object Object], 1; }

What this does: Blocks a commit that touches more than five files, forcing large agent changes to be split into reviewable pieces. The scope discipline is enforced by the machine, so it holds even on the day you're tired and tempted to skip it.

⚡ Pro tip: Have the agent commit in small, logical units rather than one big commit. If you ask it to "commit each distinct change separately with a clear message," your review becomes a series of small, focused diffs instead of one giant one — and small diffs are the entire secret to reviewing quickly without reviewing carelessly.

⚡ Pro tip: Review the agent's changes on a branch, never on

main

Reviewing at Scale, When There's Too Much to Read

The checklist works for one change. What about a day where the agent produced twenty? This is where teams quietly abandon review, and it's the most dangerous moment — high volume is exactly when a bad change slips through. The answer isn't to read less carefully; it's to change the shape of what you review.

The first lever is smaller, more numerous commits instead of fewer large ones. Counterintuitively, twenty small focused diffs are faster to review than five big tangled ones, because each small diff has a single obvious purpose you can verify in seconds. Volume of commits isn't the problem; size of each diff is.

The second lever is using an agent to assist the review — with appropriate skepticism. You can pipe a diff to a second agent instance and ask it to flag anything suspicious: deletions, weakened assertions, scope creep. Crucially, this is a spotlight, not a substitute. The second agent points your attention at the risky parts; you still make the call.

git diff HEAD~1 | claude -p ,[object Object],

What this does: Uses a second agent pass to triage the diff and surface the parts most worth a human look. It never approves anything — it just concentrates your limited attention on the lines most likely to hide a problem, which is where review time should go anyway.

⚠️ Common mistake: Letting an agent approve another agent's changes. An agent reviewing a diff can flag concerns, but "looks good to me" from a second agent is not a review — it's two systems with the same blind spots agreeing with each other. The human approval is the point of the review; the agent only helps you spend that human attention where it matters.

⚡ Pro tip: When volume is genuinely overwhelming, slow the agent down rather than speeding your review up. It's better to have the agent produce five reviewable changes a day that you actually check than fifty you rubber-stamp. The bottleneck should be honest review capacity, not the agent's throughput — because unreviewed velocity is just faster risk.

Common Mistakes

⚠️ Common mistake: Letting the agent fix and refactor in the same change. "Fix the bug and clean up the file" produces a diff where the one-line fix is lost in fifty lines of reformatting, and you can't tell the signal from the noise. Insist on the fix alone, in the smallest possible diff. Refactoring is a separate change, reviewed separately, if it happens at all.

The second mistake is skipping the review when you're in a hurry — which is precisely when agent changes are riskiest, because you're moving fast and approving on reflex. The review is a fixed, small cost; the bug it catches is an unbounded one. Under deadline pressure, the checklist matters more, not less.

Conclusion

Solid cli agent review changes discipline treats the agent's summary as a claim and the diff as the proof. Check scope first, then the real change, then everything else, then the deletions, then whether the tests are honest evidence. Automate the mechanical checks so your attention lands on judgment, keep the review on a branch, and never let a fix smuggle in a refactor. Agents are fast; the review is what makes fast safe.

The checklist, the deletion-only diff command, the scope gate, the "commit in small units" instruction — these are the same for every change in every project. Save them in PromptABCD so your review process is a repeatable discipline instead of a skim-and-hope you reinvent under pressure.