How to add AI code review to CI/CD without blocking merges

AI code review is easy to add to a pipeline and surprisingly easy to make annoying. A job starts on every push, waits for a model, posts six comments and turns a slow provider into the reason nobody can merge.

The fix is to decide what the review is allowed to do before wiring it into CI/CD. Treat AI feedback as a bounded review step. Keep tests and deterministic checks responsible for the rules they can answer exactly.

Decide what the pipeline should do

There are three useful levels of enforcement.

An advisory review posts findings and lets the normal workflow continue. This is the right starting point for most teams. It gives you real data about noise, latency and useful comments before anyone depends on the result.

A required review confirms that the review job completed. This can be useful when the organization needs a review record, but a green status must not imply that the model found every bug. A completed review is not an approval.

A blocking finding stops the merge when a review identifies a documented high-severity risk. Use this sparingly. The finding still needs evidence, a stable location and a way for a human to override it when the context is legitimate.

Do not make a provider timeout block production work by accident. Decide what happens when the service is unavailable, the review is cancelled or the model returns no usable result. A clear failure status is better than a permanent queue of retries.

Use a small, explicit pipeline

A provider-neutral review flow can look like this:

change event arrives
  cancel older review for the same change
  collect the commit and change metadata
  fetch the diff and selected files as untrusted data
  retrieve bounded repository context
  ask the model for candidate findings
  verify each candidate against the evidence
  discard stale or unsupported findings
  publish a small review with the commit it examined

The order matters. If the pipeline posts the model's first response, the rest of the system is decoration. Candidate generation is allowed to be broad. Publication should be strict.

Keep the review client small and trusted. If the job downloads arbitrary code from the change and then runs that code in the same environment as the model key, the pipeline has mixed untrusted input with a valuable credential.

Pick review triggers that match how people work

Most teams need a review when a change is ready for feedback and when a new commit replaces the one that was reviewed. They do not need a new full review for every metadata edit or every automated branch update.

Useful triggers include:

• a change opens or becomes ready for review
• a new commit arrives on an active change
• an author or reviewer asks for a fresh review
• a human starts a review after deterministic checks finish

Use path filters when generated files, vendored code or documentation do not need the same review. Keep an escape hatch for changes that cross a path boundary. A filter that hides a risky file is worse than no filter because it creates false confidence.

If several commits arrive close together, cancel the older run. Reviewing commit A after commit B has already arrived produces comments about code that no longer exists.

Keep untrusted code away from secrets

The safest general rule is simple: fetch the change as data, not as an executable workspace, when the job holds a model key or a write token.

A pull request can change package scripts, build steps, test commands, workflow files and action references. Running those changes in a privileged job gives contributor-controlled code a chance to read credentials or use the token.

Safer designs include:

• a trusted service that fetches the diff and repository context
• a CI job that runs code from the trusted base revision
• a read-only job that creates an artifact for a separate publishing step
• a review worker with a narrowly scoped provider key and repository token

Use the smallest permissions the workflow needs. A reviewer that reads repository content and posts feedback may need read access plus permission to publish review comments. It usually does not need write access to source, workflow files or repository settings.

For platform-specific trigger behavior, see the AI code review with GitHub Actions guide. The provider changes, but the trust boundary does not.

Give the model enough context, but set a limit

A diff is the right starting point. It is rarely the whole review.

Depending on the change, the reviewer may need:

• the complete changed function or class
• definitions and direct callers
• types, schemas and configuration defaults
• related tests and test utilities
• repository review rules
• the pull request description and linked requirement
• documentation for a library whose behavior matters

The diff-only code review guide shows why a changed line can look correct while a caller or invariant breaks elsewhere.

Context retrieval needs limits. Cap files, bytes, tool calls, elapsed time and model tokens. Prefer a small set of files with a reason for each one over a repository dump nobody can inspect. Record the evidence used for every finding so a reviewer can tell whether the model actually saw the relevant contract.

Do not let a pull request increase its own trusted context. Repository rules, security policies and review configuration should come from the trusted base or the review service, not from arbitrary instructions added in the change.

