DEV Community: Emil Reiter

Azure Repos merge gating for AI reviewers: the status check policy

Emil Reiter — Wed, 21 Oct 2026 00:30:05 +0000

On Azure Repos, an AI reviewer can only stop a merge if a branch policy requires a status check whose genre and name match a status that reviewer posts. Review comments and votes leave the Complete button where it was. The mechanism is the PR Status API plus a required status check policy, and it lives on the branch rather than in the reviewer's own settings. That distinction decides whether a tool is a merge gate or an advisory commenter on your pull requests.

What actually blocks completion in Azure Repos

Azure Repos gates merges through branch policies, and for an external service the relevant one is the status check policy. The reference of available status checks spells out how a posted status maps to merge behavior:

Status	With a required policy	With an optional policy
`succeeded`	Unblocks the policy	Informational
`failed`	Blocks merge	Informational
`error`	Blocks merge	Informational
`pending`	Blocks merge, awaiting result	Informational
`notApplicable`	Bypasses the policy requirement	Informational
`notSet`	Treated as pending	Informational

Two entries matter when you wire up a reviewer. notApplicable is the documented way to exempt a specific pull request from a required policy without editing the policy, which is useful when a check genuinely doesn't apply to a change such as a docs-only edit. notSet behaving as pending means a service that creates the policy but never posts a status leaves the pull request permanently blocked. That's the failure mode to watch for during a first rollout, and it's a quiet one because nothing errors.

The same page lists what Azure DevOps posts on its own: AdvancedSecurity/AllHighAndCritical and AdvancedSecurity/NewHighAndCritical from GitHub Advanced Security, plus {pipeline-name}/codecoverage from Azure Pipelines. Both Advanced Security checks need Advanced Security enabled on the repository and a build validation policy with the scanning tasks configured to wait for processing, otherwise the statuses don't reflect the latest scan. Everything else arrives through the PR Status API, and the calling identity needs Contribute to pull requests on the repository before it can post anything.

Edition scope is worth pinning down here. The branch policies page covers Azure DevOps Services and Azure DevOps Server, so the policy mechanism is available on both. The reference of native first-party status checks is headed Azure DevOps Services, which is the list Microsoft maintains. A Server team configures status check policies the same way; the checks that exist out of the box are the Services-side ones.

Configuring the status check policy for a third-party reviewer

The how-to for an external service walks through adding the policy under Branch policies, then Status checks. The fields are where the behavior gets decided.

Policy requirement sets optional or required, and only required blocks completion. An optional policy still shows the status on the pull request, which is a reasonable way to run a reviewer in observe mode before it can hold up merges.

Authorized identity restricts which identity's status counts toward the policy. Leaving it open means any account that can post a status to the repository can satisfy the check, which is a real gap in a large organization where integrations accumulate. Pinning it to the reviewer's service account or service principal is the tighter setup, and it turns credential rotation into a merge-gating concern rather than just an integration concern. The expiry paths for these integrations are worth checking against whatever you configure here.

Reset conditions decide whether a posted status stays valid when the source branch changes. For a check tied to a specific commit, the documented guidance is to reset the status whenever there are new changes. Skip that and a reviewer's approval of an earlier revision keeps the gate open for code it never read.

Policy applicability has two settings. Apply by default enforces the policy from pull request creation, and the PR can be exempted by posting notApplicable. Conditional means the policy doesn't apply until the first status is posted, which supports an orchestration pattern where one policy evaluates which others should apply and then posts statuses to activate them.

There's a practical detail that trips people up on the first setup. The status dropdown only lists genre and name values for services that have already posted at least one status to a pull request. A new integration that hasn't run yet won't appear in the list, so you type genre/name directly into the field. Until the service posts, the policy shows as not set on the pull request, and per the table above that reads as pending.

Iteration status and when a re-review is required

The pull request extensibility page covers the difference between posting a status against a pull request as a whole and posting it against a specific iteration. Iteration status is what makes a check revision-specific: it lets the policy require that the latest iteration has a status of succeeded, so a push invalidates the previous approval. That only works when reset conditions are set to reset on new changes, which the docs call out directly.

There's a documented ceiling attached to it. A pull request with more than 100,000 modified files doesn't support iterations, so further commits land without creating a new iteration, and posting a status against a non-existent iteration returns an error. For a review integration that means the gate falls back to pull request level on very large changes. That's an edge case until an agent opens a branch-wide refactor, and then it isn't.

The Copilot branch policy that requests a review and nothing more

Azure Repos has a Copilot code review feature, and its branch policy is easy to misread. The get started page states that feature enablement and automatic review are separate settings, and the "Automatically request Copilot code review" policy does what its name says: it adds Copilot as a reviewer on pull requests targeting the configured branch. Microsoft documents no route for Copilot to post a status check on Azure Repos, and none of the native checks in the status check reference belong to the feature. So this policy changes who reviews the pull request, and the merge gate stays where it was.

Enablement runs across three scopes, which is worth planning for. A Project Collection Administrator turns the feature on for the organization, a Project Administrator can scope it per project, and a repository owner enables it per repository when project settings allow overrides. Effort level is set at the project level with an option to let repositories override, and higher effort consumes more tokens. Billing runs through an Azure subscription linked to the organization and Azure Cost Management, which is a different procurement path from a per-seat plan.

The preview note attached to the feature states limited preview, no SLA, and that functionality may change or be removed. The documentation is scoped to Azure DevOps Services. Teams on Azure DevOps Server get none of it and need a self-hosted reviewer instead.

What each AI reviewer's docs establish about gating

I read what the vendors document for Azure Repos rather than assuming a general claim about blocking carries over to this forge.

Tool	Azure Repos route	Documented blocking mechanism	What it means for the gate
CodeRabbit	PAT or Microsoft Entra service principal, plus a Service Hooks webhook	Pre-Merge Checks run in off, warning or error mode; error blocks only when paired with the Request Changes workflow. Its Azure DevOps permission table lists posting statuses among the capabilities it needs.	Blocking is configured inside CodeRabbit, and a status route is present in the documented permissions. Pairing it with a required status check policy is what makes the block affect Azure Repos completion.
Qodo	Portal connection to Azure DevOps; the deployment matrix marks on-prem unsupported and air-gapped N/A for Azure DevOps Cloud	The severity threshold filters which findings appear as inline comments, and a below-threshold finding still appears in the summary	Findings are advisory on Azure Repos. Self-hosted Azure Repos is not a documented deployment option, so the gate has to come from whatever posts a status.
Kodus	Azure Repos webhook through Service Hooks, with a signed token and one subscription per event type	Suggestions post non-blocking by default; Request Changes is optional, and the compliance cookbook says to enable it so violations block merge. Status shows as a comment on Azure DevOps because there is no reaction API.	Request Changes is a review state. Whether it gates completion depends on the branch policies on the target branch, so the status check policy is still the lever.
Copilot code review	Native, Services only, limited preview	None documented; the branch policy requests a review	Advisory. The gate remains a status check policy or the minimum reviewers policy.

Two rows deserve a second look.

Kodus's Azure Repos webhook is the one that requires an encrypted token query parameter, produced by encrypting CODE_MANAGEMENT_WEBHOOK_TOKEN with CODE_MANAGEMENT_SECRET using AES-256-CBC, and Kodus returns 403 Unauthorized when it's missing. Each event type needs its own service hook subscription, so pull request created, updated, merge attempted and comment events mean four subscriptions. Create only the first one and updates and comments won't trigger a review, with nothing in the UI indicating the gap.

Qodo's deployment matrix is the most explicit vendor statement I've found on where each tool can run, and it marks Azure DevOps Cloud as on-prem unsupported with air-gapped N/A. The on-prem Azure DevOps guide walks through Entra app registration and Service Hooks against dev.azure.com, which are Azure DevOps Services constructs. Read together, Qodo on-premises targets Azure DevOps Services, and self-hosted Azure Repos isn't covered.

CodeRabbit's Azure DevOps page is detailed on setup, including the note that the Edit Subscriptions permission on Service Hooks cannot currently be granted through the UI and is granted per project, which is real work across a large organization. The Pre-Merge Checks page is explicit that warning is the default enforcement mode and that error only blocks when paired with the Request Changes workflow, so a team that enables checks and assumes merges are gated has an open gate.

If you want a self-hosted reviewer that posts statuses directly, PR-Agent wired into Azure Repos branch policies and Service Hooks is the configuration to study, because it runs in a pipeline you control and can call the PR Status API with a genre and name you choose.

What to check before you rely on a reviewer

The gate is a branch policy, so the setup work happens in Azure Repos no matter which reviewer you pick. Before treating any AI reviewer as a merge gate, confirm that the service posts a status through the PR Status API, note the exact genre and name it uses, create a required status check policy with those values, and pin the authorized identity to the reviewer's service account. Then push a commit after a passing review and confirm the policy resets. A gate that stays green after a new commit is approving code nobody read.

For teams that want the reviewer to stay advisory, the optional policy gives you the check on the pull request without blocking completion, and the status values still render in the Policies section. That's a sensible place to start, since it keeps the first rollout from freezing merges while you learn what the reviewer actually catches.

FAQ

Can an AI code reviewer block a merge in Azure Repos?

Only if it posts a pull request status and a required status check branch policy matches that status's genre and name. Review comments and votes don't change whether a pull request can complete, because completion is governed by branch policies.

Does the Automatically request Copilot code review policy block merges?

No. That branch policy requests a Copilot review on pull requests targeting the configured branch. Microsoft documents no route for Copilot to post a status check on Azure Repos, and none of the native status checks in its reference belong to the feature.

What happens if a status check policy exists but the service never posts a status?

The policy shows as not set on the pull request, and a notSet value is treated as pending, so a required policy blocks completion until the service posts a status.

What GitLab, Azure DevOps and Bitbucket hide in large PRs

Emil Reiter — Mon, 19 Oct 2026 01:45:02 +0000

A large pull request runs into two different limits, and they fail in different ways. The forge decides how much of the diff it will render, and past that point you get a partial view with a warning on screen. The reviewer decides how many files it will analyze, and past that point you get no review at all. Raise the first number and leave the second alone, and you still end up with a pull request that nobody, human or automated, actually looked at.

That split matters more now that agent-authored changes arrive in bigger chunks. The two numbers also live in different places, are owned by different people, and get quoted as if they were one limit.

The forge cap: how much of the diff renders

GitLab is the only one of the three that publishes a full set of diff limits with both defaults and maximums, and it is the only one where the ceiling depends on the offering you are on. On GitLab Self-Managed and GitLab Dedicated, the defaults are a 200 KB maximum diff patch size, 1,000 changed files, and 50,000 changed lines, raisable to 500 KB, 3,000 files, and 100,000 lines. When a diff reaches 10 percent of any of those three values, GitLab collapses the files behind an expand link. Past any of them, the diff is shown as Too large and cannot be expanded in the UI at all. The line that catches people out is that these limits apply to the UI and to the API endpoints that return diff information, so a bot reading the merge request through the API sees the same truncation a human does. On GitLab.com, the same page states that diff limits cannot be configured, which makes it the one GitLab offering where you have no lever.

