How do reviewers see why an agent made a change?
By Soumen Sarkar · October 2026
Short answer: Reviewers see why an agent made a change when the change carries its reasons: what it's for, the calls made in it, what was assumed and what was tried and dropped. Those reasons go in the pull request description, written for the reviewer.
Why isn't the diff enough?
A diff shows what changed. It doesn't show why one approach was chosen over another, what the agent assumed when the ticket was vague, or which obvious-looking alternative was tried and failed. Those are exactly the things a reviewer needs to judge the change.
Without them, the reviewer either guesses or goes and asks. At dozens of changes a day, asking doesn't scale, and guessing lets the important calls slip through unexamined.
What should the reasons say?
Four short parts are enough:
- What it's for: the outcome, in one or two sentences.
- Calls made: each choice that someone could reasonably have made differently, with its reason.
- Assumed: what the agent didn't know and decided to assume.
- Tried and dropped: the approaches that didn't work, and why.
Write it for the reviewer, not for the agent. Plain sentences, outcome first. The change reasons template gives the shape.
What does that look like on a real pull request?
Say an agent changes how product search ranks results, in Search · lib/search. Its pull request description reads:
- For: in-stock products now rank above out-of-stock ones for the same query.
- Calls made: applied the stock boost after text relevance, not before, so a perfect title match that's out of stock still shows on page one.
- Assumed: "in stock" means available in any warehouse, not the shopper's nearest one. Not confirmed.
- Tried and dropped: filtering out-of-stock items entirely; it emptied results for rare products.
The reviewer now knows where to look. The ordering call is deliberate, so it's not a bug. The warehouse assumption is the one thing worth checking, and the reviewer happens to know the answer: it should be the nearest warehouse. One comment, a small fix, done.
How do I get agents to write this every time?
Make it an instruction, not a hope. A line in your agent instructions such as "every pull request description includes what it's for, the calls you made, what you assumed, and what you tried and dropped" works with Claude Code, Codex and Cursor alike.
The harder part is capturing the reasons while they're fresh. An agent that records its calls and assumptions as it makes them can assemble the reasons at the end. One that tries to reconstruct them from the diff will miss the dropped approaches, because those never made it into the code.
What does Campfyrr add?
In Claude Code, when a session commits or opens a pull request, Campfyrr writes the change's reasons from what the session recorded as it worked: its goal, the decisions it logged, its stated assumptions and what it tried and dropped. It gives a link to put in the pull request description. Campfyrr doesn't read your code or diffs, and it doesn't approve or block anything; the reasons simply arrive with the change, so the reviewer can judge it without asking.
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.
- Assumption: An assumption is the best available answer to an unknown, stated and acted on, kept visible so anyone can correct it.
- Decision: A decision is a call made in the work, recorded with its reason at the moment it is made, so it travels to everyone who touches the same ground.
The principle behind this: Let the work speak: Our work explains itself, so nobody ever has to come and ask us.
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).