AI Review: LLM Pull Request Comments Across Six Version Control Platforms

The gap AI Review fills between a linter and a human reviewer

A linter catches what it has rules for. A human reviewer catches what they have time for, and on a busy repository that is often the first two files of the diff. AI Review targets the space in between: a model reads the change and writes comments back into the merge request where the discussion already happens. The README frames the goal as reducing noise in pull requests and saving review time, and the feature list is organised around that single loop rather than around static analysis.

The intended user is a team that already runs CI on a supported platform and is willing to hand a diff to a third-party model. The README is explicit that the tool runs client-side and never proxies or inspects requests, which matters if your concern is an intermediary service holding your source. It does not mean the code stays inside your network. Choosing a hosted provider such as OpenAI, Claude, Gemini, Bedrock, OpenRouter, or Azure OpenAI sends the diff to that vendor. Only the Ollama option keeps inference on infrastructure you control, and the README lists Ollama alongside the hosted providers without ranking them.

Five run modes and what each one sends to the model

The command surface is the clearest part of the documentation. Five subcommands map to five review shapes, and the README shows each one in use:

ai-review run-inline ai-review run-summary ai-review run-context ai-review run-inline-reply ai-review run-summary-reply

The first three are the review modes. Inline works line by line inside the diff and is the closest analogue to a human leaving a comment on a changed line. Context widens the window to multiple files, which the README describes as detecting cross-file issues and inconsistencies. Summary produces one high-level post with highlights, strengths, and major issues. The last two are reply modes: run-inline-reply answers inside an existing inline thread, and run-summary-reply continues the summary-level discussion. The README states that replies can clarify decisions, propose fixes, or provide code suggestions.

The split matters because the three review modes are not variations of one prompt. They differ in what the model is asked to look at, and a team that enables all five at once will produce a lot of text on every merge request. The reply modes in particular assume a human is already in the thread and wants the model to answer, which is a different product decision from having the model open the conversation.

Agent mode: shell commands before the review, not instead of it

The feature that separates this project from a thin wrapper around a chat completion is agent mode. The README describes it as an iterative ReAct-style loop in which the model can explore the repository with shell commands (ls, cat, rg, git) before producing a final review, giving it deeper context than a single-shot call.

The mechanism is worth stating plainly. Instead of packing a fixed diff into one prompt, the tool lets the model decide what else it needs to read, run a command, observe the output, and continue. That is how a reviewer notices that a changed function is called from a file outside the diff. It is also a larger attack surface. The commands named in the README are read-only, but the loop is described as shell access, and the README does not publish a sandbox, an allowlist, or a command filter. On a CI runner with repository credentials and possibly cloud tokens in the environment, that is the part of this tool a security reviewer should read first. The README's privacy notice covers request proxying, not what an agent loop can read on the runner.

Agent mode is also slower and more expensive than a single call by construction: each iteration is another round trip. For a small diff on a repository the model can already infer from context, the extra loop buys little.

Configuration: YAML, JSON, ENV, and the override order

The README states that configuration supports YAML, JSON, and ENV with overrides in CI/CD pipelines. Installation is a single command:

pip install xai-review

Or, without installing anything, the Docker image:

docker run --rm -v $(pwd):/app nikitafilonov/ai-review:latest ai-review run-summary

Before the first run the README asks you to create a basic configuration file, .ai-review.yaml, in the root of the project. The example begins with an llm block whose provider key is set to OPE, and the README excerpt stops there. That truncation is the practical problem with evaluating this tool from the README alone: the provider enum values, the credential keys, the VCS selection, and the prompt paths are all referenced but not shown. The README points at docs/configs/.ai-review.yaml as the source of truth, and that file, not the front page, is what you should read before writing your own.

The design choice to support ENV alongside file configs is the right one for CI, where secrets belong in the platform's secret store rather than a committed file. The README does not spell out precedence between a YAML value and an environment variable of the same name, so if you set a provider in both places, verify the behaviour on your installed version rather than assuming.