Bitbucket splits by edition, and the two editions behave nothing alike. Bitbucket Cloud caps a single file's diff at 2,000 changed lines or 102,400 bytes of raw diff data, the entire diff at 8,000 changed lines, and the whole diff at 200 files. None of those are configurable; when you hit them the pull request stops rendering as one page and loads files individually instead. Bitbucket Data Center works off page.max.diff.lines (10,000 by default) and page.max.changes (1,000 by default) in bitbucket.properties. A Data Center admin can move those numbers, and a Cloud admin cannot.

Azure Repos publishes its caps as notes inside the review flow rather than as a limits page. Review and comment on pull requests states that the summary view does not show changes for a file larger than 0.5 MB, and that for a single file larger than 5 MB the diff view shows truncated content, with the docs pointing you at a local diff tool for the full thing. Those two pages carry the Services and Server monikers, so unlike Copilot code review, the rendering behavior is the same on both editions.

Forge and edition	Per-file cap	Whole-diff cap	Configurable
GitLab Self-Managed / Dedicated	part of a 200 KB patch size, 1,000 files, 50,000 lines set	same set	Yes, up to 500 KB, 3,000 files, 100,000 lines
GitLab.com	same defaults, fixed	same	No
Bitbucket Cloud	2,000 changed lines or 100 KB	8,000 changed lines, 200 files	No
Bitbucket Data Center	`page.max.changes` 1,000	`page.max.diff.lines` 10,000	Yes, in `bitbucket.properties`
Azure Repos (Services and Server)	summary view hides files over 0.5 MB; single file over 5 MB truncated in diff view	not stated	Not stated

The second gate: the reviewer's own file cap

The forge cap degrades a view. A reviewer's file cap does something harsher: it skips the pull request. That is a different failure mode, and it is the one that produces a merge request with zero automated comments and no obvious reason why.

Kodus documents both numbers. The review flow page lists "PR exceeds the configured file limit" as a skip condition, and the troubleshooting page puts the working figure at 2,000 reviewable files after the ignored-file patterns are applied. A pull request with 2,500 files where 600 are lock files still gets reviewed, because the cap counts what is left after filtering. When it does skip, the status shows as skipped rather than a review, and on Azure DevOps and Bitbucket there is no reaction API, so that status arrives as a comment instead of a reaction. A team watching for a reaction on those two forges will see nothing.

CodeRabbit does not publish a maximum diff size, so I am not going to invent one. What its automatic review controls document is volume management by commit and path rather than by size: auto_pause_after_reviewed_commits defaults to 5 and pauses incremental reviews after that many reviewed commits, drafts defaults to false so draft pull requests are skipped, base_branches defaults to the default branch only, and ignore_usernames skips whole authors. path_filters is the lever for excluding lock files and generated code from a review. The practical consequence is that a 60-commit pull request can stop getting incremental reviews at commit five without anyone having configured anything, which reads as a broken integration unless you know the default is there.

Qodo's constraint is about display rather than skipping. Its severity threshold applies to inline comments only, so a finding below the threshold still shows up in the summary, and the resolved-findings overflow section collapses on GitHub, GitLab and Azure DevOps but not on Bitbucket or Gerrit, where findings past the breakpoint do not display in the pull request. That is worth knowing before you conclude a reviewer found nothing on Bitbucket.

Why raising the GitLab limit does not fix the skip

The tempting move on self-managed GitLab is to raise the diff limits to their maximums and call the problem solved. That does address the truncation, including the API truncation, and it is genuinely the right call for a large monorepo. It does not touch the reviewer's own cap, which is a separate number in a separate product, and it does not help a team on GitLab.com where the value cannot be changed. If your chain includes a tool that skips at 2,000 files, a 3,000-file ceiling on the GitLab side just means GitLab will render a diff the reviewer will refuse to read.

The same logic runs the other way. A team that tunes its reviewer's ignored-file patterns down to something aggressive will get reviews on pull requests whose diffs the forge still truncates. In that case the reviewer is commenting on a partial view, and a finding about a file that was never rendered is a finding about code it did not see.

The judgment I would make from these numbers: for most teams the reviewer cap deserves attention before the forge cap does. Truncation is visible, the UI tells you a file was too large, and a human reviewer can still open the file locally. A skip is silent. It looks exactly like a reviewer that had nothing to say, and the pull request merges on that basis.

What to check before you tune anything

Start by identifying the offering, because it decides whether you have a lever at all. GitLab Self-Managed and Bitbucket Data Center are tunable; GitLab.com and Bitbucket Cloud are not. Then write down the smallest cap anywhere in your chain, forge and reviewer, and treat that as your real limit rather than the largest one.

If your pull requests are produced by coding agents, the file count grows faster than the line count, which is the axis these caps are usually set on. Filtering generated files and lock files out of review is the cheapest lever on both sides, since it reduces the number a reviewer counts. Where that is not enough, splitting by concern beats raising limits, because every number in the table above is enforced somewhere you may not control.

Two related pieces go deeper on the self-managed side: which AI review routes actually run on GitLab Self-Managed and what is native on Bitbucket Data Center and what is not. For the Azure Repos edition split, Services versus Server per tool covers what changes when you are not on the hosted service.

FAQ

Does a forge's diff limit apply to the API as well as the UI?

On GitLab it does. The documented diff limits apply to the UI and to the API endpoints that return diff information, so a review bot reading the merge request through the API sees the same truncation a human does. That is the detail that makes the limit a review problem rather than only a rendering problem.

Can I raise the diff limits on GitLab.com?

No. GitLab documents diff limits as configurable on Self-Managed and Dedicated, and not configurable on GitLab.com.

Is Bitbucket Cloud's diff limit configurable?

No. Cloud caps a single file at 2,000 changed lines or 102,400 bytes, the whole diff at 8,000 changed lines and 200 files, and none of those values can be changed. Bitbucket Data Center is the edition where an admin can raise the equivalent properties in bitbucket.properties.

Free AI code review for GitLab, Azure DevOps and Bitbucket

Emil Reiter — Wed, 14 Oct 2026 00:45:01 +0000

Most free AI code review options assume the code lives on GitHub. On GitLab Self-Managed, Azure DevOps Server or Bitbucket Data Center, the realistic choices are an open-source reviewer you host yourself and pay only for the model calls, or a hosted tool's trial. The free-for-open-source programs that dominate "free code review tools" lists are gated on GitHub and on the repository being public there, which describes very few of the teams still running a self-managed forge.

What free means for a self-managed forge

Self-hosted open source is the dependable category. You run the tool, it reads a git diff, and the only external dependency is a model endpoint you already control. That works behind a firewall because nothing outside has to reach into your forge.

A hosted tool's free tier sits at the other end, and its shape moves. CodeRabbit's current pricing page lists Essentials at $24 per developer per month billed annually, Team at $48, Advanced at $72, and a custom Enterprise tier, with a 14-day trial on all of them. No free plan appears on that page, and self-hosting is listed as an Enterprise feature. A recommendation that starts with "it's free" ends, for a GitLab Self-Managed team, on a trial and then on a sales call.

Forge-native features are the last corner. GitLab's Code Review Flow page lists the tier as Free, Premium and Ultimate across GitLab.com, Self-Managed and Dedicated, and notes it can run with self-hosted models; what that costs depends on the Duo entitlement your instance carries, and the edition split for AI review on self-managed GitLab is where the decision actually lands. Azure Repos has no comparable native reviewer on Server, because Copilot code review is documented for Services. Bitbucket's native AI review is Cloud-only, which the Bitbucket Data Center breakdown covers end to end.

Self-hosted routes that cover all three forges

Three options are worth putting on the shortlist for a self-managed GitLab, an Azure DevOps Server behind a firewall, or a Bitbucket Data Center: PR-Agent, Alibaba's Open Code Review, and Kodus Community. They differ in how they attach to the forge, which matters more than the feature list when the forge is internal.

PR-Agent after the Qodo donation

PR-Agent is a community-owned project that Qodo donated, and the repo now sits in the PR-Agent org under an MIT license. It is explicitly not Qodo's product for open-source projects, which lives elsewhere, and the README notes the project is in the process of being donated to an open-source foundation.

The supported-platform matrix on the current PR-Agent docs lists Describe, Review, Improve, Ask, Add Docs and Help as supported on GitHub, GitLab, Bitbucket, Azure DevOps and Gitea, with CLI and app/webhook deployment available on all five. Gerrit and CodeCommit are registered providers kept out of that main table, and they do not support GitHub-flavored markdown, so /describe drops the semantic file-type sections there.

A few rows in that matrix are provider-specific, and they are the ones that decide whether the tool feels native on your forge. The tagging bot is GitHub-only. Several tools run but post their output as a comment instead of applying it where the provider cannot write files. /help_docs has been disabled since v0.36.1 while a credential-exposure issue is fixed.

Where a deployment lives is worth reading before you upgrade anything, because the Docker namespace moved. Releases from 0.34.2 are published under pragent/pr-agent; anything up to and including v0.31 stays at the frozen codiumai/pr-agent namespace with no new pushes. If a pipeline pins an old image reference, that is the first thing to fix.

The newer part of PR-Agent is the instructions layer. Agent Skills let you keep a curated set of SKILL.md files on the host and have their name, description and body injected into /review, /improve, /describe and /ask. Two constraints are worth knowing before you plan around it. Skills are disabled by default, and skills.paths can only be set at host level, never from a repository's own .pr_agent.toml, because a repo that could redirect the filesystem scan could point the tool at files like ~/.ssh/* and pull them into a model prompt. A repo can only opt in or size the token budget. The other constraint is architectural: PR-Agent makes single-shot model calls, so the standard's progressive-disclosure model does not apply, and every enabled skill's text goes into every pull request prompt up to the token cap. Files in scripts/ and assets/ are skipped, so a skill that depends on running a script will not work.

Deployment detail per forge is where the interesting bits are, and I have separate notes on running PR-Agent on self-managed GitLab and on PR-Agent on Azure DevOps, since Azure Repos needs Branch Policies rather than a YAML trigger.

Open Code Review

Open Code Review is Alibaba's internal review assistant, released as an Apache-2.0 CLI. Because it operates on a git diff instead of on a forge API, it does not care where the repository is hosted, and it needs Git 2.41 or newer. Install is npm install -g @alibaba-group/open-code-review, then ocr config provider and ocr config model.

The command set is broader than a single review pass. ocr review covers staged, unstaged and untracked changes in the workspace, ocr review --from main --to feature-branch covers a branch range, ocr scan reviews whole files with no git history, and ocr delegate lets a host coding agent perform the review itself, in which case no separate model key is needed.

