Review is the bottleneck when agents write the code
By Soumen Sarkar · October 2026
Problem. "I can't tell why an agent did that, so review is the bottleneck."
Agents write good changes faster than people can work out what each one is for. Review moves again when every pull request arrives with its reasons: what it's for, the calls made, what was assumed. Read those first, then the code they point to.
Why can't I tell why an agent did that?
Because the diff shows what changed, not why. An agent can write a careful change in twenty minutes, but the reasoning behind it stays in a session the reviewer never saw. So the reviewer reconstructs it from the code, or messages the author, who is busy running three other sessions.
That reconstruction is the slow part of review today. Reading code is quick. Working out what a change is for, which calls it made, and what it took for granted is not.
Why is review the bottleneck now?
Building got easy, and review didn't change shape. Each developer opens more pull requests, and each one still lands on a person who has to understand it.
The numbers point the same way. Faros AI looked at telemetry from over 10,000 developers on 1,255 teams. On teams that use AI heavily, engineers merged nearly twice as many pull requests, and review time on them nearly doubled (Faros AI, The AI Productivity Paradox, 2025). The agents did their part. The wait sits between the person who started the work and the person who checks it.
What do teams do about it?
Most teams try one of three things:
- Read every line anyway. Careful, but the queue grows and everyone waits behind it.
- Approve on trust. Fast, but the review falls downstream, onto whoever meets the change first.
- Ask for better descriptions. The right idea, but a description written from memory at the end leaves out what was tried, dropped or assumed along the way.
The fix that holds is to make each change carry its own story, written while the work happens. Google's code review guide already puts this first: before any file, look at the description and ask whether the change makes sense at all (Google engineering practices, Navigating a CL in review). Reasons make that first step answerable.
What should I read first in an agent's pull request?
Read in this order. Stop as soon as something is wrong.
- Read what the change is for. Check that it is the right thing to build.
- Read the calls made. Check each against the team's decisions.
- Read the open assumptions. Confirm or correct each one in a line.
- Read what was tried and dropped. Do not ask for it again.
- Read what it builds on and what is not done yet.
- Read the code where the reasons point. Give high-stakes areas the closest look.
When something is off, correct it with a small follow-up rather than holding the whole change at the gate. That is fix forward. The reviewing by reasons playbook walks through it with an example, and how to review agent pull requests covers the common questions.
What does Campfyrr do, and what doesn't it do?
Campfyrr writes the reasons for you. While a session works, it records the decisions made, the assumptions stated and the approaches dropped. When the session commits or opens a pull request, the Claude Code hook writes a reasons page from that record and tells the agent to put the link in the pull request description. The page has the same sections as the list above: what it's for, calls made, tried and dropped, assumptions, builds on, and not done yet. Each call links to the decision itself, so a reviewer reads the full reasoning, not a summary.
What it doesn't do:
- It doesn't review the code. Keep your reviewers, and keep any review bot you trust; it checks the diff, the reasons explain the intent.
- It doesn't run tests or replace CI.
- It only knows what was recorded. If a session recorded nothing, there is no reasons page to write.
Where do I start?
- Connect Campfyrr to Claude Code. The hooks come with it.
- Open your next agent pull request. Click the reasons link before the diff.
- Copy the change reasons template for changes made outside Campfyrr.
For the wider picture, read why review became the bottleneck with agents.
Everything on this problem
- Comparison: Campfyrr vs Entire: finding out why an agent did it, or telling the next one first: If your problem is finding out why an agent did something after it's done, use Entire: it keeps the full session behind every commit in git, so a reviewer can trace a line back to its prompt. If your problem is the next session undoing a call it never heard about, use Campfyrr: it gives that session the team's decisions and reasons before it edits. Many teams have both problems.
- For you: For engineering leads running a team on Claude Code: If you lead a team on Claude Code, you are probably the router: sessions don't know about each other, questions wait for you, and pull requests arrive without their reasons. Campfyrr briefs every session, routes assumptions to the person who knows, and puts reasons on every change. A team can set it up in about an hour.
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).