Where AI Review is the wrong tool

The clearest limitation is that this is an advisory tool, not a gate. Nothing in the README describes an exit code that fails a pipeline when the model finds a serious problem. It posts comments and summaries. If your requirement is that a build goes red when a change violates a rule, a rule-based linter or a policy check enforces that deterministically, and a language model does not, because the same diff can produce different output on two runs.

Cost and latency are the second constraint, and they are not published. The README gives no token counts, no per-review price, no timing. Every merge request spends provider quota, and agent mode spends more because each exploration step is a separate call. On a repository with frequent small commits, that is a recurring bill with no ceiling described in the material.

The third is prompt maintenance. The README lists customizable prompts for inline, context, and summary reviews as a feature, and it is one, but it is also an ongoing artifact. A prompt tuned to your guidelines is a file that needs review like any other, and the README does not describe a prompt versioning or testing workflow. Teams that will not maintain that file should expect generic feedback.

How this differs from a single-shot reviewer or a hosted review bot

The obvious alternative is a hosted code review service, where you install an app on the repository and the vendor runs the model on their infrastructure. The difference is not the comment format. It is where the diff goes and who pays. A hosted service sees your code on their side and bills you through their plan. AI Review runs in your pipeline, uses your provider credentials, and posts through your platform token, which the README describes as fully client-side with no request proxying. For a team that cannot send source to an unvetted intermediary but can send it to a model vendor they already have a contract with, that distinction decides the choice.

The second alternative is a script that calls a model API directly from a CI job. That is genuinely less machinery: one HTTP call, one comment. What it does not give you is the platform abstraction. AI Review targets GitHub, GitLab, Bitbucket Cloud, Bitbucket Server, Azure DevOps, and Gitea behind one command set, and the README's live preview table shows the same inline, context, and summary modes producing output on GitHub, GitLab, and Bitbucket from the same commands. If you are on one platform and will stay there, the abstraction is overhead. If you are on Bitbucket Server or Gitea, where hosted review bots are thinner, it is the reason to look at this project at all.

Release cadence, licensing, and what to check before adopting

The release history shows a fast cadence: v0.75.0 and v0.76.0 on the same day, then v0.77.0 roughly three weeks later. Pre-1.0 version numbers with this frequency mean configuration keys and prompt formats can move between minor releases. Treat the .ai-review.yaml in your repository as something to re-check against docs/configs after an upgrade, and pin the version in your CI job rather than tracking latest, particularly for the Docker image tag.

On licensing, the repository is Apache-2.0, which permits commercial use and modification and includes a patent grant. Two details sit outside that and are worth confirming yourself: the package is published on PyPI as xai-review, not under the repository name, and the README links a separate LICENSE file at the repository root. Read the LICENSE file and the PyPI metadata for the distribution you install. This is a description of what the material shows, not legal advice.

The README also links a Boosty page for support and lists improving review accuracy, reducing false positives, and expanding integrations as the things funding pays for. That tells you the maintenance model is a single maintainer with optional donations, which is a reasonable thing to weigh when the tool sits in your merge request path. The project is not archived, and the last push and latest release are the same day.

Editorial conclusion

Adopt AI Review if your merge requests already live on one of the six supported platforms and you want review output produced by your own model account with no intermediary service, and if you are willing to maintain a prompt file and a YAML config as part of the repository. Do not adopt it if you need a guaranteed blocking gate: the tool posts comments, and the README describes no pass/fail exit contract, so nothing stops a merge on its own. Before wiring it into a pipeline, confirm which config keys your installed version accepts by reading the .ai-review.yaml example shipped in docs/configs rather than the truncated snippet in the README, and check the LICENSE file and the PyPI metadata for the xai-review package name, since the repository is Apache-2.0 while the distribution is published under a different name than the repository.

Official sources

1. License: Apache-2.0
2. Nikita-Filonov/ai-review on GitHub
3. Project website
4. README
5. Releases