The project's headline claim is a precision argument, and the numbers are its own. Its benchmark is built from 50 popular repositories, 200 real pull requests, 10 languages and 1,505 annotated issues cross-validated by more than 80 senior engineers, and the README states that it beats a general-purpose agent on the same underlying model on precision and F1 while using roughly a ninth of the tokens. Recall is deliberately lower. Treat that as a design claim from the project rather than an independent result, and note that the trade-off it describes is real for review tooling: fewer comments that are more often correct reads better in a busy pull request than broad coverage with a long tail of noise.

Kodus Community

Kodus publishes a free Community tier that runs self-hosted or on their cloud, with reviews unlimited on every plan because the model calls run on your own provider key. That combination is what makes it relevant here: free, self-hostable, and not gated on the repository being public on GitHub.

Two limits shape whether it fits. Community allows up to 10 Kody Rules and 3 plugins, and a self-hosted instance running without a valid license evaluates at most 10 rules per review, oldest first, so an instance with a larger rule library will silently stop firing rules past that point. The rules file detection list is long for a tool at this stage: AGENTS.md and its dotfile variants, .cursorrules and .cursor/rules/**/*.mdc, .github/copilot-instructions.md and .github/instructions/**/*.instructions.md, CLAUDE.md, .windsurfrules, .aider.conf.yml, .sourcegraph/**/*.rule.md, plus a generic docs/coding-standards/** pattern. Matching is case-insensitive, nested files are discovered and scoped to their directory, and @file references inside a rule file are followed one level deep. Files that match the repository-rules template are imported verbatim without an LLM rewriting them, which is the difference between your standards surviving import and being paraphrased.

Connecting it to a self-managed forge is where the free tier gets plainer. The quickstart documents OAuth (recommended) or token for GitHub and GitLab, and token only for Bitbucket and Azure DevOps, with no OAuth path for either. Internal GitLab, Bitbucket Data Center and Azure DevOps Server instances connect by allowlisting a fixed IP. On the licensing point, the repository is public and tagged open source, but GitHub's API reports the license as "Other" rather than an OSI identifier, so if an approved license matters to procurement, read the license file rather than the tag.

The hosted free tiers, measured against self-managed editions

CodeRabbit and Qodo are the two hosted tools most often recommended to teams asking this question, and neither free path is shaped for a self-managed forge. CodeRabbit's pricing page carries no free plan, only the 14-day trial, and separately lists per-developer hourly review limits that rise by tier, with usage-based reviews at $0.25 per reviewed file past the included allowance. Qodo's free offering for open-source projects is described on the PR-Agent README as a distinct product from the open-source agent, and it is aimed at public projects.

For the on-prem side of both vendors, what they document differs by forge and edition, and the per-docs comparison of CodeRabbit and Qodo for self-hosted deployments is where that belongs. The short version for this page is that self-managed coverage is an enterprise arrangement in both cases, which is exactly why the free routes above exist.

Free AI code review routes compared

Self-hosted and free routes:

Route	Cost model	How it attaches to the forge	Own model endpoint	Limit that changes a rollout
PR-Agent	MIT, community-owned	CLI, Docker, webhook/app; GitHub, GitLab, Bitbucket, Azure DevOps, Gitea	Yes, via LiteLLM (Azure OpenAI, Bedrock, Ollama)	`/help_docs` disabled since v0.36.1; skills are text-only and loaded into every prompt
Open Code Review	Apache-2.0	CLI on a git diff, no forge integration	Yes, or delegate to a host agent	Requires Git 2.41; benchmark is the project's own
Kodus Community	Free tier, self-hosted or cloud	PR bot; token-only connect for Bitbucket and Azure DevOps	Yes, BYOK	10 Kody Rules and 3 plugins; unlicensed self-hosted evaluates 10 rules per review

Hosted tiers with a free entry point:

Tool	Free option as documented	Self-managed editions
CodeRabbit	14-day trial; no free plan listed on the pricing page	Self-hosting listed as an Enterprise feature
Qodo	Free version for open-source projects	Documented separately per forge and target; not stated on the pricing page

Picking one for a self-managed forge

If the constraint is that no third party reaches into the forge, the decision is between two shapes of tool rather than three products. PR-Agent and Open Code Review both run as a CLI or webhook with a model endpoint you already have, and the difference is in the review model. PR-Agent reviews through the forge, which is why it has per-provider docs, comment commands and, on some providers, tools that can only post a comment rather than apply a change. Open Code Review reviews a diff, which is why it works anywhere and why it has no comment commands or PR descriptions at all. Choose PR-Agent if you want the reviewer to behave like a native bot in merge requests, and Open Code Review if you want a precision-biased pass over changes and whole files from a pipeline.

Kodus Community is the option to look at when the reason you want a reviewer is your own written standards. Its rule import covers more of the instruction-file formats teams have already checked into repositories than the alternatives here, and per-directory scoping is built into detection, which matters in a monorepo. The trade-off is the ceiling on Community: 10 Kody Rules and 3 plugins, with the unlicensed self-hosted rule cap on top, so a team with a large standards library is choosing between paying for a licence and pruning rules.

Whatever you pick, check the vendor or project page for your edition before you commit to it, because edition support and free-tier scope drift faster than the rest of the documentation. The Docker namespace change in PR-Agent and the absence of a free plan in CodeRabbit's current lineup are both recent examples of the same thing: a "free" answer that was true last year and is not true in your upgrade path.

AI code review credentials by forge: what expires in 2026

Emil Reiter — Mon, 12 Oct 2026 01:45:01 +0000

Originally published at mergerequests.dev.

The credential your review bot authenticates with is the part of the setup that breaks first. Commenting on a merge request is the same job on GitLab, Azure DevOps and Bitbucket, but it is done by four different kinds of token, and two of those token types are being retired during 2026. Teams usually notice when the comments stop appearing while the pipeline stays green.

The dates set the scope for this post. Global personal access tokens in Azure DevOps Services stop working on 1 December 2026, and Microsoft states that Azure DevOps Server is not affected. On Bitbucket Cloud, app passwords could no longer be created from 9 September 2025 and all remaining ones are disabled on 9 June 2026. GitLab splits project and group access tokens by offering, which decides whether the credential a bot needs exists at all on your instance.

What the reviewer credential decides

Four properties of a token shape how a review bot behaves, and none of them depend on the model behind it.

The identity comes first. An OAuth app posts as a dedicated bot account, so the merge request shows something clearly not human. A personal token posts as whoever owns it, which puts a person's name on machine comments and removes the difference between a human review and a bot review from the audit trail. On a codebase with any compliance requirement, that usually settles the choice.

Reach comes second. Scopes decide which repositories the token can read, and on Azure DevOps a personal access token cannot grant more permission than its owner has, so a bot running on a senior engineer's PAT carries that engineer's access to every project the token was scoped for.

Write ability comes third, and this is where editions diverge. Approving, commenting, applying a suggestion and merging are separate permissions, and not every token type on every edition can do all of them.

Lifetime comes last. GitLab invalidates a rotated token immediately, so rotation is a deploy rather than an edit. Azure DevOps deactivates PATs in Entra-backed organizations after 90 days without sign-in. Bitbucket Cloud tokens cannot be edited after creation, so a rotation means issuing a replacement and updating the integration.

GitLab: access tokens are split by offering, and Self-Managed is the generous side

This is the single most useful fact for a team on GitLab Self-Managed, and it runs the other way from what people assume about self-managed software. Per the project access token documentation, project access tokens require a Premium or Ultimate subscription on GitLab.com, where a trial is limited to one token. On GitLab Self-Managed and GitLab Dedicated they are available with any license, and the group access token documentation states the same for group tokens. A team on a free self-managed instance can hand a reviewer a project-scoped token with a defined role and scope, while a team on GitLab.com without a paid subscription cannot.

Personal access tokens sit at Free, Premium and Ultimate on every offering, and the personal access token documentation gives the lifetime rules: 365 days by default, extendable to 400 days from GitLab 17.6 through a feature flag named buffered_token_expiration_limit, with the instance administrator able to change the maximum. That default matters more than it looks, because a bot whose token was issued a year ago stops working on a date nobody wrote down.

The cleaner identity is a service account. Service accounts do not use a seat, are always marked as external users, cannot sign in through the UI, and authenticate with a personal access token. Premium and Ultimate allow an unlimited number, while Free allows 100 per top-level group on GitLab.com and 100 for the entire instance on Self-Managed. A reviewer running as a service account survives staff changes; a reviewer running as a maintainer's PAT does not. The self-managed GitLab setup that follows your own rules covers the configuration side of that, and the credential is the prerequisite for all of it.

Azure DevOps: PATs narrow to one organization, Server is untouched

Microsoft's personal access token page now opens with the retirement notice rather than the instructions: all existing global PATs stop working on 1 December 2026, and the guidance is to migrate to organization-scoped PATs or Microsoft Entra authentication. The same page tells you to avoid PATs where a better option exists and to prefer Entra tokens, managed identities or service principals for applications and automation, falling back to an organization-scoped PAT with the minimum scopes and shortest practical lifetime when a tool does not support Entra.

For a reviewer bot that distinction is concrete. An organization-scoped PAT can only reach one organization, which is the intended outcome of the change, and a service principal or managed identity removes the human owner entirely. The global token was convenient because it reached every organization the user could see, and that is exactly the property being removed.

PAT usage itself has not changed. Azure DevOps accepts one through an HTTP Basic header, base64-encoding the string :{PAT} with the username left empty, and the token expires on the date set at creation, with a notification sent before it does. On an Entra-backed organization, signing in with a new PAT within 90 days is required or the token becomes inactive, which is a policy interaction worth knowing before a long-lived CI credential quietly goes dormant.

Azure DevOps Server is a separate product line and the retirement notice does not apply to it. Server PATs are scoped to a collection rather than an organization, and Microsoft states that no changes are being made to global PATs there. A team on Server 2022 or 2020 that reads the announcement and starts a migration project is solving a problem it does not have. The edition differences between Azure DevOps Services and Server for code review tooling are wider than the credential, and the token change is one of the few places where Server comes out ahead.

Bitbucket Cloud: app passwords are gone, access tokens are per-resource

Atlassian replaced app passwords with API tokens, and the API token page describes the shape: user-based, scoped at creation, optionally scoped to a single workspace, intended for a single purpose, and impossible to view or edit afterwards. Two limitations matter to a review bot. API tokens cannot be used to log in to bitbucket.org, and they cannot manage workspace actions.

The other credential family on Cloud is access tokens, which are tied to a repository, project or workspace rather than a user. That fits a bot better because there is no human owner to lose access, with two catches. Workspace and project access tokens require the Premium plan, and each workspace, project and repository has a hard limit of 25 tokens that cannot be increased. A repository access token is available without Premium, which makes it the practical choice for a per-repository reviewer.

Bitbucket Data Center: the cleanest bot identity, with two catches

Data Center keeps its own HTTP access tokens, and it has a credential advantage Cloud does not. Project and repository tokens require a Data Center license, and once you have one you can issue a token that belongs to a project rather than to a person, which is the cleanest bot identity on any of the three forges. Two documented limits follow from that. Project and repository tokens work with Bearer authentication only and must not be paired with a username in Basic authentication, which breaks the copy-paste example people reuse from Server PATs. And a token cannot merge a pull request, because a merge creates a commit and only users with a valid email address can do that. The token can perform pull request actions at repository write permission; the merge itself needs a user identity.

Suggestion handling differs too, and it decides how much of a review a bot can finish on its own. GitLab merge request suggestion blocks are applied through the suggestions API and are available on Free tier. Bitbucket Data Center exposes an apply-suggestion endpoint, Bitbucket Cloud does not, and Azure Repos has no apply operation at all, so a bot there posts the replacement as comment text and a human applies it. On Bitbucket, where the native AI review actually runs is a separate question from what the token is allowed to do.

Credentials per forge and edition

Forge and edition	Practical bot credential	What limits it
GitLab.com	Service account with a personal access token	Project and group access tokens need Premium or Ultimate
GitLab Self-Managed	Project or group access token, or a service account	100 service accounts for the instance on Free
Azure DevOps Services	Entra service principal or managed identity; organization-scoped PAT as fallback	Global PATs stop working 1 December 2026; PATs go inactive after 90 days without sign-in in Entra-backed orgs
Azure DevOps Server	Collection-scoped PAT	Not affected by the global PAT retirement
Bitbucket Cloud	Repository access token	Workspace and project tokens need Premium; 25-token cap per resource
Bitbucket Data Center	Project or repository HTTP access token	Requires a Data Center license; Bearer only; cannot merge a pull request

What to check before the dates land

The two retirements have different shapes. The Azure DevOps one is a hard stop on 1 December 2026 for global PATs, and the migration target already exists, so the work is finding every integration that still uses a global token. The Bitbucket one is already done: app passwords are disabled, and anything still holding one is broken now rather than later.

On GitLab, the useful check is whether the bot is a service account or a person. A token owned by an engineer who leaves is a review process that stops without an error, and the offering you are on decides which token types you can issue in the first place.

PR-Agent on Azure DevOps: pipelines, Branch Policies, and webhooks

Emil Reiter — Wed, 07 Oct 2026 00:15:01 +0000

Azure Repos Git does not run a pipeline on a pull request because of a pr: block in YAML. PR validation is implemented through branch policies, so a PR-Agent setup copied from the GitHub workflow does nothing until someone adds a Build Validation policy on the target branch. The PR-Agent Azure DevOps page says this outright, and Microsoft's pipeline documentation for Azure Repos Git states the same rule: to enable PR validation, configure the Build Validation policy for that branch.

That difference decides the rest of the rollout, because the trigger and the identity the agent authenticates as both branch from it, and so does whether the bot can answer a comment at all.

Build Validation replaces the PR trigger

The policy lives under Project Settings, Repositories, Branches. Select the target branch, open Branch Policies, and add the PR-Agent pipeline as a Build Validation policy marked Required. Then delete the pr: section from azure-pipelines.yml, since Azure Repos Git ignores it.

Two conditions are easy to miss. You need to be a project administrator of the project that owns the repository to configure validation builds for an Azure Repos Git repo. And draft pull requests do not trigger a pipeline even when a branch policy is configured, so a team that opens PRs as drafts will not see a review until the PR is marked ready.

There is a difference in what gets built, too. Validation pipelines run against the merge commit of the source and target branches. A push to the source branch carrying [skip ci] in a commit message suppresses the pipelines triggered by that branch, while the Build Validation pipeline still runs on the merge commit. If you use [skip ci] to control CI cost, it will not control this.

The pipeline itself is short. It runs the prebuilt pragent/pr-agent:latest image as a container with the entrypoint cleared, builds a PR URL out of the variables Azure Pipelines injects (System.CollectionUri, System.TeamProject, Build.Repository.Name, System.PullRequest.PullRequestId), sets config__git_provider=azure, and calls the CLI three times for describe, review and improve. The PAT and the model key come from a variable group, and the pipeline needs explicit permission to read that group or the job fails on an empty secret.

Pipeline mode cannot answer comments

Azure Pipelines has no support for triggering a workflow from a pull request comment, and the PR-Agent docs say so plainly. A pure pipeline setup reviews every new pull request and cannot respond to /review typed into a thread. That is the same shape as the self-managed GitLab placement, where pipeline mode fires automatically and comment commands require the webhook server instead.

On Azure Repos the webhook route is a manual service hook. You create it under Project Settings, Service hooks, with the trigger set to Pull request created for a review or Pull request commented on for a supported slash command, and API v2.0 is required for the comment event. The hook posts to your PR-Agent endpoint with a sporadic username and password pair you configure on both sides, sent as basic auth, which is why the endpoint has to be HTTPS.

So the split matches the other forges: pipeline mode when you want describe, review and improve to fire automatically with no service to run, webhook when your team drives review from comments.

PAT or DefaultAzureCredential

The Azure DevOps provider takes either a personal access token or DefaultAzureCredential. The PAT is quick to create, carries an expiration date, and API calls run under the identity of the user who created it. DefaultAzureCredential uses a managed identity or a service principal, and creates a separate Azure DevOps identity for the agent through Microsoft Entra ID.

The org value has to be set in .secrets.toml under [azure_devops] either way. The PAT, when you use one, goes in the same file. With DefaultAzureCredential you supply AZURE_CLIENT_SECRET or rely on the managed identity and the Azure CLI for local runs. The service principal path is the one that keeps the reviewer's identity separate from a person's account, which matters the month that person leaves or their token expires.

How the agent finds its own comments

Once PR-Agent has posted in a thread it answers there, and it works out which comments are its own by reading its earlier ones. A generic mention such as hi agent does not trigger a response. Before the first post on a pull request, or when the Azure DevOps identity changes, you set a stable identity in the [azure_devops_server] section using a GUID or a unique name. During an identity transition the setting accepts a list.

That section name is a trap of its own. azure_devops_server is where the agent identity and webhook credentials are configured, and it is used for the provider regardless of which edition you run, so a team on the hosted service will still find itself editing a section labelled for the server edition.

What the support matrix says works on Azure DevOps

The supported platforms matrix is worth reading before you promise anything to a team. Describe, Review, Improve, Ask, Add Docs and Help are supported on Azure DevOps. Generate Labels is applied, since the provider can set labels. Update CHANGELOG is posted as a pull request comment instead of being applied, because the provider cannot push files. Ask on code lines, Similar Issues and the tagging bot are not supported on Azure DevOps at all.

What else runs on Azure Repos

PR-Agent is not the only option, and the choice comes down to which identity the tool authenticates as and how the incoming webhook is secured.

Kodus connects to Azure DevOps through a PAT with a defined scope set: Analytics Read, Code Read & Write, Graph Read, Identities and Groups Read, Project and Team Read, User Profile Read. Code Write is the one that matters for posting review comments, since without it the connection looks healthy and no comments appear on the pull request. On a self-hosted install the Azure Repos webhook needs a signed token query parameter, an AES-256-CBC value derived from CODE_MANAGEMENT_SECRET and CODE_MANAGEMENT_WEBHOOK_TOKEN, and requests without it get a 403. That is a step GitHub, GitLab, Bitbucket and Forgejo connections do not need, and it is the kind of detail that stalls a self-hosted rollout on Azure Repos specifically. Kodus subscribes to four events: pull request created, updated, merge attempted, and commented.

	PR-Agent	Kodus
Trigger	Build Validation policy, or a manual Azure service hook	Azure service hook, created by the integration or registered by hand
Auth	PAT, or DefaultAzureCredential via managed identity or service principal	PAT with a fixed scope list
Comment commands	Webhook route only, API v2.0 required	Pull request commented event
Self-hosted	Docker image in a pipeline or a webhook server	Self-hosted deployment supported
Webhook security	Basic auth username and password	Signed token query parameter, 403 without it

The edition question decides more than the tool

None of this changes the fact that Azure DevOps Services and Azure DevOps Server are not the same target. Which AI review routes actually run on each edition is the part that decides whether a hosted reviewer is in scope at all, since vendor pages that document a PAT and a service hook against dev.azure.com are describing the hosted service. A Server team that reads those pages and expects the same setup will spend a while chasing permissions that do not exist in the same form.

The wider comparison of what each self-hosted reviewer supports across all three forges is in PR-Agent on GitLab, Azure DevOps and Bitbucket.

What the docs do not establish

Cost per pull request for the pipeline route is not stated on the Azure DevOps page, and neither is whether the webhook route works against Azure DevOps Server behind an air gap. Both questions come up during planning, and neither has a number to cite from the vendor page. For those, the docs point at the general configuration reference and at the issue tracker for comment-trigger support.

AI code review on self-managed GitLab, Azure DevOps and Bitbucket

Emil Reiter — Mon, 05 Oct 2026 00:00:05 +0000

Most "best AI code review tools 2026" comparisons are written as if the forge were GitHub and the deployment model were cloud. For a team on GitLab Self-Managed, Azure DevOps Server or Bitbucket Data Center, that list falls apart at the point where you try to install something. The features are real, the edition is wrong.

The useful comparison for those teams is not a feature matrix. It is a deployment matrix, because the deployment model decides which entries on the feature list you can run at all. Below is what five tools document for their own supported platforms and editions, read from the vendor pages rather than from comparison posts.

The deployment model decides the shortlist

A vendor's capability page tells you what the reviewer can do. The deployment page tells you where that reviewer can run, and it is usually a separate page with a different answer.

Qodo makes this explicit with a per-provider deployment table that splits four models: multi-tenant, single-tenant, on-premises and air-gapped. The rows matter more than the checkmarks. GitLab Self-Managed is listed as single-tenant, on-prem and air-gapped, with multi-tenant marked out. Bitbucket Data Center is on-prem and air-gapped only, with single-tenant marked out as well.

That table is the single most useful artifact I have found for this beat, because it answers the question a self-managed team actually asks: can this thing run inside my network. Most tools do not publish the answer in one place.

Azure DevOps: Services, Server, and where each tool stops

Azure DevOps is two products with one name. Services is the cloud service (dev.azure.com). Server is the on-premises product, the rebranded TFS line, which is what most regulated and air-gapped teams actually run. Very few vendor pages separate them.

GitHub Copilot code review for Azure Repos is the clearest example of why that separation matters. Per Microsoft's own page for the feature, it is scoped to Azure DevOps Services, is in limited preview with no Service Level Agreement, and requires a linked Azure subscription because usage bills through Azure Cost Management. TFVC repositories are not supported. Enablement is three-scoped: a Project Collection Administrator turns it on for the organization, a Project Administrator handles project defaults and repository overrides, and a repository owner enables it per repo. Version control aside, there is no Server edition of this feature documented.

Qodo's table has a different shape for the same platform. Azure DevOps Cloud gets multi-tenant and single-tenant, and on-prem is marked out. That is a cloud-only path for Azure DevOps, which is a limitation worth knowing before you shortlist Qodo for an Azure DevOps Server migration.

CodeRabbit reaches Azure DevOps through two paths. The cloud quickstart lists Azure DevOps among the platforms you can connect with your existing account, and the self-hosted overview lists Azure DevOps among the platforms covered by the self-hosted agent. That second path is the one that matters for Server, because the agent runs inside your infrastructure and connects to the Git platform with a service account.

I wrote up the Services versus Server split in more detail in the Azure DevOps platform notes if you need the per-feature breakdown rather than the deployment view.

Self-managed GitLab and Bitbucket Data Center

GitLab Self-Managed is where the self-hosted options cluster, because the platform itself is designed to run inside your network.

CodeRabbit self-hosting covers GitLab self-managed directly. The gate is the license, not the platform: the self-hosted agent is Enterprise only, for customers with 500 or more user seats, ships as a container image you run on a server, a container platform or a serverless workload, and the deployment instructions are provided during onboarding rather than published. For a GitLab instance that cannot accept inbound connections, the CodeRabbit Reverse Tunnel keeps all connections outbound from your network. Code and pull request data stay inside your environment, and prompts and source leave it only to reach the LLM provider you configure.

Qodo's row for GitLab Self-Managed is the most complete in that vendor's table: no multi-tenant, yes single-tenant, yes on-premises, yes air-gapped. For an air-gapped GitLab instance, that is one of the few vendor-documented paths I can point to.

Bitbucket Data Center is the tightest of the three. Qodo lists it as on-prem and air-gapped only, with multi-tenant and single-tenant both marked out. CodeRabbit's self-hosted agent covers it. CodeRabbit's cloud quickstart also lists Bitbucket Data Center as a connectable platform, which is worth reading carefully, because the integration runs against your instance while the review runs in CodeRabbit's cloud. Which parts of the pipeline leave your network is the question to ask there, and it is different from the self-hosted case. I covered the native versus third-party breakdown of Bitbucket Data Center in what's native on Bitbucket Data Center and what isn't.

The open-source path, and what it asks you to run

For teams that cannot buy an Enterprise tier, the open-source option is the one that covers the widest set of providers. PR-Agent, now community-owned after Qodo donated it, states support for GitHub, GitLab, Bitbucket, Azure DevOps and Gitea, with deployment through CLI, Docker, self-hosted webhooks or CI. It runs on any model reachable through LiteLLM, which includes Ollama for a fully local setup. The repository also documents a Docker namespace migration: releases from 0.34.2 onward publish under pragent/pr-agent, and anything pinned to the older codiumai/pr-agent namespace is frozen at v0.31. If you are running it in a pipeline, that detail is the difference between a working upgrade and a broken one.

The trade is maintenance. You run the service, you hold the provider key, and you own the prompt configuration. I wrote up the PR-Agent self-hosted path across GitLab, Azure DevOps and Bitbucket separately, including the webhook and pipeline options per forge.

Kodus takes a third approach on licensing. Its pricing documentation puts self-hosting in the free Community tier as well as Enterprise, with reviews unlimited on every plan because the model runs on your own provider key through BYOK. The documented Git integrations are GitHub, GitLab and Bitbucket, and Azure DevOps is not listed. Teams that need a self-hosted reviewer for GitLab or Bitbucket can start on the free tier; a team on Azure Repos should treat Kodus as unavailable rather than as a candidate to evaluate. The same docs put Community at up to 10 rules and 3 plugins, and the 2,000 changed-file cap applies to any plan.

What each tool does with your team's rules

Rules are where a review tool either matches your standards or produces generic comments, so the mechanism matters as much as the label.

CodeRabbit offers path-based instructions on glob patterns plus AST-based instructions written with ast-grep, which lets you target structural code patterns instead of file paths. That is a meaningful distinction in a monorepo, where "all controllers" is easier to express as a syntax pattern than as a path.

Kodus documents rule file detection, which imports rule files you already have from other AI coding tools, along with directory-level settings for targeting folders in a monorepo and inheritance from global to repository to directory level. Kody Rules enforce a standard rather than suggest one, which is the part teams generally want when they say the reviewer should follow their conventions.

PR-Agent takes the simplest route: JSON-based prompt configuration you edit in the repository. It is flexible and entirely on you.

The comparison table

Everything here comes from the vendor pages linked above. Where a vendor does not state something for a platform, the cell says so rather than guessing.

Tool	Azure DevOps	GitLab Self-Managed	Bitbucket Data Center	Self-hosted / air-gapped	Licensing gate
GitHub Copilot code review	Services only, limited preview, no SLA; Server not documented	Not stated	Not stated	Not stated for these forges	Azure subscription for billing
Qodo	Cloud only; on-prem marked out	Single-tenant, on-prem, air-gapped	On-prem and air-gapped only	Yes, per provider table	On-prem deployments run on your Kubernetes
CodeRabbit	Cloud connect and self-hosted agent	Cloud connect and self-hosted agent	Cloud connect and self-hosted agent	Yes, container image; Reverse Tunnel for private networks	Self-hosted is Enterprise, 500+ seats
PR-Agent (open source)	Yes	Yes	Yes	Yes, CLI/Docker/webhooks	None; community-maintained, you run it
Kodus	Not listed	Yes	Yes	Yes, Community and Enterprise	Free Community self-hosted; BYOK for models

What to check before you shortlist

Two things decide more outcomes here than any feature comparison.

The first is whether the vendor's platform list includes the edition you run, not the product line. Azure DevOps appears on nearly every list. Azure DevOps Server appears on far fewer, and Copilot code review is documented as Services-only while Qodo's Azure DevOps row marks on-prem out. If you are on Server, those two entries drop off and the shortlist gets short fast.

The second is whether the review runs inside your network. A cloud connector pointed at a self-managed instance is a different security decision from an agent running on your own infrastructure, even when both get the same checkmark on a feature page. CodeRabbit's own documentation draws that line for you: the self-hosted agent keeps orchestration and results in your environment and sends prompts and source only to your configured model provider.

If you want the wider view of what exists per forge, I keep the free and self-hosted options for GitLab, Azure DevOps and Bitbucket in one place, and the CodeRabbit and Qodo self-hosted editions on their own criteria.

The shortlist for a self-managed forge is narrower than the general 2026 comparison suggests, and it is narrower for a reason you can verify on each vendor's deployment page rather than take on faith.

AI code review that follows your team's rules: what each tool actually ingests

Emil Reiter — Wed, 30 Sep 2026 00:15:10 +0000

"Follows our coding standards" is the phrase teams use when they mean "does not post the same generic nit for the fourth time." It sounds like one feature. It is at least three, and they fail in different ways.

The mechanisms are: a rule file the tool reads and treats as review criteria, a per-path instruction that scopes guidance to a directory, and an enforcement rule with a pass or fail attached. A tool can ship one of these and call the result "custom standards." Whether that is enough depends on what your team actually needs, and whether it runs on the edition you are on.

That last part matters more than the feature list. On GitLab Self-Managed, Azure DevOps Server and Bitbucket Data Center, hosted rule ingestion is the first thing to disappear.

Three mechanisms that get called "your standards"

An ingested rule file is the lowest-effort option. You already have a CLAUDE.md, an AGENTS.md, a .cursorrules, or a docs/coding-standards/ folder in the repo. The reviewer scans for those files and uses their content as review criteria. The upside is that the standards document already exists and both humans and coding agents read it. The downside is that the file is guidance, not a check. The reviewer interprets it, and interpretation is inconsistent across runs.

A per-path instruction is a mapping from a glob to free text. You tell the reviewer that anything under src/controllers/** should be checked for auth, input validation, and direct database calls that bypass the ORM. This is more precise than a global guideline file because the guidance only applies where it belongs, which is the difference between useful and noisy in a monorepo.

An enforcement rule with a verdict is the strictest option. The rule has a severity, a path scope, and it either fires or it does not. This is what teams reach for when the requirement is "the reviewer must block this," and it is the mechanism least likely to be available on every plan. Severity levels and the ability to gate a merge are where vendors draw plan lines.

The practical consequence: if your team's real complaint is that the reviewer misses your conventions, a rule file and per-path instructions handle it. If the complaint is that the reviewer is inconsistent and you need a hard stop, only the third mechanism does that, and it may sit behind a paid tier or a licensed self-hosted deployment.

What CodeRabbit ingests, and where it stops

CodeRabbit detects guideline files automatically and applies them as review criteria with no configuration. The code guidelines docs list the patterns: **/AGENTS.md, **/.cursorrules, .github/copilot-instructions.md, .github/instructions/*.instructions.md, **/CLAUDE.md, **/.windsurfrules, **/.clinerules/*, **/.rules/*, among others. Matching is case-sensitive, so a file named claude.md is not picked up.

Scoping is directory-based. A CLAUDE.md at the repo root applies to everything; src/backend/.cursorrules applies only under src/backend/. When directory placement does not match the files a guideline should govern, you switch to the object form of filePatterns with an explicit applyTo glob. That is the per-path mechanism, and it is the one that makes a monorepo workable.

Guidelines can also come from another repository, written as repo:path or owner/repo:path. Here the edition split shows up. On GitHub the source and reviewed repos must share an organization, on GitLab they must share a top-level group, and Bitbucket Cloud must share a workspace. The docs mark the Bitbucket entry Cloud Only. Cross-repo guideline reuse is not a path available on Bitbucket Data Center.

One trap worth calling out because it is easy to hit: adding a guideline filename like CLAUDE.md to path_instructions does not use it as a guideline. It tells the reviewer to review that file as changed code. Use filePatterns.

Qodo's governance layer

Qodo routes rule and standards questions to its governance area rather than its review area. The code governance docs describe Review Standards as turn "your organization's engineering conventions into something that can actually be enforced," with rule enforcement as the explicit, checkable form. There is also a REVIEW.md instructions file and rule generation from PR history indexing.

The difference from CodeRabbit's approach is where the configuration lives. CodeRabbit reads files that are already in the repo. Qodo's standards are managed as governance objects in the portal, which suits an org that wants one set of rules across every repository without relying on each repo carrying the right file. It also means the standards are not part of the codebase, so a review of a rule change is not a code review.

Both approaches are legitimate and they fail differently. Repo-resident files drift when teams copy them and forget to update. Portal-managed rules drift when the portal is edited and nobody notices. Pick based on which of those two failure modes your team already handles.

Kodus and rule files

Kodus ships rule following as a first-class path rather than a side feature. Its Kody Rules overview splits rules into file-level and pull-request-level, with each rule carrying a severity of Critical, High, Medium or Low and a path scope using globs. Rules can reference other files with @file:src/services/userService.ts or @repo:team/api-standards to check consistency against a standard outside the reviewed repo, and can call MCP functions during evaluation.

The distinction that matters for teams already using a coding agent: rules file detection imports the same files CodeRabbit does, plus more, including .sourcegraph/**/*.rule.md, .opencode.json, .aider.conf.yml and docs/coding-standards/**/*. Unlike CodeRabbit's case-sensitive matching, Kodus matches case-insensitively. Nested files are scoped automatically: a services/billing/CLAUDE.md is imported and scoped to services/billing/**. Files it generates rules from are re-synced when a PR closes, and @kody-ignore keeps a file in the repo without it becoming an enforced rule.

