AI review bots vs reviewing by reasons
By Soumen Sarkar · October 2026
Comparison. If your problem is bugs and slips in the diff, use an AI review bot such as CodeRabbit or Copilot code review. If your problem is a reviewer who can't tell what an agent's change was for, or which calls it made, use reasons on the pull request. Most teams running agents have both problems, so use both.
What are you trying to fix?
A review bot reads the diff and asks "is this code right?" Reasons tell the reviewer "what was this change for, and what did it decide?" Those are different questions, and an agent's pull request needs both answered.
- "Small bugs keep getting through review." A review bot. It reads every line, every time, and doesn't get tired at the fortieth file.
- "I can't tell why the agent did that." Reasons. The diff shows what changed; the calls made along the way stayed in a session the reviewer never saw. That's the review bottleneck.
- "Our customers find what nobody checked." Mostly reasons, plus plans and sample outputs shown before it ships. A bot can pass code that does the wrong thing well. That's review falling on the business.
Review bots are good, and getting better. GitHub's Copilot code review finds issues in a pull request and suggests fixes you apply in a click or two (GitHub Docs). CodeRabbit goes further toward intent: it reads linked GitHub, GitLab, Jira and Linear issues and flags requirements the change doesn't address (CodeRabbit docs). If the ticket holds the intent, a good bot checks against it.
What no bot can read is what was decided while the work happened. That never reached the ticket.
The same day, with each
Here's a scene, not a customer story. Three developers and a PM. The PM decided last week that trial accounts keep their data for 30 days after expiry, because sales wins back lapsed trials. Today Sam's agent cleans up the account-expiry code. It finds a retention window it reads as a leftover, shortens it to match paid accounts, and tidies three files around it.
With only a review bot, the bot reviews the pull request in minutes. It catches a missing null check and an unclear name, and suggests both fixes. The ticket said "tidy expiry code", and the change does that. Maya, the lead, sees a clean diff and a bot that's happy, and approves. Nobody asked about the window, because nothing on the page said it was a call. Next month a returning trial finds its data gone, and sales is the first reviewer.
With the bot and reasons, the bot does the same job. The pull request also links its reasons page. Under "calls made" it lists the retention change, and under "assumptions" it says the agent took the window for dead code. Maya reads that first, sees it clashes with the PM's decision, and corrects it in a line. The fix is a small follow-up, not a held-up change.
The bot made the code better both times. Only the reasons put the decision in front of Maya.
What do reasons look like, from our own record?
This is what the Campfyrr hook told one of our own sessions after a commit on 21 October 2026:
Campfyrr wrote the reasons for this change for its reviewer:
https://campfyrr.vercel.app/change/0aa2ccbc-4
Put this link in the pull request description when you open one.
The page behind it is for the team only. It has what the change is for, the calls made, what was tried and dropped, open assumptions, what it builds on, and what isn't done. It's written from what the session recorded as it worked, not from memory at the end. See it in context in the demo, and the reading order in reviewing by reasons.
When a review bot is the better choice
- Your agents work from clear tickets. If the intent lives in the issue, a bot that reads linked issues covers much of the "what was it for" question already.
- Your misses are mechanical. Null checks, edge cases, a security slip in a dependency call. That is what bots are built to find, and reasons won't find them.
- One person runs the agents and reviews their own work. You already know the calls you made. Reasons matter most when the reviewer wasn't there.
And a caveat in the bot's favour, from GitHub itself: Copilot "is not guaranteed to spot all problems", and its reviews don't count toward required approvals by default (GitHub Docs). That's honest, and it's the same with reasons: neither replaces the person who approves.
Campfyrr doesn't review code, run tests or replace CI. It only knows what sessions recorded.
What it costs
CodeRabbit: Essentials is $24 per developer a month billed yearly, or $30 monthly, and public repositories are free (CodeRabbit pricing). Copilot code review comes with Copilot Business and Enterprise, whose prices GitHub's plans page doesn't list; ask GitHub (GitHub Docs). Campfyrr: $9 per developer a month, minimum 3, or $7 billed yearly; business teammates are free (Pricing).
For 5 developers and 3 business teammates: CodeRabbit Essentials is five times $24, so $120 a month billed yearly. Campfyrr is five times $7, so $35 a month billed yearly, or $45 monthly. Both together, billed yearly, come to $155 a month. Campfyrr is free during early access.
The cost that matters more is the daily one. A bot needs nothing from anyone. Reasons need sessions to record their calls as they work, which the hooks prompt for, and a reviewer who clicks the link before the diff. Campfyrr never takes your code or diffs (Trust); a review bot has to read your code to do its job.
Verdict
Choose a review bot if your misses are in the code itself and your intent lives in clear tickets.
Choose reasons if your reviewer can't tell what an agent's change was for, or the calls it made reach customers before they reach a person.
Use both if agents write most of your pull requests. The bot checks that the code is right. The reasons check that it's the right change. Every product we looked at is in our research, and the common questions are in how to review agent pull requests.
The problem this answers: Review is the bottleneck: "I can't tell why an agent did that, so review is the bottleneck."
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).