Claude for Code Review: Setting Up Automated PR Feedback Loops
Adding an AI reviewer to pull requests is easy. Making it useful takes more care. A badly configured reviewer leaves dozens of minor comments on every pull request, and developers soon start ignoring it.
Step 1: Choose how it runs
There are two common approaches:
- The Claude Code GitHub Action. Anthropic's official action runs Claude Code inside your workflows. It can respond when someone mentions
@claudeon a pull request or run automatically when one is opened. Running/install-github-appin Claude Code helps you set up the app and secrets. - A custom CI job. Run Claude Code in print mode against the diff and post the results with the GitHub CLI. This takes more work but gives you more control.
Start with the official action unless you have specific requirements it doesn't meet.
Step 2: Define what a useful review covers
Put review guidelines in CLAUDE.md or in the review prompt:
- Focus on correctness, security, data handling and missing tests.
- Ignore formatting and naming, which linters already check.
- Only raise issues that come with a concrete explanation of how they would fail.
- Prefer one clear comment over several speculative ones.
Requiring an explanation of how the code would fail is the most effective way to cut down on unhelpful comments.
Step 3: Limit what it can do
The reviewer should comment and nothing more. It shouldn't merge, push to protected branches or approve changes. Give the workflow token only the permissions needed to read code and post comments.
Step 4: Let developers respond
Allow developers to reply to comments, for example with @claude why? or @claude fix this, so a review can become a short discussion. Any fix should arrive as a suggested change or a separate commit for a person to review.
Step 5: Measure whether it helps
During the first month, track:
- Comments that led to a code change.
- Comments dismissed as wrong or irrelevant.
- Bugs found before merging that would otherwise have been released.
A high dismissal rate means the guidelines need tightening. If it finds nothing, it probably needs more information about the architecture.
Things to watch
- Very large diffs get shallow reviews. Encourage smaller pull requests, or review groups of files separately.
- Pull requests from forks shouldn't have access to secrets. Keep GitHub's default protections.
- AI review adds to human review. Approval should still come from someone responsible for the code.
After a month, the numbers will show whether to keep the reviewer, adjust it or turn it off.