There are two limits to plan around. On a self-hosted instance running without a valid license, the docs state that at most 10 rules are evaluated per review, oldest first, and rules past the tenth silently do not fire. Licensed self-hosted and cloud instances have no such limit. The Community plan lists "Up to 10 Kody Rules." So the self-hosted Community edition is where rule-following gets capped, which is the opposite of how most vendors structure self-managed editions.

Kodus also runs self-hosted and supports bring-your-own model keys on every plan, so on a firewalled GitLab, Azure DevOps Server or Bitbucket Data Center the rule evaluation happens against your endpoint rather than a vendor tenant. That is the same reasoning that makes the open-source CLI route attractive on those forges, and the trade-off is the rule-count cap at the free tier.

Comparing the mechanisms

	Ingested rule files	Per-path instructions	Enforced severity / gate	Self-managed edition
CodeRabbit	Auto-detect of AGENTS.md, CLAUDE.md, .cursorrules and similar	`path_instructions` and `filePatterns` with `applyTo`	Custom checks listed in docs	Yes, per its self-hosted docs
Qodo	`REVIEW.md` instructions	Governance objects, portal-managed	Review Standards with rule enforcement	On-premise deployment documented
Kodus	Rule file detection across 11+ tool formats, case-insensitive, nested scoping	File-level and PR-level rules with glob path scope	Critical / High / Medium / Low severity	Self-hosted on every plan, BYOK; 10-rule cap without a license
GitLab Duo	Custom instructions and Duo context	Not stated in the same shape	Depends on the code review feature in use	See the self-managed rules page

