Why has code review become the bottleneck with AI agents?
By Soumen Sarkar · October 2026
Short answer: Agents now write changes faster than people can read them, so the slowest step is a person working out what a change is for and whether it's right. Review speeds up when every change arrives with its reasons, assumptions and the decisions it relied on.
What changed?
Agents changed how fast changes are written. A developer running several sessions can open more pull requests before lunch than they used to in a week, and the changes are often good. Review didn't change: it's still a person reading a diff and reconstructing the story behind it. Teams that measure it see the same thing: many more pull requests, larger ones, and review time going up with them.
The reviewer's hardest job isn't reading the code. It's answering questions the diff doesn't:
- What is this change for?
- What did the agent decide along the way, and why?
- What did it assume that nobody confirmed?
- Does it follow what the team decided last month?
Each question means a message to the author, and the author is probably running three other agents.
How do you take the wait out of review?
Make every change carry its own story, so the reviewer starts from it instead of reconstructing it.
- Reasons first. The description says what the change is for, the calls made in it, and what was assumed. See reasons.
- Assumptions marked. Anything the agent assumed is listed, so the reviewer can confirm or correct it in a line rather than discover it in the code.
- Decisions linked. If the change relies on a team decision, it says which one, so the reviewer checks the change against the decision, not against memory.
- Small pieces. Changes that land in small, visible steps are faster to read and easier to fix forward.
Reviewers then read in a different order: reasons, then assumptions, then the code that matters. The reviewing by reasons playbook walks through it.
What does that look like?
A pull request arrives: "Adds partial refunds. Decided: refunds go back to the original payment method. Assumed: shipping isn't refunded on partial refunds (confirm?). Follows the March decision that money is stored in whole pence." The reviewer confirms the one assumption, reads the refund calculation closely, skims the rest and approves. Ten minutes instead of an afternoon of messages.
Campfyrr writes those reasons as the agent works, from the assumptions and decisions it records, so they're attached to the change without anyone writing them up afterwards. More on this in how reviewers see why an agent made a change.
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).