AI code review tools for pull requests an agent wrote

AI code review tools were ranked for code people wrote

AI code review tools read a pull request and comment on the diff, and CodeAnt's 2026 roundup ranks twelve of them, CodeRabbit, Greptile and Qodo among them.

Roundups like it grade each tool on codebase context and signal-to-noise. Monterail's comparison tests three of them against eight criteria and names CodeRabbit the winner. Neither guide makes the author of the code a criterion, and for me that has become the first question. Most of the pull requests I read now come from an agent.

When the author is an agent, I care less about which tool reads the most context and more about who checks the reviewer. My numbers come from my own repository's review logs, and the rest from Cloudflare's account of its own review system, the most candid write-up of this at scale I have read.

The author can't be its own reviewer

Aldena's Code Review agent is a separate agent from the build agents whose diffs it reads, and it never edits the code it reviews.

Ask Claude Code to review the diff it wrote a minute ago, in the same session, and you get a second pass from the context that wrote it. That pass still catches leftover debug lines and typos. A wrong assumption gets through, because the reviewer shares it.

So a reviewer needs its own instructions and its own context. A different model helps too, when there is one to pick. Cloudflare splits the job across up to seven specialised reviewers, security and performance among them, with a coordinator agent that deduplicates their findings and judges severity. My own pipeline runs six review agents, security, performance and maintainability among them, plus the cubic CLI over each diff it polishes.

I also want a reviewer that never fixes anything. Once a reviewer edits, its findings turn into changes nobody asked for, and nobody reads them as findings anymore.

In Aldena the reviewer is a separate hire from the same roster as the Backend Build and Frontend Build agents, and its runtime, model and effort are set separately from theirs. A runtime can be Claude Code or Codex inside the conversation's sandbox, or your team's own API key.

A finding is a claim until something checks it

A triage agent in my pipeline ruled 153 of the 1,293 review findings logged on 34 pull requests merged from November 1 to 9, 2026 to be false positives.

That pipeline lives in my repository's .claude folder and isn't part of Aldena the product. After the reviewers report, the triage agent reads each finding against the code on disk and returns REAL or FALSE_POSITIVE with its own evidence. Only the REAL ones go to the agent that fixes code. Across those pull requests, 1,134 findings were fixed and 6 were left unfixed.

So about one finding in eight was wrong, and that verdict is the triage agent's. Treat that 12% as one repository's nine days and not a benchmark: the cubic CLI and a React Doctor agent, which scans React files, joined every review on November 8, partway through the window.

Without the check, each of those would have gone to an agent whose whole job is to fix what it's handed. That would mean changing working code to satisfy a reviewer that misread it, and the change arrives with a finding attached, so nobody looks twice.

The check works in the other direction too. In a bug fix that merged on November 9, a reviewer flagged that a hostile tool schema could stall the synchronous schema compile on Cloudflare Workers. The triage agent ran the case on workerd, the real Workers runtime, where a 1.1 KB schema took 33.8 seconds to compile, and the pull request dropped that schema validator.

When you evaluate a tool, ask what happens to a wrong finding. If the answer is that a developer dismisses it, that developer is your triage step, and their time is the cost.

A review covers only what it reads

On November 9, 2026, an end-to-end test in CI caught a bad blog link in a sentence that my AI review step never read after a rewrite.

The run was my marketing pipeline shipping the AI software factory post. A model reviewed the draft for machine-written tells, and a later rewrite reworded a sentence so that one link read "the roles". My end-to-end suite has a test that rejects any blog link whose text ends in "role" or "roles", because the product names its agents by what they do. CI failed on that test, one commit fixed the link, and the pull request merged on green.

The run's own log admits that the check after the rewrite never read the reworded sentence. A code review misses a late edit to code the same way.

A review has to run on the final diff, after the last edit. And the dumb checks stay, because a regex in a test caught what a model skipped, and it will catch it on every run.

Only a short list should reach a person

