Skip to main content
As coding agents become more prevalent, the bottleneck shifts from writing code to reviewing it. Devin Review is a full-service code review platform within the Devin webapp that turns large, complex GitHub PRs into intuitively organized diffs and precise explanations.
Devin Review is free and available for PRs on regular GitHub repositories (not GitHub Enterprise). Public PRs don’t require a Devin account. Private PRs can be viewed with a Devin account or via the CLI.

​
Features

Smart diff organization

Groups changes logically, putting related edits together instead of alphabetical order.

Copy and move detection

Detects when code has been copied or moved and displays changes cleanly, instead of full deletes and inserts.

Bug catcher

Checks for bugs and labels them by confidence level. Severe bugs require immediate attention.

GitHub compatibility

Leave comments, approve PRs, request changes—all within Devin Review, synced to GitHub.

Codebase-aware chat

Ask questions about the PR and get answers with relevant context from the rest of the codebase. You can also ask Devin directly from any comment, bug, or flag in the diff view.

​
Getting Started

  • Devin webapp — Head to app.devin.ai/review to see your open PRs organized by category (assigned to you, authored by you, review requested). When Devin makes PRs, you’ll see an orange “Review” button in the chat.
  • URL shortcut — For any GitHub PR link, replace github.com with devinreview.com in the URL. For private PRs, sign in to Devin first or use the CLI.
  • CLI — Run npx devin-review {pr-url} from within a local clone. See CLI below for details.

​
Auto-Review

Devin can automatically review PRs without you having to manually trigger it. Configure auto-review in Settings > Review, or from the settings icon on any PR review page.

​
When Does Auto-Review Run?

Auto-review triggers when:
  • A PR is opened (non-draft)
  • New commits are pushed to a PR
  • A draft PR is marked as ready for review
  • An enrolled user is added as a reviewer or assignee
Draft PRs are skipped until marked ready.

​
Self-Enrollment (All Users)

Any user with a connected GitHub account can enroll themselves for auto-reviews—no admin permissions needed.
  1. Go to Settings > Review
  2. Click “Add myself (@yourusername)” to enroll
Once enrolled, Devin will automatically review any PR you create, are added to as a reviewer, or are assigned to, on any repository. You can also self-enroll directly from a PR review page by clicking the settings icon and toggling “Me (@username)”.

​
Admin Configuration

Admins have additional options in Settings > Review:
  • Repositories — Add repositories to auto-review ALL PRs on that repo. Use the dropdown to search and select from connected repositories.
  • Users — View and manage all enrolled users across the organization. Add any GitHub username to the auto-review list.
  • Insert link in PR description — When enabled (default), Devin adds a link to the review in the PR description.
Enterprise accounts: Settings apply across all organizations in the enterprise. Only users in the primary organization with enterprise admin permissions can manage settings. Users in non-primary orgs can only self-enroll.
Auto-review is not available for public repos that aren’t connected to your organization.

​
Bug Catcher

The Bug Catcher automatically analyzes your PR for potential issues and displays findings in the Analysis sidebar. Findings are organized into two categories: Bugs and Flags.

​
Bugs

Bugs are actionable errors that should be fixed in the code. These represent issues the Bug Catcher has high confidence are actual problems. Bugs are displayed with two severity levels:
  • Severe — High-confidence issues that require immediate attention
  • Non-severe — Lower severity issues that should still be reviewed
When you see a bug, you should investigate and fix it in your code.

​
Flags

Flags are informational code annotations that may or may not require action. They come in two classes:
  • Investigate — Flags that warrant further investigation. You should review the flagged code yourself and verify whether there is an actual bug or issue.
  • Informational — The Bug Catcher has either concluded correctness or is explaining how something works. These help you understand the code changes without requiring action.

​
Resolving Findings

You can mark bugs and flags as resolved once you’ve addressed them or determined they don’t require action. Resolved items are dimmed in the sidebar and sorted to the bottom of each section.

​
Review Actions

​
Starting a Review

When creating a new inline comment or replying to an existing thread, you can check the Start a review checkbox to batch your comments into a pending review instead of posting them individually. This mirrors the GitHub review workflow, letting you collect all your feedback before submitting. Once a review is in progress, subsequent comments are automatically added to it and the checkbox is hidden.

​
Resolving Comments

You can resolve review threads to indicate they’ve been addressed. When all threads in a bot-authored review are resolved, Devin automatically minimizes that review on GitHub to keep the PR conversation clean. If a thread is later unresolved, the review is automatically unminimized. In the diff view, you can expand or collapse individual comment threads using the caret toggle to focus on outstanding feedback.

​
Code Owner Indicators

When a code owner has been requested as a reviewer, Devin Review displays a shield icon next to their name in the reviewer sidebar with a “Requested as code owner” tooltip. This makes it easy to identify which pending reviewers have code ownership over the changed files.

​
Auto-Fix

Devin Review can automatically suggest and apply fixes for bugs it detects in your PRs. When Auto-Fix is enabled, Devin will propose code changes directly alongside its bug findings.

​
How to Enable It

There are three ways to enable Auto-Fix:
  1. From the PR review settings popover — On any Devin Review page, click the settings icon (three dots) and toggle Enable Autofix. This toggle appears for Devin-authored PRs.
  2. From the embedded PR review settings — In the embedded Devin Review view inside a Devin session, open the settings popover and toggle Enable Autofix.
  3. From global Customization settings — Go to Settings > Customization > Pull request settings > Autofix settings - bot comments, then either:
    • Set mode to Respond to specific bots only and add devin-ai-integration[bot] to the allowlist, or
    • Set mode to Respond to all bot comments.