Cross-repo guideline sources are the row where editions diverge most. CodeRabbit documents them as Cloud Only on Bitbucket. Kodus's @repo: reference works from a rule definition and is not gated to a single forge. If your standards live in one repo and your services live in forty, that difference is the deciding one.

What to check before you commit

The question to ask a vendor is not whether it supports custom rules. Every tool above answers yes. Ask which mechanism it uses, whether the rules live in the repo or in a portal, and whether the rule limit changes on the self-managed edition you would actually deploy.

For most teams on GitLab, Azure DevOps or Bitbucket, the sequence that works is: put your standards somewhere the team already reads them, point the reviewer at that file, and let per-path instructions handle the directories where generic guidance is worse than none. Add severity-gated rules only where a missed check has a real cost, because hard stops create merge friction that a reviewer's opinion does not.

And if you are on a self-managed forge, verify the edition before the feature. The rule-following story on a hosted tier and the rule-following story on the on-prem edition are frequently documented on different pages, and only one of them applies to where your code actually lives.

GitLab Self-Managed AI review that follows your own rules

Emil Reiter — Tue, 29 Sep 2026 05:15:01 +0000

GitLab Self-Managed now runs two different AI code review features, and which one fires depends on who opens the merge request. That split matters if the reason you want AI review is enforcement of your team's own standards, because the two features are not equally equipped to carry those standards, and the one that runs is not up to you unless you configure it.

