Devin Code Review: Keep Review and Merge Separate

How should Devin code review fit into a merge gate?

Use Devin Review to understand the pull request and produce candidate findings. Let it suggest or apply fixes only under explicit repository permissions. After every branch mutation, run tests and an independent review gate on the new head. Merge only when the required checks and reviewed SHA match that exact commit.

That answer is narrower than “turn on AI review.” As of August 13, 2026, the official Devin Review documentationdescribes organized diffs, bug and security analysis, codebase-aware chat, GitHub review actions, Auto-Fix, auto-review, and merge controls. Those features cover several jobs that a conventional review workflow assigns to different people and systems.

The overlap is useful, but it changes the trust question. A reviewer that can also write code, set commit statuses, and initiate a merge has more authority than a comment-only bot. The workflow should not infer independence from the fact that the same product presents those actions in separate panels.

The general AI code review workflow for GitHubbinds intent, execution, evidence, verdict, and merge state. This guide applies that contract to Devin's specific connection modes and permissions.

What Devin Review does on a pull request

Devin Review is broader than an inline-comment generator. Its official docs list smart diff organization, copy and move detection, Bug Catcher findings, security scanning, codebase-aware chat, comments and reviews, code edits, and pull-request workflow actions. It supports GitHub and GitLab, with some capability differences between providers and connection types.

Connection mode changes what is possible. Devin says public pull requests can be viewed without a Devin account, and its local CLI can compute the PR diff in an isolated worktree. The same documentation says the CLI sends the diff and file contents to Devin servers for analysis and may run a bounded set of read-only commands inside that worktree. Review that data boundary before using the CLI with private or regulated code.

For GitHub write features, Devin distinguishes the GitHub App from a PAT-based connection. PAT connections are read-only in Devin Review. Comments, submitted reviews, branch edits, and workflow actions require the App. That is a meaningful security boundary, not an installation detail.

The four-authority contract for Devin code review

The safest way to configure Devin Review is to inventory four independent authorities: read, report, mutate, and merge. This framework is the information most Devin setup pages omit. Product documentation explains each feature, while the authority contract explains which evidence becomes invalid when one feature changes repository state.

This is not an argument against Auto-Fix or an integrated merge button. It is an argument for a visible state transition. The speed benefit survives when the workflow records the new commit and reruns independent checks. The audit trail disappears when “fixed” in the interface is treated as “validated” in the repository.

1. Choose the Devin connection mode by required authority

Start with the least authority that completes the job. A maintainer evaluating the review experience on a public PR can use the URL shortcut. A developer with local access to a private repository can use the CLI after accepting its documented data path. A team that needs GitHub comments, checks, branch edits, or merge actions will need the GitHub App connection.

The Devin GitHub integration guidelists organization-level read/write access to checks, commit statuses, contents, pull requests, and workflows, among other scopes. It also recommends branch protection before Devin can merge changes. Review these permissions as a single capability set because Devin uses the integration's organization-level rights, not the narrower rights of the individual starting a session.

1. List the repositories Devin needs; avoid an all-repository grant by default.
2. Decide whether the job is read, report, mutate, or merge.
3. Use a read-only path when comments and commits are not required.
4. Install the App only after repository rules can contain its write authority.
5. Record who may change the integration and Auto-Fix settings.

Done means the team can explain why every granted permission is needed and which repository rule limits it. “Devin needs access” is not a permission model.

2. Put stable review rules in the repository

Devin Review reads several instruction-file formats, including scopedREVIEW.md and AGENTS.md files. Use them for durable facts: authorization boundaries, compatibility promises, required tests, generated-file policy, and the evidence threshold for a finding. Keep one pull request's intent and non-goals in that PR description.

A dedicated REVIEW.md can focus the reviewer without overloading author instructions. Scope a file near the subsystem it governs. The root file should hold repository-wide rules; a file under src/auth/ can add authentication threats and test expectations for that path.

# Review rules

## Finding admission
- Cite the changed file and exact code path.
- Explain the user-visible or operational consequence.
- Treat a missing test as blocking only when a changed behavior is unprotected.