When Devin Review finds bugs and Auto-Fix is enabled, it will generate suggested fixes that you can review and apply directly from the diff view.

​
Permissions & Constraints

  • Only organization admins can change this setting.
  • If bot comment mode is set to Respond to all bot comments, the Auto-Fix toggle appears enabled but cannot be changed from PR review settings. Use Customization settings to modify bot comment mode.
  • Devin Review’s No Issues Found summary comments are always ignored. Only comments with actual findings trigger Auto-Fix.
If Devin Review feedback is currently ignored in your repository, you’ll see a prompt in the session timeline to enable it.

​
CLI

The Devin Review CLI lets you run code reviews directly from your terminal. This is especially useful for private repositories or when you want a streamlined local workflow.

​
Installation & Usage

Run the CLI from within a local clone of the repository, no authentication required: 
cd path/to/repo
npx devin-review https://github.com/owner/repo/pull/123
You must run this command from within the repository being reviewed. How it works:
  1. Git-based diff extraction — The CLI uses your local git access to fetch the PR branch and compute the diff. This means you need read access to the repository on your machine.
  2. Isolated worktree checkout — The CLI creates a git worktree in a cached directory to check out the PR branch. This keeps your working directory untouched — no stashing, no branch switching. The worktree is automatically cleaned up after the review completes.
  3. Diff sent to Devin servers — The computed diff and file contents are sent to Devin’s servers for analysis.

​
Privacy & Access Control

The CLI uses a localhost server to authenticate your review session:
  • Local-only access by default — When you run devin-review, it starts a localhost server on your machine that serves a secure token. Only processes on your local machine can access this token, meaning only you can view the review page while logged out.
  • Transfer to your Devin account — If you log in to a Devin account that has access to the GitHub organization, the review session is transferred to your account. This lets you access the review from other devices and share it with teammates.
When you run the CLI, devin-review can execute commands locally on your machine to gather additional context for finding bugs. This enables deeper analysis than diff-only review. The Bug Catcher can execute a limited set of read-only operations scoped to the worktree directory:
  • File reading — Read file contents within the repository
  • Search — Grep for patterns and glob for file names
  • Bash commands — Only read-only commands like ls, cat, pwd, file, head, tail, wc, find, tree, stat, and du

​
Commit & Comment Attribution

  • Bug findings, flags, and automated annotations always appear as the Devin bot.
  • When a user writes a comment or review through Devin Review, it appears under the user’s GitHub identity.
  • When a user asks the chat agent to make a code change, the resulting commit is made as the Devin bot.
  • GitHub Suggested Changes follow standard GitHub behavior: any reviewer (including Devin) can leave a suggested edit in a review comment. When a user clicks “Apply suggestion,” the commit is authored by that user, in the same way as GitHub.
  • Devin will never create commits or comments on behalf of a user without the user explicitly initiating the action.

​
AGENTS.md / Instruction Files

Devin Review respects instruction files in your repository. If any of these files exist, they’ll be used as context when analyzing your PR:
  • REVIEW.md
  • AGENTS.md
  • CLAUDE.md
  • CONTRIBUTING.md
  • .cursorrules
  • .windsurfrules
  • .cursor/rules
  • *.rules
  • *.mdc
These files can contain coding standards, project conventions, or other guidelines that help provide more relevant feedback.

​
Custom Review Rules

You can configure additional files to be ingested as review context from Settings > Review under the Review Rules section. This lets you add custom file glob patterns beyond the defaults listed above. To add a custom rule:
  1. Go to Settings > Review
  2. Under Review Rules, type a file glob pattern (e.g. docs/**/*.md)
  3. Click Add
Custom rules appear in the list alongside the default **/REVIEW.md rule. You can remove any custom rule by clicking the trash icon next to it. This is useful when your project has review-relevant documentation in non-standard locations, such as architecture decision records, style guides, or team-specific conventions stored in custom paths.

​
REVIEW.md

REVIEW.md is a dedicated instruction file for Devin Review. Place it anywhere in your repository to customize how Devin reviews PRs in your project. Devin automatically picks up REVIEW.md files at any directory level (**/REVIEW.md), so you can scope review guidelines to specific subdirectories if needed. Use REVIEW.md to define review-specific guidelines such as:
  • Areas of the codebase that need extra scrutiny
  • Common pitfalls or anti-patterns to watch for
  • Project-specific conventions that reviewers should enforce
  • Files or directories that can be safely ignored during review
  • Security or performance considerations unique to your project
Example REVIEW.md: 
# Review Guidelines

## Critical Areas
- All changes to `src/auth/` must be reviewed for security implications.
- Database migration files should be checked for backward compatibility.

## Conventions
- API endpoints must include input validation and proper error handling.
- All public functions require TypeScript return types — do not use `any`.
- React components should use functional components with hooks, not class components.

## Ignore
- Auto-generated files in `src/generated/` do not need review.
- Lock files (package-lock.json, yarn.lock) can be skipped unless dependencies changed.

## Performance
- Flag any database queries inside loops.
- Watch for N+1 query patterns in API resolvers.