FredrinAI code review means two jobs that share a name. One is a model reading your pull request and leaving comments — a feature you can switch on this afternoon. The other is you reading a diff a model wrote, which decides how much work you can actually ship, and which almost nothing in the tooling market is aimed at.
This post covers both, and then the part nobody sells: what your day looks like when three agents finish at once and every diff needs a person before it merges. If those three are Claude Code sessions, the setup that gets them there is a separate guide; this one starts where they stop.
What is AI code review?
AI code review is a language model reading a change and reporting what looks wrong — logic errors, unhandled cases, security patterns, drift from local convention — usually as inline comments on a pull request. It is advisory by design. Every major implementation posts findings and leaves the merge decision to a human.
The direction matters, because the economics invert. A model reviewing human-written code is a second opinion on work someone already understands. A human reviewing model-written code is the only opinion, on work nobody understands yet. That inversion is the defining consequence of handing an agent a goal instead of a line.
Why review became the bottleneck
Because generating a change got dramatically cheaper while reading one did not. A model produces a few hundred lines faster than you can read the first hunk of them, and reading is the part that did not speed up. Start three agents at once and you have built a queue, not capacity. Review is where throughput is decided.
This is not a new observation, it is newly load-bearing. Google's published guidance warns about the size effect: it is easier for a reviewer to find five minutes several times to review small changes than to block out half an hour for one large one, and on large changes "important points get missed or dropped." Agents make large changes effortlessly. The reviewer's day did not get longer. The arithmetic of that ceiling is in running five client engagements in parallel.
AI code review tools, compared honestly
Five products come up most often, and they differ less than the marketing suggests. All of them read a diff, most read the surrounding repository, and all of them post comments rather than verdicts. Choose on where your team already works, then spend your effort tuning what gets flagged.
| Tool | Where it runs | Best at | Won't do |
|---|---|---|---|
| GitHub Copilot code review | GitHub PRs, plus VS Code, Visual Studio, JetBrains, Xcode | Zero-setup first pass with one-click suggested edits | Approve or block — it always leaves a comment review |
| Claude Code Code Review | GitHub PRs via a managed app; /code-review locally | Correctness bugs, severity-tagged, tuned by a file in your repo | Gate the merge — its check run is always neutral |
| Cursor Bugbot | GitHub PRs, and /review inside Cursor | Teams already living in Cursor; it can spawn an agent to fix what it found | Help much if your team is not in Cursor |
| CodeRabbit | GitHub, GitLab, Azure DevOps, Bitbucket, plus IDE and CLI | Breadth of platform coverage and PR walkthroughs | Stay quiet by default; expect to tune the noise |
| Greptile | GitHub and GitLab PRs | Findings that depend on repository-wide context, not just the diff | Read code it has not indexed |
Notice what the last column agrees on. GitHub documents that Copilot always leaves a "Comment" review, so its reviews "do not count toward required approvals" and "will not block merging changes." Anthropic documents that Code Review's check run "always completes with a neutral conclusion", so it never blocks a merge. Two of the largest vendors in the category shipped that default deliberately: if you were hoping to hand the gate to the machine, they have closed the door.
Keep one category separate: linters, type checkers, and static analysis are cheaper, deterministic, and they can block a merge. Anything a linter catches should be caught by a linter.
What these tools catch, and what they miss
They are good at local correctness: an unhandled null, a swallowed error, a race between two lines visible at once, a convention the rest of the file follows. They are weak on the question an experienced reviewer asks first — whether this change should exist in this shape at all — because the answer is mostly not in the diff.
Google's checklist is ordered, and design is first: "The most important thing to cover in a review is the overall design of the CL." A diff-scoped reviewer is structurally bad at that. It can tell you the function is correct. It cannot tell you the function should not have been written.
The vendors are honest about it — GitHub's documentation says Copilot "is not guaranteed to spot all problems or issues in a pull request." Treat the bot pass as a filter for the boring findings, not as coverage.
A workflow for reviewing agent-written diffs at volume
Write acceptance criteria before the agent starts, keep one intent per branch, let the bots comment first, then spend human attention on tests, boundaries, and running the thing. Reject with a specific constraint rather than a mood. The order matters more than any individual step in it.
- Write the acceptance criteria first. "Uploads over 50MB return 413 with a JSON error body, and the existing multipart path is unchanged." Written before the work, that is a specification the agent builds toward. Written after, it describes whatever happened.
- One intent per branch, enforced physically. A change confined to its own branch and working directory cannot quietly become three. Scope you intend to keep decays under time pressure; scope the filesystem enforces does not. The mechanism is a working directory per branch, not a promise to yourself.
- Let the machine go first. The bot pass costs you no attention and removes findings that would have. Read its comments before the diff.
- Then read like a reviewer, not a proofreader. Tests first — they tell you what the change believes it is doing. Boundaries next. Then run it.
- Reject with the constraint, not the verdict. "This must not hold the lock across the network call" produces a better second attempt than "wrong, fix it." One is a specification; the other is a mood the model has to guess at.
If step four keeps taking twenty minutes, the problem is upstream in the list. Difficulty understanding a diff is itself a finding — send it back smaller.
What tired reviewers skip
The failure modes of model-written code are not the failure modes of human-written code. A person writes something wrong in a way that makes sense, because they misunderstood the requirement. A model writes something wrong in a way that looks right, because plausibility is what it optimizes. Fatigue removes exactly the checks that catch the second kind.
- Unrequested breadth. A diff larger than the request means the model decided something. Find what it decided; that is where the surprise lives.
- Tests that assert the implementation. They pass. They would pass if the behavior were wrong. Check the test fails against the old code.
- Invented references. Library versions, configuration keys, API shapes. Confident citation of something that does not exist reads exactly like knowledge.
- The error path. Empty input, the concurrent case, the failure of the thing being called. That is where confident-and-wrong survives.
- The deleted lines. Diff readers watch the additions. A quietly removed guard clause is the most expensive thing a tired reviewer waves through.
Acceptance checks an agent cannot grade for itself
The weakest link in any AI code review workflow is self-assessment — a model reporting that its own work is done. The fix is not distrust, it is format. An acceptance check should be a command and an exit code, agreed before the work starts and reproducible by the reviewer in seconds, not a paragraph claiming success.
In Fredrin that is the ticket plan: acceptance checks written before the agent starts, and on finishing, the agent submits the commands it ran with their real exit codes. A red check opens no pull request. The ticket lands in a review column where a human ships it or sends it back, with the rejection reason attached to the work when it resumes.
The concession: an agent reporting its own exit codes is still self-reporting, and a test suite that asserts the wrong thing passes just as loudly. The format does not buy certainty, it buys cheap verification — pnpm test → 0 can be re-run in seconds, and "I verified this works" cannot be checked at all. The human still reads the diff. That is not a gap in the design; it is the design.
Does any of this need a tool?
Mostly no. Acceptance criteria are a habit, small changes are a habit, reading the tests first is a habit — none of that ships in a product. Three parts are structural, though: isolation, so scope is a physical fact rather than an intention; a review column, so finished work sits somewhere visible; and rejections that reach the next attempt.
That is the shape of Fredrin; the rest is on the features page. The context half — how written-down conventions stop an agent repeating a wrong assumption weekly — is Memory. The same problem from the client's side is shipping AI-generated code a client will accept.
FAQ
Can an AI reviewer replace a human reviewer? Not today, and the vendors do not claim it. Both GitHub and Anthropic ship their reviewers as comment-only, so neither can approve or block a merge. Treat the bot as a first pass that clears noise.
Does an AI code review tool block merging? By default, no. Copilot leaves a comment review that does not count toward required approvals, and Claude's Code Review posts a neutral check run. If you want a gate, read the findings out of the check run in your own CI and decide there.
Which tool should I start with? Whichever is closest to where your team already works — that decides adoption more than accuracy does. Start with the built-in option on your git host, then add a dedicated reviewer once you know which findings you keep wishing you had.
How do I stop the bot leaving forty style comments?
Move everything a linter can catch to the linter, then cap the rest in configuration. Most reviewers read a rules file from your repository — Claude's reads CLAUDE.md and REVIEW.md — and a written cap beats ignoring the comments.
Should the agent that wrote the code review it? As a first pass, sure — it is cheap and it catches its own obvious mistakes. As the last pass, no. The context that produced the error is the context judging it.
What is the single habit that pays for itself fastest? Writing acceptance criteria before the work starts. It turns review from open-ended judgment into checking a claim against evidence, which is the largest single lever on how long a review takes.
Fredrin is a desktop kanban for running many AI coding agents in parallel — every ticket gets its own branch, worktree, and agent session, and nothing merges without a human review. Free on macOS and Windows, on the AI subscription you already pay for: fredrin.com.