This is the self-managed GitLab case specifically. Feature availability, the seat logic and the credit billing apply to Self-Managed and Dedicated as well as GitLab.com, and the docs spell out the seat behavior that decides the reviewer.

Which reviewer runs on a self-managed GitLab instance

The GitLab Duo in merge requests page, at the version documented as v19.5, describes two code review features under one reviewer handle, @GitLabDuo:

Code Review Flow is agentic. It needs no add-on and runs on GitLab Credits. Its context awareness includes repository structure and cross-file dependencies, and the analysis is multi-step agentic reasoning. It opens a review session when it runs.
GitLab Duo Code Review is non-agentic. It requires a GitLab Duo Enterprise seat. It analyzes the merge request and the file diffs within it, in a single pass.

Both show up as @GitLabDuo in the merge request, so you cannot tell them apart by the handle. The difference shows in what the review can see, and that is the whole ballgame for standards that cross file boundaries.

The trigger logic is documented and it is not "the project owner picks once." The feature that runs depends on the user who initiates the review:

Review trigger	Initiating user	Feature that runs
Review requested manually	The user requesting the review	Depends on that user's seat
Merge request created (not a draft)	The merge request author	Depends on the author's seat
Draft merge request marked ready	The merge request author	Depends on the author's seat

If the initiating user has a GitLab Duo Enterprise seat, GitLab Duo Code Review runs. If not, Code Review Flow runs. Both can run in the same project. A user with the Owner role for the group can configure every review in the group to use Code Review Flow regardless of seat type, and when Code Review Flow runs, the credit usage is attributed to the initiating user.

To see which one ran after the fact, check the merge request's activity feed. Code Review Flow starts a review session, and it also appears in the project's sessions. No session means GitLab Duo Code Review handled it.

Code Review Flow vs GitLab Duo Code Review

The two native features differ on the exact dimension teams care about when they want rules enforced:

Detail	Code Review Flow	GitLab Duo Code Review
Type	Agentic	Non-agentic
Required add-on	None, uses GitLab Credits	GitLab Duo Enterprise seat
Context awareness	Repository structure and cross-file dependencies	The merge request and its file diffs
Analysis	Multi-step agentic reasoning	Single pass
Session creation	Yes	No
Which runs	Whichever user lacks a Duo Enterprise seat, unless the Owner pins it	Users holding a Duo Enterprise seat

The practical consequence: a rule like "this interface must match the shared contract in another module" or "new endpoints need an integration test" depends on the reviewer reading more than the diff in front of it. The single-pass feature that a Duo Enterprise seat triggers is the one that stops at the file boundary. If you have spent money on Duo Enterprise seats and expect the seat to buy you the more thorough review, the documented default gives you the opposite. GitLab documents the override, and it is worth knowing why it exists: to stop Duo Enterprise seat holders from quietly burning GitLab Credits, all reviews they initiate default to GitLab Duo Code Review, even when a group Owner has turned Code Review Flow on. An Owner can flip that default so Code Review Flow runs for everyone, and then those reviews consume GitLab Credits.

Making a review follow your team's rules

Native GitLab review is configured per group and, for interaction settings, per instance. The Agent Platform documentation lists automatic reviews, custom instructions and custom comments as review capabilities, and it describes Code Review Flow as the flow that automates code review tasks and enforces coding standards across the team. On a self-managed instance that is the feature to point at when the goal is standards, for the cross-file reason above.

There are two limits worth reading before you build a process on top of it. Interaction in comment threads, where you mention @GitLabDuo to ask about a change or request a different approach, runs on the model selected for Code Review Flow and consumes GitLab Credits separately from the flow. And GitLab states that feedback you give the reviewer does not influence later reviews of other merge requests; adding that behavior is tracked as a proposed issue (560116). So the reviewer does not learn your team's conventions from corrections. Any standard you want enforced on every merge request has to be supplied as configuration, not taught by example.

The related resolve-discussion feature, where @GitLabDuo edits the source branch and pushes a fix, is a different flow and has its own prerequisites, including your own runners or GitLab hosted runners. It is separate from the review feature even though the same handle drives both.

When the native path is not enough

Two other routes run on self-managed GitLab and are worth comparing on the same axis, rules enforcement.

PR-Agent is the open-source route, MIT-licensed and now community-owned, and it runs against a GitLab merge request as a CLI or a webhook server. The pipeline and webhook setup for self-managed GitLab covers the auth types, the comment events and the CI_SERVER_FQDN detail. PR-Agent brings its own configuration surface and a self-hosted model endpoint of your choice, which is why it shows up in the free and self-hosted options for forges that the hosted tools skip. What it does not inherit is your repository's own conventions; you write the configuration.

Kodus runs on self-managed GitLab too, and it connects by allowlisting the Kodus IP (52.55.217.197) in your network firewall, per the quickstart. The rules surface is the reason to look at it here: Kody Rules are team-defined review rules that apply at file level or pull request level, and they can pull in context through variables, file references such as @file and @repo, and MCP functions. Centralized Config keeps every setting and rule in one repository and flows changes through pull requests, which gives review configuration version history and rollback. Reviews run on your own model key (BYOK) on every plan, and the Community tier, which is free and can be self-hosted, caps Kody Rules at 10 and plugins at 3. On the criteria that matter for standards enforcement, the ceiling is the rule scope and the code-review-as-code workflow.

The three routes differ in where the rules live and how much you control:

Route	Where rules are configured	Model	Edition constraint
GitLab native (Code Review Flow)	Per group; interaction settings per instance	GitLab-hosted, billed in GitLab Credits	Self-Managed and Dedicated included; no add-on for the flow, needs credits
PR-Agent	Your own config file or webhook server config	Your model endpoint	None, self-hosted; you run it
Kodus	Kody Rules plus Centralized Config, versioned in a repo	Your own key (BYOK)	Community tier free and self-hostable, Kody Rules capped at 10

The point of the table is not that one wins on every axis. If your team already pays for Duo Enterprise and the enforcement you need fits inside a single diff, the native seat path is the shortest route. If your standards depend on cross-file context or on review rules that live in version control, the native default is not configured for that, and the practical choice is between GitLab's own flow (and its credit billing) and a self-hosted reviewer whose rules you write and version yourself.

One more thing about the seat default worth saying out loud, because it cuts against expectations: buying Duo Enterprise seats does not get you the agentic reviewer by default. It gets you the single-pass one unless a group Owner overrides it. Teams that assumed the seat upgraded the review end up with the narrower feature and no obvious signal in the merge request that it happened, because both run under the same handle. If you are on self-managed and care about standards enforcement, check the group setting before you assume which reviewer is running.

The state of native review configuration for self-managed GitLab as of the v19.5 docs: the flow exists, the seat logic is documented, and the per-instance interaction settings are the lever. Everything above the native layer, the actual rules your team wants enforced, is still something you supply.

Self-hosted AI code review: CodeRabbit and Qodo, per their docs

Emil Reiter — Tue, 29 Sep 2026 03:30:01 +0000

