How should I review a pull request an agent wrote?
By Soumen Sarkar · October 2026
Short answer: Review an agent's pull request by its reasons first: check what it's for, the calls it made and what it assumed, spend your attention on the high-stakes ones, and fix what you find forward instead of holding the change at the gate.
Where should my attention go first?
To the reasons, not the diff. An agent's code is usually tidy; what goes wrong is a call it made without knowing something you know. The reasons tell you which calls it made and what it assumed, so you can check the few things that matter instead of reading every line with equal care.
Start with three questions:
- Is it for the right thing? Does the stated purpose match what the team needs?
- Are the calls sound? Each choice someone could reasonably have made differently.
- Are the assumptions true? Especially the ones you happen to know the answer to.
If the pull request has no reasons, ask the agent for them before you read the code. It's faster for both of you.
Which parts deserve a slow read?
The high-stakes ones: changes touching data, money, access, public interfaces, or anything that deletes. A wrong guess there is expensive to undo. Everything else can be read at the speed it deserves, because a small mistake in a button label or a log message is cheap to fix after it lands.
That split is what lets a reviewer keep up with dozens of changes a day without either rubber-stamping or becoming the bottleneck.
What does that look like on a real one?
Say an agent's pull request adds an "auditor" role to admin settings, in Access · lib/auth/roles. Its reasons say:
- For: auditors can read billing and user lists but change nothing.
- Calls made: reused the viewer permission set and added billing read on top.
- Assumed: auditors may export the user list as CSV. Marked high stakes.
The reviewer skips the form markup and goes to the permission set and the export. The export assumption is wrong: exports include email addresses, and auditors shouldn't take personal data out. The reviewer writes one comment, "auditors: no CSV export, view only", the agent removes the export permission and adds a test, and the change merges within the hour.
What does fixing forward mean for review?
It means the review's job is to correct the course, not to guard the gate. If something minor is off, approve and fix it in a follow-up, or let the agent fix it straight away. Hold a change only for what would be costly once it's in: the high-stakes calls.
A fix should say what it changed and why, so the correction reaches whatever relied on the original call.
How does Campfyrr help reviewers?
In Claude Code, when a session commits or opens a pull request, Campfyrr writes the change's reasons from what the session recorded, and gives a link for the description. Assumptions about data, money, access, public interfaces or deletions are marked high stakes and shown first. Campfyrr never approves or blocks a change; your review and your CI still decide. It just makes sure you start with the reasons.
Words used here
- Reasons: Reasons are what a change is for, the calls made in it, and what was assumed, attached to the change for whoever reviews it.
- High-stakes assumption: A high-stakes assumption is an assumption that touches data, money, access, public interfaces or deleting things, so being wrong costs more and it should be checked first.
- Correction: A correction is the fix to a wrong assumption or call, made by someone who knows better and sent back to the work that relied on it, without stopping anyone.
The principle behind this: Fix forward: We don't guard the gate. We correct the course.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).