An agent opens a pull request with a clean diff, and whether a human ever reads it depends on configuration most teams wrote before agents existed. Four gates sit between the change and a reviewer: who gets requested, whether a reviewer ran at all, what that reviewer was allowed to post, and whether any policy requires a human approval. Each gate can exclude the change without anyone noticing, and the same two fields drive all four, the author of the commits and the branch the change targets.
That is worth checking before you buy anything, because a reviewer that never runs looks exactly like a reviewer that found nothing.
The reviewer of record is chosen from the base branch, not the diff
GitHub reads CODEOWNERS from the base branch of the pull request, not from the branch the agent pushed. If the agent opened the PR against main but the ownership file lives on a release branch, no code owners are requested. The same rule applies to forks: the PR uses the upstream base branch's file.
Two more constraints in GitHub's CODEOWNERS documentation matter for agent workflows. Code owners are not automatically requested on draft pull requests, and they only get requested once the PR is marked ready. When the owner is a team, the team has to be visible and hold write permission on the repository, which is a common gap when ownership sits with a team that was renamed or moved.
Then branch protection decides whether the review is decorative. Requiring an approving review, or requiring approval from a code owner, is a separate setting from having owners at all. Two details in GitHub's protected branch documentation are easy to miss: restrictions do not apply to people with admin permissions unless you turn that on, and only a single branch protection rule applies to a branch at a time, so overlapping rules resolve by priority rather than by combining.
For an agent-authored change, the practical question is whether the approval that satisfies branch protection can come from the agent's own account or from a service identity with write access. If it can, the gate is open.
The exclusion lists were built to filter bot noise
Every reviewer ships skip rules, and those rules were written when the main problem was dependency bots opening PRs nobody wanted to read.
CodeRabbit's automatic review controls are the clearest example. The documented GitHub entries for ignore_usernames are dependabot[bot], renovate[bot], and github-actions[bot]. Matching is exact and case sensitive, with no wildcards. Username skipping also takes precedence over every other control, so a PR from a listed author is skipped regardless of labels or any other setting. Skips are silent: ignore_title_keywords drops the PR with no review posted, drafts are skipped by default, and base_branches defaults to the default branch only, so a PR targeting develop gets no automatic review until you add the pattern.
Kodus documents the same class of settings in its review configuration reference. Default ignored paths include yarn.lock, package-lock.json, package.json, .env, and **/*.json. Draft PRs are reviewed by default, which is the opposite of CodeRabbit's default. An empty baseBranches means every base branch is reviewed. Review cadence defaults to pausing after three pushes inside a fifteen minute window, and Kody's skip reasons include a configured file limit and a PR where every changed file matched an ignore pattern.
Two Kodus behaviors are worth flagging for anyone who treats a config file as the source of truth. kodus-config.yml is ignored until kodusConfigFileOverridesWebPreferences is turned on, so committing the file alone does nothing, and unknown keys in that file are dropped without an error or warning. A typo reads as a setting that had no effect.
PR-Agent runs its review when the command is invoked or when the workflow triggers. The GitHub Action in the PR-Agent README fires on pull_request types opened and synchronize, and the CLI or comment path (/review) is how the tool is reached otherwise. There is no automatic pass on a PR nobody points it at. The same README notes that /help_docs is disabled pending a fix for a credential-exposure issue, which is a reminder that the trigger path is also the credential path.
Put together, the failure mode is specific. If your coding agent commits under a service account, an app identity, or a bot name, any exclusion list written to silence dependency bots will silence it too, and the skip is silent. You find out by looking for a review that does not exist.
The same author field can be used to require a human instead
Anthropic's agent approval check reads the same author field in the opposite direction. It requires a set number of human approvals, two by default, on any PR containing commits authored by a configured agent identity, and it hooks into branch protection so the requirement is enforced at merge rather than suggested in a comment.
The contrast is the useful part. The identity of the author is available in both cases. One policy uses it to skip the change, the other uses it to demand a human signature on it. Teams usually end up with the first policy by accident, because the bot exclusions were already there, and the second only when someone writes it deliberately.
What the reviewer is allowed to post decides whether it can hold a merge
A reviewer that comments and a reviewer that blocks are different products, and most tools ship the commenting version.
Kodus posts non-blocking comments by default. Its review policy page states that requesting changes and auto-approving are both opt-in, that request-changes is not available on GitLab, and that blocking behavior should only be enabled when the team agrees on thresholds and has strong CI.
CodeRabbit's request changes workflow is disabled by default. When enabled, approval stays pending until the latest commit has been reviewed, required threads are resolved, and pre-merge checks pass, and CodeRabbit re-verifies that the PR head has not changed immediately before approving. Two escape hatches matter: explicit @coderabbitai approve and @coderabbitai resolve commands override the workflow, and a rate-limited run leaves approval pending because the latest commit never completed a review.
That last point is where review tooling and review policy interact. If your merge requirement is satisfied by a tool's approval, then the tool's rate limit, skip rules, and configuration defaults become merge requirements.
| Reviewer | Default on a PR from an agent identity | Silent skips to audit | Blocks a merge by default |
|---|---|---|---|
| Kodus | Reviews, including drafts | Ignore paths (includes **/*.json), ignored title keywords, base branch narrowing, cadence pause, file limit |
No. Request changes and auto-approve are opt-in, and request changes is unavailable on GitLab |
| CodeRabbit | Reviews, drafts skipped |
ignore_usernames (takes precedence over everything), ignore_title_keywords, base branches limited to the default branch, pause after five reviewed commits |
No. Request changes workflow is off by default and has explicit approve and resolve overrides |
| PR-Agent | Runs only when invoked by comment or workflow trigger | Nothing automatic to skip, because nothing runs unprompted | No. It posts review output |
The defaults differ in ways that change coverage. Kodus reviews drafts and every base branch unless narrowed. CodeRabbit skips drafts and reviews only the default branch unless you add patterns. Neither blocks a merge without an explicit opt-in.
A check you can run on one agent PR this week
Take a merged PR that an agent authored and walk the four gates in order. Find the review request list and confirm a human or team actually appears, which tells you whether CODEOWNERS resolved from the base branch. Look for evidence that a reviewer ran, a review, an inline comment, a status reaction, and treat silence as a skip rather than a clean pass. Open the reviewer's config on the base branch and look for the author name or title pattern that would have matched this PR. Finally, check whether branch protection requires a human approval that the agent's own account cannot provide.
Any of the four can be wrong on its own, and the symptoms are identical from the outside. A change that never reached a reviewer, a reviewer that ran and found nothing, and a reviewer that found something nobody was required to read all show up as a merged PR.
The wider shift this belongs to is that review effort has moved toward deciding whether a change is acceptable, which is what the artifact worth reviewing when agents write the code covers from the process side. Routing is the part that comes before any of it. A team can buy the best reviewer available and still have agent output land unread, because the config that decides who reads what was tuned for a different kind of author. Salesforce's numbers on review time plateauing while code volume rose are the downstream version of this, and GitHub's own eight step checklist for reviewing AI-generated code assumes a human is already in the loop.
Checking the four gates costs about ten minutes on one PR, and it tells you whether the rest of your review investment is connected to anything.
Top comments (0)