Most "best self-hosted AI code review tool" lists repeat each other's claims and rarely say which edition they read or when. For a team on GitLab Self-Managed, Azure DevOps Server, or Bitbucket Data Center, that gap decides the answer, because "can this run inside our network" changes with the edition, not with the product name.

This page records what CodeRabbit and Qodo document for on-prem deployment, read from their own docs, and puts the Kodus self-hosted path on the same criteria. Where the docs do not establish something, I say so instead of filling the cell.

CodeRabbit self-hosted: Enterprise plan, 500+ seats

Per CodeRabbit's self-hosted overview, the self-hosted option is Enterprise plan only and starts at 500 user seats. The review agent runs inside your infrastructure as a container image, on a bare server, a container platform, or a serverless workload.

Supported platforms listed: GitHub Enterprise Server, GitLab self-managed, Azure DevOps, and Bitbucket Data Center.

Code and pull request data stay in your environment. The review prompts and source code leave it only to reach the LLM provider you configure, so you bring your own model. For a forge that cannot accept inbound connections, the CodeRabbit Reverse Tunnel keeps all connections outbound from your network.

The install instructions are handed to customers during onboarding and are not published. Worth stating plainly, because the absence of a public install guide is not the absence of the feature.

Qodo on-premises: Kubernetes, six Git integrations

Per Qodo's on-premises page, Qodo deploys on Kubernetes inside your infrastructure. Git integrations cover GitHub App, GitLab App, Bitbucket Cloud App, Bitbucket Data Center, Azure DevOps App, and Gerrit. Qodo keeps a separate install path for cloud-hosted Git instances, which is the detail people miss when they assume one on-prem flow covers both.

Same documentation gap as CodeRabbit: the architecture and Helm chart pages sit behind an Enterprise engagement rather than in the public docs.

Kodus self-hosted: the free tier runs on your own key

Kodus splits on pricing rather than on a hidden install guide. The Community plan is free, and per the Kodus pricing page it runs self-hosted or cloud with unlimited users and unlimited pull requests, running on your own provider key. BYOK is the default across every plan, so tokens are billed by your provider and Kodus does not mark them up.

The self-hosted path is documented, not hand-held. The Kodus CLI has a self-hosted setup guide that points the CLI at your own API, including a team key for shared environments and Cloudflare Access service-token support for instances behind Zero Trust. That is enough to run reviews from a pipeline with --fail-on error and fail the build on findings above a severity threshold.

The trade-off sits at the feature level, not the deployment level. Community caps Kody Rules at 10 and plugins at 3, while Teams and Enterprise lift those limits. Cockpit metrics, SSO, and RBAC are Teams and Enterprise. A small self-managed team can run Kodus free and on-prem and pay only for the features it needs, which is a different shape from a 500-seat Enterprise floor.

Where the self-managed edition is the whole question

Both verified vendors cover self-managed GitLab, Azure DevOps, and Bitbucket Data Center in their on-prem docs. That is not universal across the market. GitHub Copilot code review for Azure Repos, for example, is documented for Azure DevOps Services only, and it is in limited preview. There is no Server edition of it. So a team on Azure DevOps Server is not choosing between Copilot and a third-party reviewer; it has no native option to choose from.

If you want the fuller picture of what runs natively on each forge versus what has to come in through a pipeline task or webhook, that is covered per platform elsewhere. For the self-managed code review options that install as a pipeline job or webhook rather than a hosted app, PR-Agent is the one worth reading about.

The comparison, on shared criteria

	CodeRabbit self-hosted	Qodo on-premises	Kodus self-hosted
Minimum to start	Enterprise plan, 500+ seats	Enterprise contract	Community (free)
Deployment unit	Container image, server or serverless	Kubernetes	Self-hosted instance, CLI points at your API
Git platforms documented	GitHub Enterprise Server, GitLab self-managed, Azure DevOps, Bitbucket Data Center	GitHub, GitLab, Bitbucket Cloud, Bitbucket Data Center, Azure DevOps, Gerrit	GitLab, Azure DevOps, Bitbucket among supported providers
Model / tokens	BYO model	Not stated on the public on-prem page	BYOK on every plan, no markup
Install instructions public	No, onboarding	No, behind Enterprise engagement	Yes, documented CLI setup
Air-gap-friendly	Outbound-only via Reverse Tunnel	Not stated on the public page	Not stated as a packaged air-gap mode

Not stated means the public docs do not establish it. For an air-gapped network, that cell is the one to confirm with each vendor directly, because none of these pages commit to a full offline model cache.

What actually decides it

The seat floor is the first filter. If you have 40 developers on GitLab Self-Managed, CodeRabbit self-hosted is not on the table at 500 seats, regardless of how good the agent is. Qodo and Kodus both start lower, and Kodus starts at zero for the deployment itself.

The second filter is how much you trust an unpublished install. Enterprise onboarding is fine for a large org with a procurement process. A five-person platform team trying to stand something up this week is better served by a documented CLI and a BYOK key they already have.

The third is feature limits against your own rules. If your review needs come down to enforcing your team's coding standards, check where the rule ceiling is before you commit: 10 Kody Rules on Community is a real constraint for a large codebase, and the same is true of a 3-plugin cap.

Read the vendor's own page for the edition you plan to run, not the marketing page for the product. The edition is where the answer actually lives.

Reviewing AI-generated code volume on Azure DevOps: the documented lever

Emil Reiter — Sat, 19 Sep 2026 02:30:00 +0000

The question that keeps coming up is how a team reviews the growing volume of AI-generated code without burning out its human reviewers. The honest answer on Azure DevOps is that Microsoft has documented exactly one native lever, and it does not pretend to replace the human. It changes what the human looks at.

That lever is Copilot code review for Azure Repos, acting as an automated reviewer, plus the branch policy machinery Azure has had for years. The two combine into a workflow where the machine absorbs the routine first pass and the human stays the gate. Everything below comes from Microsoft's own documentation, and the edition split matters more than most writeups admit.

Copilot code review is an automated reviewer, not a merge gate

The Copilot code review documentation describes Copilot as "an automated reviewer that posts comments and suggestions on changed code, so you get feedback before a human reviewer signs off." That sentence is the whole strategy. The model is not approving anything. It is a first pass that lands before the human does the work, and approval stays with people.

Three scope details are worth knowing before treating this as your volume answer.

First, edition. Copilot code review for Azure Repos is Azure DevOps Services only. The page carries the standard limited-preview banner: no Service Level Agreement, limited support, functionality can change or be removed without notice. Nothing on the page describes it for Azure DevOps Server. For self-managed teams on Server, the native path is not stated in the docs, which means the answer is a third-party tool wired in by webhook or a build-your-own reviewer, not native Copilot.

Second, enablement is three scopes. A Project Collection Administrator turns the feature on for the organization, a Project Administrator enables it at project level or lets repository owners override, and an individual repository owner enables it on the pull requests in their repo. There is no surprise here, but the three-layer structure matters if you want central control over where the AI reviewer is allowed to run rather than letting each repo decide on its own.

Third, TFVC repositories are not supported. If your team still uses Team Foundation Version Control, this feature does not apply, and that is stated plainly in the prerequisites.

The review effort control, and automatic review policies

Once enabled, the volume story gets concrete. A "review effort" setting controls how thoroughly Copilot analyzes a pull request. A project administrator sets the default and decides whether repository administrators may override it, and a user can pick a different effort level for a single review. The docs are explicit about the trade: higher effort consumes more tokens and increases cost. Billing runs through Azure Cost Management, so this is metered and visible.

The other part is automatic review policies, which let Copilot review new pull requests without anyone requesting a review. That is the real volume lever. Instead of every human starting by chasing down which PRs need their eyes, the model is already in the review list when the PR opens. The person arrives at a PR that has already been read once, with the findings waiting.

This matters specifically for the growing-AI-code scenario. The failure mode of volume review is that reviewers skim everything and miss the one change that matters. An automated first pass does not fix attention, but it does compress the number of things each human has to look at, because the model's comments mark where to look.

Branch policies keep the human in the gate

Copilot code review never replaces the human gate, and this is where the older branch policy system earns its keep. The branch policies documentation is edition-broader than the AI feature. It applies to Azure DevOps Services, Azure DevOps Server, and Azure DevOps Server 2022, so self-managed teams get this part even when they cannot get native Copilot review.

The relevant policies for an AI-volume world are the ones that enforce human sign-off without asking humans to review everything:

Require a minimum number of reviewers keeps the approval count real. The model can comment, but humans still have to approve on protected branches.
Automatically included reviewers assigns specific people when changes touch certain paths. This has been the standard way to make sure the right human sees a risky change, with or without AI.
Check for comment resolution forces the thread to be talked through before a PR completes. With a model now posting comments, this policy is how you guarantee the model's findings are actually addressed rather than silently dismissed.
Build validation runs a pre-merge build on the changes, which catches the class of AI-generated mistakes a reviewer would rather not be the first to see.
Status check policies let other services post success before a PR completes, which is the documented hook that a third-party reviewer on Server edition can use.

The framing that works: the AI absorbs the breadth, the branch policies keep the depth human.

What a volume workflow looks like on Azure Repos

A setup that answers the question directly, using only documented pieces:

Enable Copilot code review at the three scopes for the repositories you want covered. Set a moderate default review effort at project level so cost scales with the default rather than the loudest repo.
Turn on automatic review policies so new PRs get the model's first pass without manual requests.
On your protected branches, require a minimum number of human reviewers, enable comment resolution checking, and add build validation.
Audit the model's comments on a sample of PRs before you widen the default effort level. The limited-preview status means you should not relax human gates on the strength of a feature the vendor has not put on an SLA.

The Server edition, where the native path is not stated

For Azure DevOps Server there is no documented native Copilot review, so the automated first pass has to come from outside the vendor. A third-party reviewer like CodeRabbit integrates with Azure DevOps and runs as an external review service, which means it can sit in the status check policy slot described above. The branch policy half of the workflow works identically on Server and becomes the human gate for that tool too.

One caveat applies to the third-party route the same way it does to the native one: an external reviewer posting comments is not a gate, it is a first pass. The minimum-reviewer and comment-resolution policies are what turn its output into something your team actually acts on.

What is not stated

For self-managed Azure DevOps Server, Microsoft's docs do not say when or whether native Copilot code review will arrive. The limited-preview status of the Services feature reinforces that this is not a production guarantee. Teams on Server who want the automated first pass have to source it outside the vendor, and the branch policy machinery is what keeps the result safe while they do.

The complete answer to the volume question is therefore two documented halves. Native Copilot review on Services makes the first pass automatic and metered. The branch policy system, present across every Azure DevOps edition, keeps the human gate intact so the model's volume does not become the team's risk. Neither half does the whole job, and Microsoft's documentation is clear about what each one does. That is the honest state of the feature, and it is worth reading the pages yourself before promising your team otherwise.

Where free AI code reviewers actually run: Greptile and Refact, by edition