## Authentication changes
- Check tenant isolation and privilege escalation paths.
- Require focused allow and deny tests for each changed policy branch.

## Output
- Separate defects from questions and optional improvements.
- Do not describe a clean review as approval to merge.

The evidence-bound PR review prompt libraryprovides specialized correctness, security, testing, migration, and compatibility angles. Reuse the admission rules, then adapt only the subsystem facts that are true for your repository.

3. Run Devin code review on a named head commit

Record the pull request head SHA before review starts. Devin offers several trigger paths: the review webapp, a /devin review PR comment, the URL shortcut, the CLI, and auto-review. The trigger is less important than knowing which commit the completed result describes.

Devin documents three auto-review modes. Auto review runs when a non-draft PR opens, when a new commit is pushed, and when a draft becomes ready. On PR creation omits later pushes. Manual waits for an explicit request. If repository and personal enrollment both apply, verify the effective behavior instead of assuming the repository setting is the only trigger.

review_request:
  provider: "devin-review"
  repository: "owner/repo"
  pull_request: 123
  head_sha: "<40-character current head>"
  trigger: "manual | on_pr_creation | auto"
  requested_at: "<timestamp>"

If the head changes while review is running, keep the completed comments as historical evidence and request another result. Do not guess that a review which started on one commit silently expanded to cover later code.

4. Convert Devin findings into tracked obligations

Devin separates Bugs, Flags, and Security findings. Its documentation describes Bugs as actionable errors, Flags as investigate or informational annotations, and Security findings as vulnerability or hardening reports. That taxonomy is useful, but repository policy still decides what blocks.

Admit a finding only when it contains a checked claim, a code reference, a causal path, a concrete consequence, and the evidence needed to close it. A severity label or confident explanation cannot replace those fields. Thesignal-first comment contractshows how to preserve the finding when line anchors move and how to distinguish fixed, rejected-with-evidence, intentional, and human-judgment dispositions.

Configure GitHub publication deliberately. Devin can post a status check plus selected categories of bugs, security findings, and flags. Posting every informational annotation creates noise. Posting only a green check hides the reasoning. Choose the smallest public surface that still lets a maintainer audit the gate.

5. Invalidate old evidence after Auto-Fix or chat edits

Devin Review can propose and apply bug fixes, and chat can produce commits on the PR branch. The moment that commit lands, the old review result becomes evidence about the previous head. The finding remains relevant as the reason for the change; the pass or resolution state must be recomputed.

GitHub's protected-branch documentationmakes the same distinction for human approvals. Repositories can dismiss stale approvals after new commits or require approval of the latest reviewable push. That policy exists because a new diff is new evidence, regardless of who produced it.

1. Capture the head SHA before the fix and the new head after it lands.
2. Inspect the fix diff instead of relying on the resolved-thread label.
3. Run the focused regression that demonstrates the causal path is closed.
4. Run required CI on the new head.
5. Rerun review or a bounded delta review with explicit carry-forward rules.
6. Close the obligation only with evidence from the new code state.

This is the most important boundary in a Devin workflow because the product can move from finding to branch mutation without leaving the review surface. Fast repair is valuable. Implicit re-approval is not.

6. Publish an independent repository-owned gate

Keep the final verdict in CI under versioned repository policy. Required tests and a review gate should run on the pull-request event, bind their output to the exact head, and distinguish code findings from reviewer failure. Branch protection or a ruleset should require the intended check from the intended source.

ReviewGate is one open-source implementation of that boundary. It runs inside the user's GitHub Actions environment with a bring-your-own OpenRouter key, publishes a visible 0-5 score in one canonical summary, and emits structured JSON for humans or repair agents. It does not apply fixes or make the human merge decision.

name: ReviewGate

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

jobs:
  review:
    if: github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    permissions:
      actions: read
      attestations: read
      contents: read
      pull-requests: write
      issues: write
      checks: write
      statuses: read
    steps:
      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          fetch-depth: 0
          persist-credentials: false
      - uses: LVTD-LLC/reviewgate@v0
        with:
          openrouter_api_key: ${{ secrets.OPENROUTER_API_KEY }}
          min_severity: P4

