Blog

How to integrate AI code review into your CI/CD pipeline

A guide to adding AI code review to GitHub Actions, GitLab CI and Jenkins, with setup steps and advice on choosing where reviews run.

Alex Mercer

To integrate AI code review into a CI/CD pipeline, either install a review app that comments on every pull request with no pipeline changes, or add a job to GitHub Actions, GitLab CI or Jenkins that runs a review tool's command-line interface (CLI) on the diff. An app needs less upkeep; a pipeline job gives you control over when the review runs and whether its findings fail the build.

The challenge is integration. Most teams worry that adding another step will slow down deployments. They wonder if an AI review needs complex configuration. They're concerned about how it works with existing tools like GitHub Actions, GitLab CI, or Jenkins.

TLDR

  • AI code review can be added at different points in your workflow. It can run before code is pushed, when a pull request is opened, or during the CI/CD build. 

  • AI code review tools like cubic need no pipeline setup and review pull requests automatically. API-based tools fit into existing CI/CD systems like GitHub Actions, GitLab CI, or Jenkins.

  • The right choice depends on when you want feedback. Most teams prefer pull-request reviews because they give fast feedback without blocking developers or changing pipelines.

Where AI code review fits in your pipeline

Understanding where to place AI code review in your development workflow matters. Different integration points offer different tradeoffs. 

Most developers already work this way. In the CD Foundation's State of CI/CD Report 2024, 83% of developers said they were involved in DevOps-related activities.

1. Pre-commit hooks

Code review runs on developer machines before code is committed. This catches issues earliest but requires local setup on every developer's machine.

Pros: Immediate feedback before code leaves the developer's environment.

Cons: Requires configuration on each machine, can slow down commits, inconsistent if developers skip hooks.

2. Pull request level

Code review runs automatically when PRs are opened or updated. This is where most teams integrate AI review.

Pros: No local setup needed, consistent reviews on all PRs, doesn't slow down individual commits.