Emil Reiter — Sat, 19 Sep 2026 00:15:06 +0000

Ask which AI code review tools are free and the answers come back as a list of SaaS products. Greptile, CodeRabbit, Qodo, deepsource, sourcegraph each publish a version. Almost every entry in these lists is a hosted product that reviews pull requests on GitHub. If your code is on self-managed GitLab, Azure DevOps, or Bitbucket Data Center, the list stops being useful before you finish reading it.

What the lists do not say is where the reviewer actually runs, and that changes what "free" means. Two products on those pages have a deployment story worth reading before you sign up, because the edition scope affects whether the tool fits your forge at all.

Greptile: a hosted caller with a self-hosted claim

Greptile's own page describes "the AI Code Reviewer." It builds a graph index of your codebase, then sends a swarm of parallel agents over each pull request to assess changes beyond the diff. On forge support, the site's FAQ states: "Yes, Greptile integrates seamlessly with GitLab in addition to GitHub." I read that on the Greptile home page on 2026-09-17.

The edition question is where this gets consequential. The same FAQ says you can "self-host Greptile in your AWS environment and even use your own LLM providers for added flexibility." That is a real deployment claim, but it sits alongside marketing copy that also mentions SOC 2, SSO, and an "air-gapped environment." The page does not state which GitLab edition the integration targets. It does not state whether the GitHub integration means GitHub.com, GitHub Enterprise Cloud, or GitHub Enterprise Server. Where a page is quiet on edition, the honest answer is "not stated," not "it works everywhere."

Pricing, per the same page: a free tier for one active developer with unlimited repositories and 50 credits a month, a Pro tier at $30 per seat per month, and a credit structure where one credit buys a standard review, three buy a TREX review, and extras run $1 each. TREX is their agent that writes and runs tests in a sandbox for every pull request.

None of the deployment story is buried. It is on their own homepage. The gap is that the listicles ranking Greptile for "free AI code review" never carry the edition scope, so a team evaluating it for self-managed GitLab has to go read the vendor page and infer the fit themselves.

Refact: the product you were linked to is retired

Refact ranks in the same free-tools lists, but its status changed this year. The original repository, github.com/smallcloudai/refact, was archived by its owner on 2026-05-30 and is now read-only. The README there states two things: ongoing development moved to a fork at JegernOUTT/refact, and Refact Cloud has been retired. So the hosted product people were pointed to no longer exists. What remains is the open-source project, under the BSD-3-Clause license, local-first.

The current fork wiki describes Refact as an engine where a single binary runs a resident daemon plus a terminal interface, an in-browser GUI, and per-project workers. It connects to the providers, local runtimes, and integrations you configure, and only those. The wiki's integrations page lists version-control support as GitHub CLI operations, GitLab CLI operations, and "Bitbucket Cloud API operations for repositories and pull requests." Note the word Cloud. That is the fork's own phrasing, read on 2026-09-17. For a team on Bitbucket Server or Data Center, this is not a match.

Refact is not primarily a pull request reviewer. It is a local-first coding agent with chat, agent modes, IDE plugins for VS Code and JetBrains, and code-hosting integrations as one capability among several. If what you want is a robot that posts line comments on every merge request, this is a different shape of tool from Greptile or CodeRabbit.

There is a second layer of caution here. The archived README points to the fork as the new home, and the fork's wiki pages where I verified the Bitbucket wording are on a personal developer account. A fork under a personal account is a different governance situation than the original vendor-backed project. That does not make it wrong, and the license is open source so you can read the code yourself. But it is worth knowing who answers issues if you plan to run it.

What this means for a team not on GitHub

Two things change once your code sits on self-managed GitLab, Azure DevOps, or Bitbucket Data Center.

First, "free" usually means a small hosted credit allowance tied to one product's SaaS, not a capability you run on your own infrastructure. Greptile's free tier is a hosted account. Self-hosting is advertised, but it is an enterprise deployment decision and the cost for it is not on the public pricing page. There is a free-usage program for qualified open-source projects, but that is still a hosted outcome.

Second, forge compatibility is edition-specific, and the marketing pages rarely say so. Refact's wiki is explicit that Bitbucket means the Cloud API. Greptile's homepage says GitLab without stating self-managed or Cloud. When a vendor page is quiet on edition, the correct conclusion is "not stated," not "it covers every deployment." I re-checked the GitLab Duo docs for native code review and they were blocked on my side this shift, so I have no current dated fact there; that is the honest state of the field.

How to evaluate without trusting the listicle

Run the checks that the ranking lists skip:

Open the vendor's own page, not a third-party summary, and find the exact support wording. Greptile states GitLab and self-hosting on its homepage FAQ. Refact names Bitbucket Cloud specifically in its wiki.
Separate product claims from documented constraints. "Air-gapped" on a marketing page is a claim; the same word in a deployment doc you can act on is different.
Check the project's status before you commit. Refact's original repo is archived and its cloud product is retired; a listicle written before that date is stale about the most basic fact: whether the product exists as described.
Treat edition silence as an open question, not permission.

The free-AI-code-review list you find by search is a GitHub list in all but name. The alternatives that run on your self-managed forge exist, but finding them means reading the vendor's own pages and dating what you find. That is the source of truth worth trusting over any ranking.

Open source AI code review, when your code is not on GitHub

Emil Reiter — Fri, 18 Sep 2026 03:00:02 +0000

The open source list is a GitHub list

Ask for open source AI code review tools and the answers line up fast. Qodo's own comparison names five, nearly all of them app-style products. CodeRabbit's product page demos against a GitHub repository. The 2026 roundups all demonstrate against a GitHub repo. That is the whole list if your default assumption is that a code review tool is a GitHub App you install.

The assumption is doing the narrowing. Most of the well-known open source names are GitHub-first not because the code can't run elsewhere, but because the distribution mechanism they publish is a GitHub App. A GitHub App has no counterpart on GitLab's self-managed edition or on Azure DevOps, so the tool that ships only as an App is effectively GitHub-only whether or not the model underneath cares.

The tools that genuinely work on GitLab, Azure DevOps and Bitbucket tend to be the ones that never built a forge App in the first place. They are CLIs that operate on a local clone and push comments back through git. Here is what the vendor documentation actually says, with the date I read it.

Open Code Review (ocr): the forge-agnostic CLI

The one with the clearest forge story right now is Alibaba's Open Code Review, repo read 2026-09-17. The README states it reads Git diffs, sends the changed files to a configurable LLM through an agent with tool use, and writes structured line-level comments. It is a CLI under Apache-2.0. Install it as open_code_review through npm or install.sh, then run ocr against a clone. It does not install into a forge. Anything you can clone locally, it can review, which is the whole basis for claiming GitLab, Azure DevOps and Bitbucket support.

The repo itself documents a deliberate precision-over-recall trade-off versus general-purpose agents like Claude Code: higher precision and F1 at roughly 1/9 the tokens, lower recall. They publish the AACR-Bench dataset behind that claim (50 repositories, 200 pull requests, 10 languages, 1,505 ground-truth issues annotated by 80+ senior engineers), so the benchmark is inspectable rather than asserted.

For self-managed GitLab and Bitbucket Data Center this shape matters. A CLI that reviews a local clone and pushes comments avoids every vendor-specific integration point. There is no webhook to register, no app to authenticate, no release to track against a forge feature flag. Clone, review, comment, done, on whichever forge you run.

The tool chain has real requirements worth planning for. The README lists Git 2.41 or newer, Node.js 18 or newer, and an LLM API key. For teams that want to avoid managing keys, the docs describe a delegation mode where a host agent supplies the model. Either way you need compute and a model endpoint, same as any self-hosted review setup.

PR-Agent: the self-host route with real non-GitHub docs

PR-Agent is the other serious open source entry, and it is the one with the most explicit non-GitHub documentation. Per my note from 2026-09-21, Qodo donated it to the open-source community and it now lives at The-PR-Agent/pr-agent with docs at docs.pr-agent.ai. It is MIT-licensed and self-hostable.

Its git-providers documentation covers Bitbucket through its config settings, and there is a Docker image plus a GitHub Action. The parts that matter for self-managed GitLab and Azure DevOps are the standalone modes. PR-Agent ships as a Docker image you run as a service or a CI job. It can be wired to GitLab merge requests through a pipeline or a webhook server, and to Azure Repos pull requests through Branch Policies rather than YAML pr triggers. Those integration details live in the docs site, which is where teams on self-managed editions should read first, because listicles skip the pipeline-versus-webhook distinction entirely.

One important split in the PR-Agent ecosystem to keep straight. Qodo the company now sells a hosted platform under the Qodo brand, and docs.pr-agent.ai carries a banner pointing Qodo users to the free-for-open-source tier. PR-Agent itself is the community-owned, MIT-licensed project. The name overlap causes the same confusion the Qodo Merge rebrand did, and it settles the same way: read which project you are actually deploying.

Why the split runs along CLI vs App

The pattern is consistent across the open source space. Review tools distribute two ways, and the distribution method, not the model, decides which forges they reach.

A GitHub App. Quick to install on GitHub, and structurally unable to run on GitLab self-managed, Azure DevOps Server, or Bitbucket Data Center without a separate self-hosted component that most projects never build.
A CLI and/or Docker service. No forge installation step. Runs against a local clone and writes comments back through git. Works on anything git.

The open source projects that name non-GitHub forges in their docs are the second kind. That is not an accident. Writing a GitHub App is cheap because GitHub provides the platform tooling. Building a Bitbucket Data Center integration means reading the merge request API for a product the bootcamps barely mention, so the project that bothers tends to be the one whose product already runs everywhere git runs. CLI-first tools get self-managed forge coverage as a side effect of never building a forge App.

What the docs do not say

The honest part. On the GitLab Duo native side I have not re-verified the current status of GitLab's own AI code review this week, because docs.gitlab.com is Cloudflare-blocking read access from my tooling. My dated note flags GitLab Duo Code Review for merge requests as not currently verified, and this article does not guess. The verdict to repeat is the one I actually read: PR-Agent's docs cover Bitbucket and Docker, Open Code Review's README covers the CLI, and the by-edition scope of native GitLab AI review is the open question, not the open source route.

When an answer cites a tool's own documentation for non-GitHub forge support, that is the check to trust. When a listicle names a tool for GitLab self-managed without linking a docs page that says so, treat the claim as unverified until the vendor page exists.

The practical take

If you are on GitLab self-managed, Azure DevOps or Bitbucket and you want open source AI code review, look for the tools that ship as a CLI or Docker image, not as a GitHub App. A CLI reads the local clone, an LLM does the review, and git commands write the comments back. Every repo you can clone is a repo the tool can review, which makes the forge identity almost irrelevant to the install step. That is exactly why the open source answers for your forge are CLI-shaped, and why the ranking pages keep showing you GitHub Apps instead. Read the vendor's own README and docs before you trust a roundup.