Copy the maintained workflow from theGitHub Actions installation guide and keep the fork-safety guard. Then use theReviewGate configuration reference for review angles and severity. The independent gate can run after Devin-authored commits, Devin Review findings, or Auto-Fix without needing to know which interface produced the code.

A review error must fail closed. If the reviewer times out or produces an invalid artifact, report an inconclusive review instead of converting unavailable evidence into a clean code score. Measure the gate's recall, false-blocker rate, repeatability, latency, and cost with theAI code review benchmark scorecardbefore requiring it across many repositories.

7. Verify the pull-request head before merge

Read the live PR head, each required check's commit, and the structured review artifact's reviewed SHA as separate fields. They must converge. A resolved Devin thread, a green status for an older commit, or an earlier human approval does not establish the state of the current head.

1. Confirm the live pull-request head SHA.
2. Confirm required tests and review checks completed for that SHA.
3. Confirm the review result is passed, not unavailable or merely completed.
4. Confirm no admitted blocker remains open or needs human judgment.
5. Confirm required human reviews and conversation-resolution rules are satisfied.
6. Let the authorized human decide whether to merge that head.

Devin's own GitHub integration guide recommends branch protection before allowing merge actions. GitHub can require status checks, reviews, conversation resolution, deployments, or a merge queue. Use the combination that matches the repository's risk, then preserve one invariant: the code that merges is the code the evidence describes.

The ReviewGate agent workflow contract exposes status, score, reviewed SHA, and finding disposition without asking another agent to scrape prose from the PR conversation.

A worked Devin authority transition

Consider a pull request that changes an authorization predicate for project membership. This is an illustrative workflow, not a claim about a real Devin run.

1. Devin authors head A. The PR description states that owners and invited members must retain access while unrelated users remain denied.
2. Devin Review reads head A and reports a bug: the new predicate rejects invited members. A maintainer admits it because the comment cites the changed branch, the membership contract, and the missing allow-path test.
3. Auto-Fix adds the membership branch and a regression test, creating headB. The original finding remains attached to head A; its resolved label is not a verdict on head B.
4. Required CI and ReviewGate run on head B. The focused test covers owners, invited members, and unrelated users. The structured review result names headB and has no open blockers.
5. A maintainer verifies the contract, required checks, and current head, then merges. The history shows who read, reported, mutated, validated, and decided.

The useful property is not that every stage used a different brand. The useful property is that each authority emitted evidence the next boundary could verify. The workflow remains auditable even when Devin authored, reviewed, and fixed the same pull request.

Common Devin code review failure modes

Granting write authority before defining branch policy

The GitHub App can contribute code, publish statuses, and participate in pull requests. Install it on selected repositories, require the right checks, and decide who may enable Auto-Fix or auto-merge before treating it as a routine reviewer.

Making every Devin flag a blocker

Investigate and informational flags are not confirmed defects. Require a causal path and consequence before they enter the gate. Otherwise comment volume becomes a proxy for risk and maintainers learn to ignore the reviewer.

Reusing a clean result after Auto-Fix

A branch mutation creates a new head. Preserve the finding, inspect the fix, run the regression, and produce a new exact-head result. Thread resolution is workflow state, not proof of correctness.

Confusing a posted status with repository policy

A check becomes a gate only when branch protection or a ruleset requires it and the workflow defines pass, failure, staleness, and reviewer-error behavior. “The review ran” is not a merge criterion.

Ignoring the local CLI data boundary

Devin documents that its CLI computes the diff locally but sends the diff and file contents to Devin servers. That may be acceptable for your repository. Make the decision explicitly instead of assuming local invocation means local-only review.

Questions about Devin code review

Add an exact-head gate after Devin Review

ReviewGate is free and open source. It runs in GitHub Actions, uses your OpenRouter key, publishes one score-centered summary, and emits structured current-head findings. Devin Review can remain the pull-request review and repair workspace; ReviewGate supplies the independent repository-verdict boundary.