# How AI code review works, step by step

> What happens between opening a pull request and the first AI review comment, from the webhook and the code index to verification, posting and learning.

Most explanations of AI code review stop at "a language model reads the diff and leaves comments". That is the visible part. A reviewer a team can trust does a good deal of work before the model sees anything, and more after it has an answer and before anything is posted.

This guide follows one pull request through MergeHarbor's review, stage by stage, and explains why each stage exists. If you want the broader picture first (what AI review is, how it compares with linters and static analysis, and how to evaluate a tool), read [What is AI code review?](https://mergeharbor.com/guides/what-is-ai-code-review). This guide is about the mechanism.

## 1. Before any pull request: the index

Review quality depends on context, and context has to be prepared ahead of time. When you connect a repository, MergeHarbor builds three indexes of it:

- **A code graph.** Files, functions, classes and the calls and references between them. In Go, Java, JavaScript, TypeScript and Python, calls are resolved and marked exact or likely; in other languages symbols are matched by name. The [supported languages](https://mergeharbor.com/docs/languages) page lists which languages get full parsing, structural parsing or plain text.
- **A text index** for exact search, so the reviewer can find every use of a setting name or an error string.
- **A semantic index**, built from embeddings of code chunks and plain-language summaries of each file, so the reviewer can find code by meaning ("where else do we parse this date format?").

After the first pass, only changed files are processed again. Large binaries and generated or vendored code are skipped. Reviews do not wait for indexing: a repository is reviewed from the moment it is enabled, and until its index is built the reviewer reads the files the pull request needs directly. The summary notes when less codebase context was available.

## 2. The trigger: a webhook from the code host

A review starts when your code host sends a webhook: a pull request (or merge request) was opened, reopened, marked ready, or received a new push. MergeHarbor registers these webhooks for you when you enable a repository on [GitHub](https://mergeharbor.com/ai-code-review/github), [GitLab](https://mergeharbor.com/ai-code-review/gitlab), [Bitbucket](https://mergeharbor.com/ai-code-review/bitbucket), [Azure DevOps](https://mergeharbor.com/ai-code-review/azure-devops), Gitea or Perforce.

What counts as a trigger is configurable. In `.mergeharbor.yml`, `trigger` can be `never`, `opened`, `pushes` or `all`, and `filters` limit reviews to pull requests that match conditions on author, labels, branches, paths, title or size. By default, pull requests opened by Dependabot, Renovate and similar bots are skipped. A comment such as `@mergeharbor review` starts a review on demand.

Pushes are coalesced: a burst of commits produces one review after the branch settles, not one per commit.

## 3. The diff, minus what should not be there

A worker updates its mirror of the repository and computes the diff. Two things are removed before a model sees it:

- **Files that are not worth reviewing.** Lockfiles and vendored, generated and binary files are left out, along with anything matching your `ignore_paths`. Whitespace-only edits are dropped from the prompt.
- **Secrets.** A secret scanner removes private keys, cloud access keys, code-host tokens, passwords in connection URLs and high-entropy values assigned to names such as `password` or `api_key`. Redaction is always on, and it applies to everything the model later reads through its tools, not just the diff. The details are in [How MergeHarbor uses AI and your code](https://mergeharbor.com/docs/ai-data).

Pull requests that change only documentation or configuration skip the model and get an automatic summary.

## 4. Deterministic checks, before any model

Some defects need no judgment. A committed secret, a SQL query built by concatenating values, a shell command built from input, `eval`, a disabled TLS check or a leftover conflict marker is wrong regardless of context. MergeHarbor runs built-in rules for these on every pull request before the model is involved. They use no credits, and serious problems they find are posted within seconds, while the rest of the review is still running.

## 5. Risk ranking

Before the model reads the diff, each part of it gets a risk score from what it touches: removed guards, queries, concurrency, error handling, boundaries, money and authentication. The reviewer starts with the riskiest changes and only skims tests, docs and formatting. This costs nothing extra and is on by default.

The same signals feed the choice of how much review the pull request gets. With the Auto [review tier](https://mergeharbor.com/docs/review-tiers), MergeHarbor adds up points for size, risky areas (authentication, payments, secrets, migrations, infrastructure), labels, the target branch and recent serious findings in the same files, and picks Standard, Deep or Max. No model call is needed to decide, and the summary says why it chose the tier it did.

## 6. Context retrieval

A diff shows what changed, not what depends on it. Two stages close that gap, and both are always on for Deep and Max reviews (and can be turned on for Standard):

- **Trace what depends on the change.** From the functions, types and settings the pull request changes, MergeHarbor follows the code graph to their callers, implementations and config readers, ranks them, and states the blast radius in the summary: how many call sites, files and modules depend on the change, and whether tests cover them.
- **Bring in related code.** Exact text search, semantic search and graph neighbours each suggest related code. The results are merged, de-duplicated and trimmed to a token budget, so the reviewer sees the relevant parts without paying for whole files.

Your team's context comes in here too: [rules](https://mergeharbor.com/docs/rules) that match the changed files, context files and knowledge-base pages you configured, and, if you connect them, linked tickets from Jira, Linear or Asana with their acceptance criteria. The guide on [diff-only versus codebase-aware review](https://mergeharbor.com/guides/diff-only-vs-codebase-aware-review) shows three bugs that are invisible without this step.

## 7. Investigation with read-only tools

Then the model reviews. It is not a single prompt in, comments out. The reviewer reads the change and decides what else it needs, using read-only tools: read a file, search the code, find callers, read commit history, look up a linked ticket. New code in the pull request is visible to the tools alongside the indexed codebase.

The tools are bounded. A file read returns at most 800 lines, a tool result is limited to about 12,000 characters, and the agent can only read the repository and commit under review, using a short-lived signed token. Every tool result passes through the secret scanner before the model sees it.

Deeper tiers give the reviewer more steps, a stronger model and a larger context budget. Most ordinary changes are reviewed in one focused model pass; high-risk or cross-cutting changes get a full investigation within a per-review cost cap. Very large pull requests are reviewed in parts at the same time and combined into one summary.

## 8. Verification: try to disprove every finding

A model that has decided something is a bug tends to keep believing it. So the draft findings go to a second pass whose job is the opposite: show that each one is wrong, citing the code it checked. A finding the verifier disproves is never posted. Uncertain ones are posted with lower confidence.

This is the single biggest lever on noise. The share of draft findings stopped this way appears in your analytics as **Stopped by verifier** under Insights → Quality. It is controlled by `verify_findings`, which is on by default. See [how verification works](https://mergeharbor.com/product#verify).

## 9. The posting bar

Deeper tiers look harder, but they do not get to say more. Every tier posts against the same bar:

- Notes about missing tests, naming, documentation or style are held back unless your strictness is set to high.
- A small note about code that already has a serious finding is folded into that finding instead of becoming a second comment.
- The same issue found in several places becomes one comment, and issues already raised on the pull request are not repeated.
- Your filters apply: `min_severity`, `categories` and `max_comments` (extra findings go to the summary instead of inline).

With evidence-based scoring turned on, each finding's confidence is recomputed from what the verifier found, whether a deterministic check agrees and how your team has responded to that kind of comment. With a precision target set, only the findings that together meet it are posted. Critical findings always are. The guide on [reducing false positives](https://mergeharbor.com/guides/reduce-false-positives) covers these settings in detail.

## 10. Posting to the code host

What is left is posted natively on the code host:

- **A summary** of the change, a confidence score from 1 to 5, and optionally a diagram.
- **Inline comments** on the exact lines, each with severity, category, confidence and a suggested fix where one applies, plus an optional prompt you can hand to a coding agent.
- **A status check** you can require before merging, and if you use it, a separate [merge gate](https://mergeharbor.com/guides/merge-gates) check that combines the review with tests, approvals and linked requirements into one safe-to-merge verdict.

On GitHub this is a check run; on GitLab, Bitbucket, Gitea and Azure DevOps it is a commit or pull request status. The [GitLab setup guide](https://mergeharbor.com/guides/gitlab-merge-request-setup) shows what this looks like on a merge request.

## 11. The next push: incremental review

When the author pushes a fix, MergeHarbor reviews only what changed since the last review, and earlier findings carry forward. Files that have not changed since the last review are not reviewed again unless someone asks for a re-review. When a push fixes a finding, the finding is marked resolved, and the code-host thread can be resolved too.

Re-reviewing the same commit at the same tier uses no credits. The guide on [cost per developer](https://mergeharbor.com/guides/ai-code-review-cost-per-developer) shows how this adds up.

## 12. After the merge: learning

The review is not the end of the loop. MergeHarbor watches what happens to its comments:

- A comment whose lines changed before merge counts as **acted on**; one still unchanged at merge counts as **passed over**.
- Thumbs up and thumbs down, dismissals with a reason, and replies are recorded. A reply that explains a convention ("we do this on purpose because…") becomes a **proposed rule** for an admin to approve.
- Points your own reviewers keep raising across pull requests also become proposed rules.

When a team keeps passing on one kind of comment in a repository or folder, MergeHarbor stops posting lower-priority comments of that kind there. Security, correctness, concurrency and data-integrity findings, and every critical finding, are never held back. Nothing learned applies silently: proposed rules need approval, and every learned preference can be undone. See [Learning and review quality](https://mergeharbor.com/docs/learning).

What MergeHarbor learns stays with your organization. MergeHarbor does not train or fine-tune any model on customer code; the [security and data privacy guide](https://mergeharbor.com/guides/security-and-data-privacy) covers what is sent where.

## Why the stages matter more than the model

It is tempting to judge an AI reviewer by which model it uses. In practice the model is one stage of twelve. The index decides whether the reviewer can see the caller that breaks. Redaction decides whether a secret leaves your network. Verification and the posting bar decide whether engineers keep reading the comments. Learning decides whether the reviewer is better in month three than in week one.

## Try it on your own pull requests

The fastest way to see the pipeline is to run it. [Start a 14-day trial of the Team plan](https://app.mergeharbor.com/signup), with no card required, connect a code host, and open a pull request. Reviews start right away, and codebase context is added as indexing completes.

## Further reading

- [How MergeHarbor reviews a pull request](https://mergeharbor.com/product#how-it-reviews), with each stage on one page
- [What is AI code review?](https://mergeharbor.com/guides/what-is-ai-code-review), and how to evaluate a tool
- [How to reduce false positives in AI code review](https://mergeharbor.com/guides/reduce-false-positives)
- [Configure reviews](https://mergeharbor.com/docs/configuration): the full `.mergeharbor.yml` reference
- [Review tiers and credits](https://mergeharbor.com/docs/review-tiers)