Keep deterministic checks separate

AI review is a poor replacement for a compiler. Run the tools that can answer exact questions in their own jobs:

• compilation and type checking
• unit and integration tests
• formatting and linting
• static analysis
• dependency and secret scanning
• generated-file checks

The AI reviewer can read their results when that helps explain a risk. It should not invent a compiler verdict or repeat a failed test as a paragraph of speculation.

This separation also makes failures easier to understand. A type-check job failed. A review provider timed out. A security scanner found a secret. Each message points to a different owner and a different fix.

Publish fewer comments than you generate

The model can produce candidates. The pipeline should publish findings only after a second check.

Before a finding becomes a comment, verify that:

• the reviewed commit is still current
• the line exists and is eligible for an inline comment
• the finding describes a concrete failure
• the evidence supports the claimed behavior
• the severity matches the likely impact
• the comment is not a duplicate of an earlier finding
• the number of comments stays within a configured limit

Do not ask the model to produce a fixed number of issues. That instruction turns silence into a failure and encourages guesses. A good review can finish with no comments.

The AI code review false positives guide covers the same problem from the reviewer's point of view. The pipeline version of the rule is shorter: candidates are cheap, published comments are expensive.

Handle retries, concurrency and cost

Review jobs can overlap when an author pushes several fixes. Give each change a concurrency key and cancel older work. If cancellation is not available, check the current revision before doing model work and again before publishing.

Set limits for:

• total review time
• model calls per change
• retrieved files and bytes
• output comments
• provider retries
• daily or monthly spending

Retry transient network failures with a small cap. Do not retry an invalid request or an unsupported repository forever. Do not let a provider outage create a backlog of reviews that arrive after the change is merged.

Record enough data to explain the bill and the delay. At minimum, keep the change identifier, reviewed revision, start and finish times, model calls, cancellation reason and publication result. Avoid logging source code or provider payloads unless your data policy allows it.

Roll out the review in stages

Start with advisory comments on a repository where the team can inspect the output. Run the review on real changes, not a hand-picked demo branch.

During the first stage, track:

• accepted, dismissed and duplicate findings
• time from change to first useful feedback
• cancelled and stale reviews
• model and CI cost
• categories of bugs the review missed
• time engineers spent investigating comments

When the team trusts the signal, add a required completion status if that record matters. Add blocking behavior only for narrow, well-tested rules. Keep a manual override and document who owns it.

If the comments stay noisy, fix context, rules and verification before increasing the model or the number of review passes. More calls do not repair an unclear review contract.

A practical default

For most teams, the default should be:

1. Run AI review when a change is ready and when its revision changes.
2. Fetch repository data through a trusted path.
3. Keep secrets out of jobs that execute untrusted code.
4. Use bounded context retrieval rather than the entire repository.
5. Publish advisory comments after candidate verification.
6. Let tests, linters and scanners own deterministic failures.
7. Cancel stale work and cap retries, tokens and spending.

That setup is less dramatic than making an AI job the final gate. It is also much easier to measure and improve.

Frequently asked questions

Should AI code review block merges?

Usually not at first. Start with advisory feedback, measure useful and rejected findings, then add narrow blocking rules only when the team understands their failure modes. Tests and deterministic checks should keep ownership of exact failures.

Should the review run on every commit?

Run it when a change is ready for feedback and after a new revision replaces the reviewed one. Avoid duplicate full reviews for metadata changes or automated updates that do not alter the reviewable code.

Can a CI job safely review code from an untrusted branch?

It can inspect the branch's diff and files as data. It should not execute that branch in the same privileged environment that holds model keys or write tokens. Use a trusted worker or a carefully separated workflow.

How much repository context should an AI reviewer receive?

Enough to check the contracts affected by the change, including relevant callers, types, tests, rules and documentation. Set caps on files, bytes, calls and tokens so the review stays predictable.

What should happen when the model fails?

Mark the review as incomplete, explain the failure and apply the policy you chose before implementation. Do not silently report success, and do not block every merge forever because a provider is unavailable.