Cloudflare's AI code reviewer completed 131,246 review runs in its first 30 days, and Cloudflare says the bias is explicitly toward approval.

Those runs averaged about 1.2 findings each, and the low count is on purpose. Cloudflare "biased hard for signal over noise", and a single warning in an otherwise clean merge request still gets approved with comments. Engineers overrode Cloudflare's reviewer, which Cloudflare calls breaking glass, on 0.6% of merge requests. And the same post says it "isn't a replacement for human code review, at least not yet with today's models."

I agree with that shape. A reviewer that leaves thirty comments on every pull request teaches people to scroll past it, and the one comment that mattered goes unread with the rest.

In my pipeline the findings don't reach me as comments at all. The 1,134 fixed ones arrived as one line per polish run in the pull request body, with the fixes already in the diff. On November 9 my pipeline ran that polish on a 16-file change to the pipeline itself, a pull request still open as I write this. Six review agents and cubic looked at it. Four found nothing, and React Doctor had no React files to scan. The other two raised nine findings, and triage confirmed all nine. One was rated High, two were the same fix reported by two reviewers, and most of the rest were renames. My report still counts that pair as two findings, which is exactly the padding Cloudflare's coordinator exists to remove.

In Aldena, the Delivery agent's pull request reaches a person, and so does anything an agent stopped to ask. Questions and tool approvals land in the team inbox, grouped by project with the longest wait first. When an agent stops on several approvals and a question in one turn, they arrive as one batch. I can answer them in any order or allow every open approval at once, and the agent resumes after the last answer. The card below came from a Project Setup agent, and every agent's questions land the same way.

How I'd shortlist AI code review tools for agent-written work

A shortlist for agent-written pull requests comes down to five questions, and the first is who reviews the code.

• Who reviews? A separate agent with its own instructions and context, or the session that wrote the code asked to check itself. Only the first catches a wrong assumption.
• What does it read? The final diff after the last edit, and the diff again after the fixes. Cloudflare's average merge request got 2.7 reviews, the first plus one per round of fixes pushed.
• What does a finding look like? Severity, file and line, with duplicates merged. A count per severity tells me how bad a change is before I open it.
• What checks a finding? Something has to, before a fix lands. A tool without that step leaves the checking to whoever reads its comments.
• What reaches a person? The pull request and a short list, with the merge left to a human.

Before you buy, run each tool on your shortlist over ten pull requests you have already merged and count the findings you would have acted on against the ones you would have dismissed. That split is the tool's signal-to-noise on your own code.

How the review loop runs in Aldena

Aldena's Code Review agent reviews the working diff through five lenses (maintainability, security, performance, backend correctness and frontend correctness) and reports findings without editing code.

The working diff is the uncommitted changes plus untracked files, read in chunks so a large change doesn't get skimmed. The report groups findings as critical, high and medium, each with its file and line, and ends with a count per severity. The Code Review agent reports to the Delivery agent, which splits the findings into a backend lane and a frontend lane and hands each lane to the build agent that owns it, one at a time. After the fixes the diff goes back to the Code Review agent, for at most two rounds, and the loop stops early once a pass finds nothing critical or high.

Nothing in that loop checks a finding the way my triage agent does, and the fixes from the second round go into the pull request without another review. The person reading the pull request is the check on both.

When the loop ends, the Delivery agent branches, commits, pushes and opens the pull request against your default branch, then stops. It never merges; that step stays with you. Aldena's own tools, the git tools of each connected integration among them, run under an allow, ask or deny policy you set per project at the approval gate. Model choice is per agent, so the reviewer can run on a different model from the agents whose code it reads.

To try it, hire the Delivery agent, the Full-Stack Build agent and the Code Review agent into a project, wire the other two under the Delivery agent on the org chart, and give the Delivery agent a small ticket. Read the review report before you read the diff. If its critical and high findings are the ones you would have raised, keep the loop and grow the ticket size.