Set Up AI Code Review in Your GitHub CI/CD Pipeline

GitHub AI code review puts a model on every pull request before a human looks at it. The bot reads your diff, flags bugs and security issues, and leaves inline comments while your tests run. By the time a teammate opens the PR, the bot has marked the easy problems.

This guide sets up AI code review two ways. The first uses a managed GitHub App and takes about ten minutes. The second is a custom GitHub Action you control end to end. Both run on every pull request, the ai code review github setup most teams want.

New to the topic? Start with our guide to AI code review and our comparison of the best AI code review tools. This post assumes you picked a tool.

What AI code review in CI/CD means

A CI/CD pipeline runs checks every time you push code. Tests, linters, static code analysis, and builds all run on their own as part of continuous integration. AI code review adds one more check. When a pull request opens, the pipeline sends the diff to a language model. The model analyzes source code the way a senior engineer would, then posts review comments on the PR.

This is code review automation in the truest sense. The review fires on a GitHub event and reports in under a minute for most changes. These ai powered code reviews give developers real time feedback inside the normal code review process, and they improve code quality before a teammate opens the PR.

You have two shapes to choose from. A managed tool installs as a GitHub App and runs on its own servers. A custom setup runs inside GitHub Actions, in a workflow file you own. The App starts faster. The Action gives you full control over the prompt, the model, and the data that leaves your repo.

Prerequisites

You need admin rights on the repo, since installing an App and adding secrets both require admin access. You need a pull request workflow, because AI review reacts to pull requests. For the custom path, you also need an API key from a model provider such as OpenAI or Anthropic.

Branch protection helps too. It lets you require checks to pass before a merge. That turns the AI review into a real gate rather than a comment nobody reads.

Option 1: Use a managed GitHub App

The fastest way to run GitHub AI code review is a managed tool. CodeRabbit, Greptile, and Qodo all install as GitHub Apps. Some teams pick an open source reviewer they self host. Others want automated code review tools that enforce a shared coding standard out of the box.

Install the GitHub App

Open the tool's GitHub Marketplace listing and click install. Grant access to every repo or pick specific ones. For a first run, pick one repo. GitHub asks you to approve permissions: an AI reviewer needs read access to code and pull requests, plus write access to pull request comments. Approve the scopes, and the App starts listening.

Configure the review behavior

Most managed tools read a config file from the root of your repo. A tool might use a .coderabbit.yaml file, for example.

reviews:
  request_changes_workflow: false
  high_level_summary: true
  poem: false
  path_filters:
    - "!**/*.lock"
    - "!dist/**"
  auto_review:
    enabled: true
    drafts: false
chat:
  auto_reply: true

This config turns on automatic review, skips draft pull requests, and ignores lock files and build output. Tune the path filters early. Without them, the bot reviews generated files and wastes its budget on noise. Then open a test pull request to confirm it works.

Option 2: Build a custom GitHub Action

Want control over the model, the prompt, and what data leaves your network? Build your own AI code review action. It runs inside GitHub Actions, next to your tests.

Wire up the API key as a secret

Never paste an API key into a workflow file. Store it as an encrypted repo secret. In your repo, open Settings, then Secrets and variables, then Actions. Add a secret named OPENAI_API_KEY. The workflow reads it at runtime, and it never shows up in logs.

Write the workflow file

Create .github/workflows/ai-review.yml. It triggers on pull requests, checks out the code, and runs a review script. The permissions block lets the job post comments back on the PR.

name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Run AI review
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
          REPO: ${{ github.repository }}
        run: python .github/scripts/ai_review.py

The fetch-depth: 0 line pulls full history, so you get an accurate diff against the base branch. Actions provides the GITHUB_TOKEN on its own.

Write the review script

The script gets the diff, sends it to the model with a clear instruction, and posts the result as a PR comment.

import os, subprocess, requests

diff = subprocess.run(
    ["git", "diff", "origin/main...HEAD"],
    capture_output=True, text=True
).stdout[:60000]

prompt = (
    "You are a senior code reviewer. Review this diff. "
    "List concrete bugs, security issues, and risky changes. "
    "Be specific and cite the file and line. Skip style nits.\n\n"
    f"{diff}"
)

resp = requests.post(
    "https://api.openai.com/v1/chat/completions",
    headers={"Authorization": f"Bearer {os.environ['OPENAI_API_KEY']}"},
    json={
        "model": "gpt-4o",
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.2,
    },
)
review = resp.json()["choices"][0]["message"]["content"]

repo = os.environ["REPO"]
pr = os.environ["PR_NUMBER"]
requests.post(
    f"https://api.github.com/repos/{repo}/issues/{pr}/comments",
    headers={"Authorization": f"Bearer {os.environ['GITHUB_TOKEN']}"},
    json={"body": f"## AI Code Review\n\n{review}"},
)

We kept this small, so you can read it in one pass. In production you would cap the diff size, retry on rate limits, and split very large pull requests. Commit both files, open a pull request, and watch the Actions tab.

Tune when reviews run

Running the AI on every push gets expensive and noisy. Skip draft pull requests with drafts: false, or gate a custom job with a draft condition. Filter by path so docs and lock files do not trigger a review. Cap the diff size, since a huge refactor blows past the model context window and costs a lot.

Best practices for CI/CD

Make the AI a non-blocking check at first. Let it comment but not fail the build. Once the false positive rate drops, promote it to a required check in branch protection.

Tune the prompt to your stack. A generic reviewer flags generic issues, so tell it your language, your framework, and the bugs you care about.

Keep humans in the loop. AI review clears the first pass and tightens the feedback loops around your manual code reviews. It is strong on obvious bugs, missing error handling, and known security patterns, and it pairs well with your security checks. It is weak on business logic, architecture, and intent, so a human still owns the merge. We dig into that split in our post on what AI catches and what it misses.

Common pitfalls

Alert fatigue is the first. A loud bot that comments on every line trains your team to ignore it, so use path filters and a prompt that skips style nits. The second is leaking code to a third party: read your provider's data retention terms, and for sensitive repos pick a self-hosted model or a no-training guarantee. The third is treating the AI as a gate too early, so run it in advisory mode first. The fourth is cost, since every review is an API call. Set a budget and watch your provider dashboard for the first month.

Measure whether it works

Track three numbers. Time to first review should drop to under two minutes once the AI lands its comment. Acted-on comments tell you how many AI issues turn into commits; near zero means the bot is noisy. Escaped bugs move slowly, but fewer bugs reaching production from reviewed PRs is the signal that matters most.

Bringing it together

GitHub AI code review is not a giant project. The managed path is a GitHub App, a config file, and a test pull request. The custom path is one workflow file and a short script. Either way, you add automated code analysis to your ci cd pipelines and free your team for the judgment calls only people can make. Start with one repo, run in advisory mode, then expand once you trust it. For more, browse the Levelop blog and our full AI code review guide.