Cons: Feedback comes after code is committed (though before it's merged).

3. CI/CD pipeline step

Code review runs as part of your existing CI/CD pipeline alongside tests and builds.

Pros: Integrates with existing pipeline tools, can block deployments on issues. 

Cons: Feedback comes later in the process and requires pipeline configuration.

4. Continuous codebase scans

Beyond PR reviews and pipeline checks, some teams run deep AI scans across the entire codebase. These scans analyze the repository as a whole to uncover subtle bugs, architectural risks, and security issues that are hard to detect in short-lived reviews.

Because they operate at the codebase level, these scans can explore complex interactions across files, legacy code paths, and long-standing issues that aren’t introduced in a single pull request.

Pros: Finds deep, non-obvious issues across the full repository.

Cons: Not instant feedback, works best alongside PR-level reviews.

Tools like cubic’s codebase scans use large AI agent systems to continuously analyze the repository, complementing faster reviews that run during development.

Integration approaches for different CI/CD systems

How you integrate an  AI tool for code review depends on your CI/CD platform. Here are different types of integration approaches: 

1. GitHub Actions integration

GitHub Actions is the most common CI/CD platform for teams using GitHub. AI code review can be integrated as a workflow step.

Example workflow with the cubic CLI:

name: AI code review
on: pull_request
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - name: Install the cubic CLI
        run: curl -fsSL https://www.cubic.dev/install | bash
      - name: Review the changes against main
        env:
          CUBIC_API_KEY: ${{ secrets.CUBIC_API_KEY }}
        run: |
          git branch main origin/main
          cubic review --base main --json
name: AI code review
on: pull_request
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - name: Install the cubic CLI
        run: curl -fsSL https://www.cubic.dev/install | bash
      - name: Review the changes against main
        env:
          CUBIC_API_KEY: ${{ secrets.CUBIC_API_KEY }}
        run: |
          git branch main origin/main
          cubic review --base main --json
name: AI code review
on: pull_request
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - name: Install the cubic CLI
        run: curl -fsSL https://www.cubic.dev/install | bash
      - name: Review the changes against main
        env:
          CUBIC_API_KEY: ${{ secrets.CUBIC_API_KEY }}
        run: |
          git branch main origin/main
          cubic review --base main --json

This workflow runs on every pull request. The checkout step fetches every branch, and git branch main origin/main gives the job a local main to compare against; change main if your pull requests target another branch. The install script adds the cubic CLI to the job's path.

To set it up, generate a personal API key under Settings → API, CLI & MCP → cubic CLI in cubic and save it as a repository secret named CUBIC_API_KEY. The key has your account's access, and CLI reviews need a seat on an active subscription. cubic review exits with code 1 when it reports findings, so the job fails on findings; append || true to the last line to log them without failing the job. cubic's docs recommend its GitHub pull request review as the final pass, since it uses a different model and review pipeline for a more thorough review.

Coding agents have their own actions. The Claude Code GitHub Action (anthropics/claude-code-action@v1) can review a pull request and post inline comments, the Codex GitHub Action (openai/codex-action@v1) runs the Codex CLI in a job and, in OpenAI's example, posts a review comment on the pull request, and Google's run-gemini-cli action reviews pull requests when they open. Each runs with credentials you store as repository secrets, such as an Anthropic, OpenAI or Gemini API key.

Limitation: This approach requires maintaining workflow files and managing API keys.

GitHub Actions is built into GitHub, which makes it a natural starting point for AI code review integration.

2. GitLab CI integration

GitLab CI uses .gitlab-ci.yml files to define pipeline stages. AI code review can run as a test stage.

Basic GitLab CI configuration:

stages:
  - test
  - build
  - deploy

ai-code-review:
  stage: test
  script:
    - ai-review-cli analyze --token $AI_REVIEW_TOKEN
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
stages:
  - test
  - build
  - deploy

ai-code-review:
  stage: test
  script:
    - ai-review-cli analyze --token $AI_REVIEW_TOKEN
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
stages:
  - test
  - build
  - deploy

ai-code-review:
  stage: test
  script:
    - ai-review-cli analyze --token $AI_REVIEW_TOKEN
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

This runs an AI review during the test stage on merge requests. ai-review-cli stands in for your tool's command, and AI_REVIEW_TOKEN should be a masked CI/CD variable. Claude Code has a GitLab CI/CD integration, in beta and maintained by GitLab, that runs as a job like this one with an ANTHROPIC_API_KEY variable. If your code is on GitLab, note that cubic's pull request review works only on GitHub.

3. Jenkins integration

Jenkins pipelines can include AI code review as a pipeline stage.

Basic Jenkins pipeline:

pipeline {
  agent any
  stages {
    stage('Code Review') {
      steps {
        sh 'ai-review-cli scan --repo $GIT_URL'
      }
    }
    stage('Test') {
      steps {
        sh 'npm test'
      }
    }
  }
}
pipeline {
  agent any
  stages {
    stage('Code Review') {
      steps {
        sh 'ai-review-cli scan --repo $GIT_URL'
      }
    }
    stage('Test') {
      steps {
        sh 'npm test'
      }
    }
  }
}
pipeline {
  agent any
  stages {
    stage('Code Review') {
      steps {
        sh 'ai-review-cli scan --repo $GIT_URL'
      }
    }
    stage('Test') {
      steps {
        sh 'npm test'
      }
    }
  }
}

This adds code review before tests run. As in the GitLab example, ai-review-cli stands in for your tool's command; keep its token in Jenkins credentials rather than in the Jenkinsfile.

Common challenge across all approaches: These integrations require maintaining configuration files, managing secrets, and updating workflows when tools change.

GitHub App integration: The simpler approach

Some AI code review platforms skip CI/CD configuration entirely by integrating as GitHub Apps.

This approach works differently. Instead of adding pipeline steps, you install an app on your GitHub repository. The app automatically reviews pull requests without any workflow files.

How GitHub App integration works:

  1. Install the app on your GitHub organization.

  2. Grant repository access.

  3. The app automatically reviews new pull requests.

  4. Feedback appears as PR comments.

  5. No workflow files or API keys to manage.

cubic uses this approach. After you install its GitHub App, it reviews new pull requests in the repositories you select, then each new push. It skips draft PRs unless you turn on draft reviews, and a PR opened before the install needs the comment @cubic-dev-ai review this PR. No GitHub Actions workflow, secrets or pipeline configuration needed.

The benefit is simple: less maintenance. Updates happen on the platform side, not in your repository. There’s nothing to keep in sync, nothing to upgrade, and nothing extra for your team to manage.

GitHub's own Copilot code review also needs no workflow file: you request Copilot as a reviewer, or turn on automatic reviews with a ruleset. Each review uses AI credits, plus GitHub Actions minutes when it runs on GitHub-hosted runners. For setup steps and how the review apps compare, see our guide to AI pull request review on GitHub.

Step by step: how to add AI code review to your pipeline

Here's how to integrate AI code review regardless of which approach you choose.

Step 1: Choose your integration point

Decide where the review should happen:

  • Pre-commit: For immediate local feedback.

  • Pull request: For automated review without local setup (recommended for most teams).

  • CI/CD pipeline: If you need review results in the existing pipeline reports.

Step 2: Select your integration method

For GitHub repositories:

  • GitHub App integration (simplest, no configuration).

  • GitHub Actions workflow (if you need custom pipeline logic).

For GitLab:

  • GitLab CI integration in .gitlab-ci.yml

For Jenkins or other CI/CD:

  • Add a pipeline stage with a CLI tool or API calls

Step 3: Set up the integration

For GitHub App approach (using cubic as an example):

  1. Go to the tool's installation page.

  2. Click "Install" and select repositories.

  3. Grant necessary permissions.

  4. The tool automatically starts reviewing new PRs.

No configuration files needed. No secrets to add. cubic's developer quickstart walks through the same steps.

For CI/CD pipeline approach:

  1. Get API credentials from the tool.

  2. Add credentials to your CI/CD secrets.

  3. Create or modify pipeline configuration.

  4. Add the review step to your workflow.

  5. Test with a sample pull request.

Step 4: Configure review rules

Most tools let you customize what gets reviewed:

  • Which file types to analyze?

  • Severity levels to report.

  • Specific rules to enforce.

  • Review frequency.

Code review checklists help define what automated reviews should check.

Step 5: Test the integration

Open a test pull request with intentional issues to verify:

  • Reviews run automatically.

  • Feedback appears in the right place.

  • Timing fits your workflow.

  • Results are actionable.

Handling review feedback in your workflow

AI code review produces feedback. Your workflow needs to handle it appropriately.

Blocking vs non-blocking reviews

Blocking reviews prevent merging until issues are fixed. This helps maintain code quality, but it can slow development when tools surface too many alerts, a common false positive problem that causes many AI code reviewers to break down in real workflows.

Non-blocking reviews provide feedback but don't prevent merging. This maintains velocity but requires discipline to address issues.

Most teams start with non-blocking reviews, then make them blocking once they trust the tool's accuracy.

Integrating with existing quality gates

If your pipeline already has quality gates (test coverage thresholds, security scans), AI code review should fit alongside them.

Example quality gate setup:

  • Tests must pass: Blocking.

  • Security scan must pass: Blocking.

  • AI code review: Non-blocking (initially).

  • Code coverage above 80%: Blocking.

This lets you gather confidence in AI review before making it a hard requirement.

Advanced integration features

Some AI code review tools offer features that go beyond basic PR review.

1. Continuous codebase scanning

Standard AI review analyzes pull requests. Advanced tools also scan entire codebases continuously to find existing issues.

cubic's codebase scans work this way. They analyze the full repository on a schedule, catching issues in older code and vulnerabilities from dependency updates. This complements PR reviews by finding problems that weren't introduced in recent changes. Codebase scans are in beta, available by request, and included on Pro and Max for up to 3 repositories.

2. Custom rule integration

Teams often have specific coding standards beyond generic best practices. Integration that supports custom rules lets you enforce team-specific patterns.

AI wiki and MCP support enable tools to access team documentation and enforce project-specific conventions.

3. Integration with project management

Some tools integrate with Jira, Linear, or other project management systems. When an AI review finds issues, it can automatically create tickets assigned to the right developer.

This keeps issue tracking centralized without requiring developers to manually transfer feedback from PR comments to tickets.

Common AI integration challenges and solutions

Teams encounter predictable issues when integrating AI code review.

Challenge: Too many false positives slow reviews

Solution: Start with non-blocking reviews. Adjust sensitivity settings. Train the tool on your codebase patterns. The best AI code review tools learn from your feedback to reduce false positives over time.

Challenge: Review time slows PR throughput

Solution: Don't make merges wait on the slowest review. Deeper reviews take longer: Anthropic says its managed Code Review completes in 20 minutes on average, and a cubic Ultrareview usually takes about 9 minutes. Keep AI review non-blocking until you know how long it takes on your pull requests. GitHub App integrations typically run faster than CI/CD pipeline steps because they don't wait for other pipeline stages.

Challenge: Managing credentials and secrets

Solution: Use GitHub App integration when possible to avoid managing API keys. If using API-based tools, use your CI/CD platform's secret management (GitHub Secrets, GitLab Variables, Jenkins Credentials).

Challenge: Integration breaks after updates

Solution: GitHub App integrations update automatically without breaking your setup. For pipeline-based integrations, pin tool versions and test updates in a staging pipeline first.

Choosing the right integration approach for your team

The best integration method depends on your team's needs and existing setup.

Choose GitHub App integration if:

  • You use GitHub.

  • You want zero configuration maintenance.

  • You prefer automatic updates.

  • Your team values simplicity.

Choose CI/CD pipeline integration if:

  • You need custom pipeline logic.

  • You want to review results in existing reports.

  • You use platforms without app support.

  • You need precise control over when the review runs.

Choose pre-commit hooks if:

  • Your team wants immediate local feedback.

  • You can ensure a consistent local setup.

  • Commit-time delays are acceptable.

Most teams benefit from GitHub App integration for simplicity and speed. It provides fast feedback without configuration overhead.

Getting started with AI code review integration

You don't need to rebuild your workflows to add AI code review to your CI/CD pipeline. Modern tools integrate smoothly into existing processes. The key decisions are where to integrate (pre-commit, PR, or CI/CD) and which method to use (app integration or pipeline configuration). For most teams, pull request level integration through GitHub Apps provides the best balance of feedback speed and setup simplicity.

Start with one repository as a pilot. Test the integration with your team's actual workflow. Adjust settings based on feedback. Then roll out to additional repositories once the process works smoothly.

Automated code review should accelerate your pipeline, not slow it down. With proper integration, it catches issues early while maintaining development velocity.

Ready to integrate AI code review? 

Try cubic with zero configuration required. Install the GitHub app and start getting automated reviews on your next pull request.

FAQ

What false-positive pitfalls should you watch for when rolling out AI review on pull requests?

The common ones are blocking merges on AI findings before you've tuned the tool, reviews of generated files, lockfiles and vendored code, comments that repeat what your linter already enforces, and two AI reviewers commenting on the same pull request. Start non-blocking, exclude generated paths, tell the reviewer to skip what your linter checks, and reply to wrong comments with the reason so a tool that learns from feedback stops repeating them. Then cut the comment categories nobody acts on.

Should AI code review block merges?

Not at first. Run it as comments until developers act on its comments about as often as on human reviewers' comments, then consider blocking on its highest-severity findings. A CLI step that exits with an error on findings, such as cubic review, fails its job, and you can make that job a required status check. Review apps differ: Claude Code Review's check run always completes neutral, so it never blocks, while Bugbot's stays neutral unless you set it to fail on unresolved issues.

Can AI code review run in GitLab CI or Jenkins?

Yes. A review tool with a CLI can run as a GitLab CI job or a Jenkins stage, with its token in a masked CI/CD variable or a Jenkins credential, and Claude Code has a GitLab CI/CD integration maintained by GitLab. Review apps differ by host: cubic's pull request review works only on GitHub, while CodeRabbit and Cursor Bugbot also review GitLab merge requests.

Table of contents