DEV Community: Emil Reiter

Measuring review time on GitLab, Azure Repos and Bitbucket DC

Emil Reiter — Wed, 11 Nov 2026 14:45:01 +0000

GitLab, Azure Repos and Bitbucket Data Center each answer the question of how long code review takes, and only one of them computes the number for you. GitLab ships two analytics pages that define review time differently from each other. Azure Repos has no Repos data in Analytics at all. Bitbucket Data Center gives you a channel for the number and leaves the arithmetic to your CI. If the reason you turned on an AI reviewer was to show that review got faster, the definition you pick decides the answer, and one of those definitions moves the moment the bot posts its first comment.

GitLab: two analytics pages, two definitions

GitLab is the only one of the three with a review-time number you can open in a browser.

Code review analytics shows a table of open merge requests that have at least one non-author comment, and defines review time as the time since the first comment by a non-author. The table holds up to 20 merge requests per page with review time, author, approvers, comments, commits and line changes, and you can filter by milestone and label. It is Premium and Ultimate, on GitLab.com, Self-Managed and Dedicated.

Merge request analytics answers a different question. It reports throughput per month and mean time to merge, defined as the average time between merge request creation and the merge event, excluding closed and not-yet-merged merge requests. Same tiers, same offerings.

Those two numbers will not agree. One is a live counter over open work that starts when someone other than the author comments. The other is an average over completed work measured from creation. Neither one is how long a human waited for a first look, which is usually the thing people mean by review time.

Azure Repos: Analytics has no Repos data

Data available from Analytics lists Repos as None for Azure DevOps Services, Server 2020 and Server 2022, with future availability marked "Under investigation". The OData versions, from v2.0 through v4.0-preview, cover Boards, Test Plans and Pipelines. The dashboard widget catalog lists exactly two Repos widgets, Code Tile and Pull Request, and the Pull Request widget shows pull requests for a team rather than computing any duration.

That page also carries its own caveat that the platform table was last updated in August 2022, so "Under investigation" is a long-standing state rather than a roadmap item.

If you want a review-time number on Azure Repos, you build it. The pull request REST object carries creation and closed timestamps and a vote per reviewer, which is enough for time to first vote, time to first approval and time to completion. There is no historical series waiting for you, so you either snapshot on a schedule or reconstruct from the API later. And because that API is versioned per collection, the field you read today is the field you have to keep reading if you want the series to stay comparable.

Bitbucket Data Center: Code Insights is the channel, not the metric

Code Insights is how data reaches a pull request on Bitbucket Data Center. An integration posts a report with a description, a link back to the reporter's URL and up to 6 fields, plus annotations attached to that report. Annotations render on changed lines and only in the unified diff view, not on side-by-side, commit or iterative diffs.

Checks for merging pull requests can then require a report to be present, to pass or fail, or to carry annotations of a given severity, and an annotation only blocks a merge when it sits on a changed line in the diff. Nothing in the product computes review time. Whatever number you want on the pull request, your CI has to calculate and post it as a report field, and the history lives wherever your CI keeps it.

Why the GitLab number moves when you add an AI reviewer

GitLab defines review time as the time since the first comment by a non-author, and includes merge requests that have at least one non-author comment. A review bot posting a summary comment is a non-author, and the docs do not carve bot or service-account comments out of either the inclusion rule or the definition.

The consequence is that enabling an AI reviewer tends to push that number up. Before the bot, the counter started when the first human reviewer commented. With the bot, it starts seconds after the merge request opens, so review time drifts toward the age of the merge request itself. Human latency did not change; the dashboard now reports something worse, because the clock starts earlier.

Mean time to merge is not affected, since it only looks at creation and the merge event. That makes it the more stable headline if your reporting has to survive a change in tooling, at the cost of hiding the difference between waiting for a first look and waiting for a final approval.

The docs do not state whether service accounts are excluded from code review analytics, so check on your own instance before quoting the number anywhere. On a self-managed instance you can inspect the data directly, which is the only way to know whether your reviewer's comments are in the sample.

What to compute if you need a number that holds up

Fix the definition before you turn anything on, and keep it fixed. Pick either time to first human comment or time to merge, and be explicit that they measure different things.

Exclude bot accounts from the first-comment calculation yourself. On GitLab that means filtering by author, because the analytics page will not do it for you.
Use a percentile rather than a mean when a handful of long-running merge requests skew the distribution. Kodus computes its review phase with P75 for that reason, and defines review time as PR opened to PR closed with abandoned pull requests excluded, which sits closer to cycle time than to first-response time.
Snapshot the raw data. Azure Repos Analytics will not keep a review-time series and Bitbucket Data Center will not either, so a query you run in three months will not be able to look back.
Annotate your own chart when the tooling changes. If the number moved because the clock definition changed, that is worth knowing before someone presents it as an improvement.

	Review-time metric	Definition	Where it lives	What you still build
GitLab	Review time per open merge request, plus mean time to merge	Time since first non-author comment; creation to merge	Code review analytics and merge request analytics, Premium and Ultimate, cloud and self-managed	Bot filtering for the first-comment metric
Azure Repos	None for Repos	Not stated	Analytics covers Boards, Test Plans and Pipelines only	REST API snapshots of creation, closed and votes
Bitbucket Data Center	None	Not stated	Code Insights reports, up to 6 fields	CI computes the duration and posts the report field
Kodus	Lead Time Breakdown with coding, pickup and review phases	PR opened to PR closed, P75, abandoned pull requests excluded	Cockpit, paid tier; self-hosted Enterprise also needs the Analytics Worker	Nothing for the metric itself

The Kodus row is the only one of the four where the review phase is a first-class metric rather than something you assemble. The trade-off is scope: Cockpit needs a paid tier, and a licensed self-hosted Enterprise deployment needs the Analytics Worker running alongside the code review worker, so an air-gapped instance that only runs the reviewer will not produce the chart. Data refreshes every 30 minutes by default, which is fine for a trend line and not fine if you want to watch a review land.

First-look versus completion: pick one before you measure

The useful split is between a first-look metric and a completion metric. A first-look number tells you whether work is sitting in a queue, which is what most teams mean by review time. A completion number tells you whether work is leaving the system. AI review can plausibly move the second and mostly does not move the first, since a human still has to read the diff. Claiming a drop in review time without saying which of the two you measured is the quickest way to have the number ignored, or to have someone reconstruct it and find the opposite.

There is also a version of this where the metric is the wrong target entirely. If review time is long because a 4,000-line pull request arrives on Friday, the AI reviewer posting faster comments changes nothing about the human read. Measure first, then decide whether the reviewer is the thing to change.

For the settings that change those numbers rather than the measurement itself, the trigger, scope, draft behavior, blocking and re-review levers are in cutting pull request review time with AI on GitLab, Azure Repos and Bitbucket. For the case where the number looks fine and reviewers still complain, the caps that hide parts of a large diff are in what GitLab, Azure DevOps and Bitbucket hide in large PRs. On Azure DevOps Server rather than Services, the per-tool edition split decides whether a given reviewer exists for you at all, which matters before you invest in building the metric around it.

Reviewing AI-generated code at volume: the ceilings per forge

Emil Reiter — Mon, 09 Nov 2026 01:45:01 +0000

AI code review usually gets evaluated on quality and then deployed into a volume problem. The reviewer that looked sharp on a five-file pull request meets a backlog where an agent opens twelve a day, each one large, each one pushed to three times before it is ready. What breaks first is not the model. It is one of three ceilings that nobody configured deliberately: the forge's API quota, the vendor's review quota, and the reviewer's own trigger cadence.

Those three live in different products, are owned by different people, and fail in ways that look like something else. The forge ceiling looks like an outage. The vendor ceiling looks like the reviewer going quiet. The cadence ceiling looks like a reviewer that stopped noticing new commits. Each one has documented numbers, and for the two self-managed forges the numbers are yours to set.

The forge ceiling comes first, because everything shares it

An AI reviewer is an API client. It reads diffs, posts comments, updates statuses, and every one of those calls draws from the same quota as your pipelines, your scripts, and your dashboards. Volume is what makes that quota visible.

Azure DevOps publishes the clearest numbers, and the behavior is the part worth internalizing. Consumption is measured in Azure DevOps throughput units, an abstract blend of database, compute and storage load. One TSTU is the average load of a typical user over five minutes; the rate limits page puts normal activity at spikes of 10 TSTU or less, larger but less frequent spikes up to 100, and the global limit at 200 TSTU within any sliding five-minute window. A user is delayed when their personal usage exceeds 200 times a typical user in that window, with delays from a few milliseconds up to 30 seconds.

The trap is the response code. A delayed request still returns HTTP 200, with Retry-After and the X-RateLimit-Delay header carrying the delay. A client that treats any 2xx as success records requests that never ran, and a review that silently did not happen looks identical to a review that found nothing. Only sustained overuse produces the unambiguous HTTP 429 with TF400733. If you are building or configuring a bot against Azure Repos, reading X-RateLimit-Remaining and treating a non-zero delay as a failure is the difference between a working integration and a mystery. Note also that the documented remedy for a higher ceiling is an access level, not a setting: the identity your integration uses needs Basic + Test Plans.

Bitbucket Data Center gives you a real lever here. Rate limiting is a token bucket per user, off by default, with defaults of 60 tokens and a refill rate of 5 per second. It applies to HTTP requests using basic or bearer authentication, so REST API calls and Git over HTTP, while Git SSH operations are a separate mechanism. Exhaustion returns 429, records a rate-limited event in the access log, and surfaces in JMX metrics. Two details matter when a bot misbehaves. First, you can give a specific user an exemption, either custom bucket settings or unlimited requests, which is the clean way to stop your reviewer competing with your pipelines for the same bucket. Second, in a cluster every user gets a separate bucket on every node, so a three-node instance gives each user three buckets and the global settings apply to each.

GitLab's forge-side limits are documented per endpoint rather than as a single quota page, and the relevant ones for a review bot are the write endpoints it hammers: notes and comments. Those are the limits to check before blaming the reviewer.

The vendor ceiling: reviews per hour, or credits per month

The second ceiling belongs to whatever reviews your code, and the pricing models are not comparable at face value.

CodeRabbit meters reviews. Its plans page lists per-developer, per-hour rolling allowances: 1 review per hour on Free and that is summarization only, 5 on Essentials, 8 on Team, 10 on Advanced, 12 on Enterprise. Files per review are a separate cap, 5 on Essentials up to 12 on Enterprise, counted after path filters are applied. A team that runs one pull request per developer per day never touches this. A team where an agent opens several pull requests per developer per hour hits it during a normal working morning, and the failure is a review that never starts. Essentials and above can enable usage-based reviews to keep processing past the allowance, with the caveat that pull requests above 300 files are not supported through usage pricing at all, and that the Fair Usage Limits Policy lets availability adjust under sustained high volume.

GitLab meters credits instead. GitLab Credits are the consumption currency, with included credits allocated per user per month and no rollover, a shared monthly commitment pool, and on-demand usage at $1 per credit once everything else is spent. The detail that decides how a volume spike lands: a flow that runs as a service account with composite identity is billed to the namespace, not to the user who started it. Code Review Flow is one of those. So a busy team draws from the namespace pool rather than from individual allowances, which is a simpler model to reason about and a worse one to attribute, since you cannot reserve part of the pool for a subset of users. Usage caps on the dashboard are the available control. On the Free tier, on-demand usage is capped at $25,000 per calendar month and switches off automatically when it is reached.

The self-managed split is the one that catches teams mid-deployment. GitLab Duo Core arrives automatically with Premium or Ultimate on 18.0 and later, but it is not available on GitLab Duo Self-Hosted under an offline license, because Core needs a connection to the GitLab AI Gateway. If you want self-hosted models on an air-gapped instance, the Agent Platform Self-Hosted add-on is the path, and it is billed as a flat fee under an Enterprise License Agreement rather than by usage, which makes the cost predictable and the capacity commitment real.

Azure Repos Copilot code review meters nothing in the same way. Billing runs through Azure Cost Management on an Azure subscription linked to the organization, and the volume lever is the review effort level, set per project with optional per-repository override, where higher effort consumes more tokens and increases cost. Users can pick a different effort for a single review. That makes cost a per-review decision rather than a plan limit, which suits teams that want to spend effort where it matters and not on every agent-generated pull request.

Kodus sits at the other end of that spectrum: reviews are unlimited on every plan because it runs on your own model key. The free Community tier is self-hosted or cloud with up to 10 Kody Rules and 3 plugins, Teams is $10 per active developer per month on cloud, and Enterprise is custom with self-hosting. The ceiling is technical rather than commercial, at 2,000 changed files, past which the pull request is not reviewed.

What is metered	Model	Where the volume bites
Azure DevOps forge API	TSTU, 200 per sliding 5-minute window, delays up to 30s	Bot API calls share the quota with pipelines; delays return HTTP 200
Bitbucket DC forge API	Token bucket per user, 60 size / 5 per second, off by default	Cluster gives each user a separate bucket per node; exemptions are per user
CodeRabbit	5-12 reviews per developer per hour, 5-12 files per review	Sustained bursts exhaust a rolling hourly allowance; no usage pricing above 300 files
GitLab	Credits: included per user, then shared pool, then $1 per credit	Code Review Flow bills the namespace, so a team spike drains a shared pool
Azure Repos Copilot	Azure subscription via Cost Management, effort level per review	Cost scales with effort and frequency, not with a plan limit
Kodus	Nothing per review; BYOK token cost to your provider	Hard stop at 2,000 changed files per pull request

The cadence ceiling: how many times one pull request gets reviewed

The third ceiling is internal to the reviewer, and it is the one teams most often discover by accident.

Kodus documents its trigger model explicitly. The review flow runs on pull request open, on new commits, or on a @kody start-review comment, and it skips when there are no new commits since the last run, when the changes are merge-only, when every changed file matches an ignore pattern, when the file limit is exceeded, or when the pull request is in draft mode and configured to skip drafts. The cadence setting is the volume control: automatic reviews every push, auto-pause during rapid consecutive pushes with a default of 3 pushes in 15 minutes, or manual only. A force re-run is available with @kody review --force, which matters because a plain start-review will skip again if there is nothing new.

CodeRabbit has an equivalent default that behaves the same way without being set. auto_pause_after_reviewed_commits defaults to 5, so incremental reviews pause after five reviewed commits. On a pull request that an agent pushes to eight times, the last three pushes get no review, and nothing on the pull request says so. Combined with the per-developer hourly allowance, that is two independent limits that both express themselves as silence.

The consequence is that the useful question about a review setup is not how good the findings are. It is how many reviews per pull request you are actually buying, and whether the answer is the one you assumed.

What to set before volume arrives

The ordering matters, because the ceilings interact.

Raise the forge ceiling first, since it is the only one that takes down things other than your reviewer. On Bitbucket Data Center that means turning rate limiting on deliberately and giving the review bot an exemption, rather than leaving it off and discovering the problem when someone enables it. On Azure Repos it means reading the delay headers in whatever integrates, because the 200 response will not tell you.

Then decide whether your reviewer is metered by reviews or by credits, because the failure looks different. A metered-by-review allowance runs out mid-morning and comes back on a rolling window; a credit pool drains and needs a purchase or an on-demand acceptance. Both are visible in advance if you look at the numbers rather than at the pull request.

Then set the cadence to match how your team actually pushes. Auto-pause defaults exist because reviewers that comment on every push generate noise, and a reviewer nobody reads is the same as no reviewer. For teams running agents that push frequently, reviewing once on open and once when the pull request is marked ready is usually a better use of the same budget than reviewing every intermediate push, and it sidesteps the cadence pause entirely.

FAQ

Why does AI code review stop working when pull request volume goes up?

Because three separate ceilings exist, and each fails differently. The forge throttles API calls, the vendor caps how many reviews you get, and the reviewer's own trigger cadence decides how many times it runs on a single pull request. Adding a reviewer multiplies load against the forge ceiling it already shares with your pipelines.

Who pays for a GitLab Code Review Flow run?

The namespace, not the person who started it. Foundational flows like Code Review Flow run as a service account with composite identity, so the usage is billed to the namespace and draws from the monthly commitment pool and then on-demand credits, at $1 per credit.

Does Azure DevOps return an error when it delays a request?

No. A delayed request still returns HTTP 200 with Retry-After and the X-RateLimit headers set. A client that logs success on any 2xx records requests that never ran, and the delay ranges from a few milliseconds up to 30 seconds.

What is a TSTU on Azure DevOps?

An Azure DevOps throughput unit, an abstract measure of load blending database, compute and storage consumption. One TSTU is the average load of a typical user over five minutes, normal activity produces spikes of 10 TSTU or less, and the global limit is 200 TSTU in any sliding five-minute window.

Is Bitbucket Data Center's rate limiting per instance or per user?

Per user, using a token bucket. Defaults are a bucket size of 60 requests and a refill rate of 5 per second, applied to HTTP requests with basic or bearer authentication such as REST API calls. In a cluster, each user gets a separate bucket on each node.

AI code review on Azure DevOps: Services vs Server, per tool

Emil Reiter — Wed, 04 Nov 2026 14:45:01 +0000

Azure Repos ships in two editions, and the AI review options are not the same in both. Microsoft's Copilot code review is documented for Azure DevOps Services and carries a limited preview label. Azure DevOps Server has no Microsoft-native reviewer at all, so a Server team runs PR-Agent from a pipeline, points a vendor webhook at Service Hooks, or self-hosts something. Which edition you are on decides the setup work, the permissions you need, and where the reviewer reads your coding standards from.

That last part is where most rollouts go sideways, so it is worth walking through the routes one at a time.

Copilot code review is Azure DevOps Services only

The get started page is headed Azure DevOps Services, and the feature is in limited preview: no service level agreement, and functionality can change or be removed. Prerequisites are an Azure DevOps organization, a Git repository in Azure Repos (TFVC is not supported), and an Azure subscription linked to the organization, because usage bills through Azure Cost Management instead of through seats.

Enablement cascades across scopes. A Project Collection Administrator turns the feature on at the organization level and can enable it for every project at once. A Project Administrator scopes it to specific projects, and a repository owner enables it per repository when project settings allow overrides. Individual users opt in through Preview features unless an administrator has already enabled the preview for everyone.

Automatic reviews are a separate switch from enablement. Copilot reviews pull requests on its own only where you add a branch policy on the target branch. Without that policy, someone has to add Copilot as a reviewer by hand on each pull request, which is fine for a pilot and not fine for a team. The default review effort is set at project or repository level, and higher effort consumes more tokens, so the effort setting is also a cost setting.

For a Server install, none of this exists.

Where Copilot reads your team's rules, and the target-branch catch

Copilot takes instructions at the organization and project level through Azure DevOps settings, and at the repository level through a file. The instructions page accepts two paths for that file: .github/copilot-instructions.md or .azuredevops/copilot-instructions.md, both at the repository root. Path-scoped files go in .github/instructions/ or .azuredevops/instructions/ as *.instructions.md, with YAML front matter carrying an applyTo value.

A path-scoped file without applyTo is skipped. Nothing errors, the file is committed, and reviews keep running without it. If you have a rules file that seems to have no effect, that front matter value is the first thing to check.

The catch that changes how you roll standards out is which branch the instructions come from. Repository-level and path-scoped files are read from the pull request's target branch only. A pull request that adds or edits the instructions file is not reviewed against the new text. Those rules apply after the change merges into the target branch. If you are introducing a standard, land the file on the default branch first, then let the later pull requests pick it up.

When instructions exist at several scopes, Copilot uses all applicable ones during a review. The docs do not promise a precedence order for an organization rule that contradicts a repository rule, so that is a conflict to avoid rather than resolve.

What runs on Azure DevOps Server instead

On the server edition the choice is between self-hosted tools and hosted vendors that reach into your instance.

PR-Agent lists Azure DevOps as a supported git provider, and the support matrix lists an Azure DevOps pipeline as supported usage. A Server team can run it as a pipeline job or behind a webhook. It is community-owned and MIT licensed, review categories and prompts live in configuration files you own, and the matrix lists repo context files such as AGENTS.md. One caveat to note before you plan around its help tooling: /help_docs has been disabled since v0.36.1 pending a fix for a credential-exposure issue.

Open Code Review from Alibaba is a different shape. It installs from npm as ocr, works on a git diff, a commit range, or a whole-file scan, and needs an LLM endpoint rather than a forge integration. On a firewalled Server install that is convenient, and it also means the tool does not post comments to a pull request by itself unless you wire that up. Its published benchmark is the project's own, built from 50 repositories and 200 pull requests with engineer-annotated issues, and it reports higher precision than a general-purpose agent on the same model at roughly a ninth of the tokens, with lower recall as a stated trade-off. Treat it as the project's number, not a third-party measurement.

Kodus connects to Azure DevOps with a Personal Access Token and documents no OAuth path for that provider, unlike GitHub and GitLab. The PAT scopes the docs list are Analytics Read, Code Read & Write, Graph Read, Identities and Groups Read, Project and Team Read, and User Profile Read, with Code write access being the one that lets it post comments. If the connection succeeds but nothing appears on new pull requests, the PAT scopes are the first thing the troubleshooting page points at.

One Azure-specific detail matters if you self-host it: the Azure Repos webhook URL has to carry an encrypted token query parameter, derived by encrypting CODE_MANAGEMENT_WEBHOOK_TOKEN with CODE_MANAGEMENT_SECRET using AES-256-CBC. Requests without it get a 403. The webhook page also notes the URL has to reach the webhooks service on port 3332, or your reverse proxy has to route the webhook path there. And on rules, Kody reads coding-agent instruction files including .github/copilot-instructions.md and .github/instructions/**/*.instructions.md; the .azuredevops/ paths are not in that list, so a team standardizing on the Azure-native path should know which tools will read it.

Do the hosted vendors document Azure DevOps Server?

Less clearly than you would want, and the difference matters.

CodeRabbit's Azure DevOps page covers a PAT or a Microsoft Entra service principal, Project Administrator or Project Collection Administrator rights, and the Edit Subscriptions permission on Service Hooks so the webhook can be installed. It notes that permission cannot currently be granted through the UI and that it is granted per project, which becomes real work across a large organization. The page does not split Azure DevOps Services from Azure DevOps Server, so it does not establish Server support on its own.

Qodo's on-premises Azure DevOps guide walks through a Microsoft Entra app registration, a service account added to the organization with Basic access and Project Administrators, and a Service Hooks webhook subscribed to PR Created, PR Updated, PR Commented and PR Merged. Those steps assume dev.azure.com and Entra ID, which are Azure DevOps Services constructs. The deployment matrix separately marks on-prem as unsupported for Azure DevOps Cloud. Read together, the guide covers running Qodo on-premises against Azure DevOps Services. It does not document an Azure DevOps Server install.

Comparison table

Route	Azure DevOps Services	Azure DevOps Server	Where rules come from	Where the review runs
Copilot code review	Yes, limited preview	Not documented	Org and project settings, `.github/` or `.azuredevops/` instruction files	Azure Pipelines agent pool
CodeRabbit	Documented (Entra service principal or PAT)	Not stated	Web UI and repository config files	CodeRabbit cloud, via Service Hooks
Qodo on-premises	Documented through Entra ID and Service Hooks	Not documented	Repository config and PR commands	Your Qodo environment
PR-Agent	Supported provider, pipeline or webhook	Supported provider, pipeline or webhook	JSON config, prompt files, `AGENTS.md`	Your pipeline, CLI, or webhook server
Open Code Review	CLI on a git checkout	CLI on a git checkout	Path-scoped review rules	Wherever you run the CLI
Kodus	Documented, token auth	Not stated	Kody Rules plus detected repository rule files	Kodus self-hosted or cloud

Every cell reflects the vendor or project page linked above. Where a cell says not documented or not stated, the page I read does not cover that edition, and that gap is the thing to verify before you commit. The wider edition coverage comparison across all three forges covers the same question for GitLab Self-Managed and Bitbucket Data Center.

Which route fits which team

On Azure DevOps Services, Copilot code review is the shortest path to a first automated review. An administrator turns it on at the organization level, billing runs through a subscription you already have, and reviewers appear on pull requests without a webhook to maintain. What you accept in return is the preview status, the missing precedence order when instructions conflict, and the target-branch rule for instruction files. If your standard is that a reviewer must apply a rules file changed inside the same pull request, Copilot will not do that, and you want a tool that reads the rule at review time.

On Azure DevOps Server the choice is between PR-Agent and a self-hosted product. PR-Agent is the lower-commitment option: MIT, no vendor account, configuration stored in files in your repository, and a documented pipeline trigger. What you pay for it is operational work, since you own the pipeline, the model key and the webhook endpoint. A UI for managing rules, or metrics on what the reviewer found over time, is where a product like Kodus starts to make sense, and the price of that is running the service yourself, including the webhook token and the port exposure above.

The cheapest test before committing to any of them is one pull request. Put a single rule in the file that route reads, open a pull request that breaks the rule, and see which reviewers flag it. On Azure Repos, the file that reaches the most reviewers is .github/copilot-instructions.md, because Copilot reads it and Kody detects it among its supported patterns. If your repository already speaks .azuredevops/, keep both paths in sync or the tools will end up reviewing against different standards.

FAQ

Is Copilot code review available on Azure DevOps Server?

No. Microsoft documents it for Azure DevOps Services, and the documentation is headed for that edition. Server teams run a self-hosted reviewer such as PR-Agent, or wire a vendor integration into Service Hooks.

Where does Copilot code review read custom instructions from?

Organization and project settings, repository files at .github/copilot-instructions.md or .azuredevops/copilot-instructions.md, and path-scoped *.instructions.md files carrying an applyTo value. Repository-level and path-scoped files are read from the pull request's target branch, so a change to them applies after it merges.

Can CodeRabbit or Qodo review Azure DevOps Server pull requests?

Neither vendor page establishes Server support. CodeRabbit documents an Azure DevOps integration through a PAT or an Entra service principal, and Qodo's on-premises guide uses dev.azure.com and Entra ID, which are Azure DevOps Services constructs.

Open source AI code review on GitLab, Azure Repos, Bitbucket DC

Emil Reiter — Mon, 02 Nov 2026 01:30:04 +0000

If your forge is GitLab Self-Managed, Azure Repos, or Bitbucket Data Center, there are two open source AI code review projects that will run inside infrastructure you control: PR-Agent and Kodus. Everything else with a self-hosted option is a commercial product attached to a contract and a seat floor, which is a different kind of purchase.

Both of them review pull requests on all three forges, both let you point the model layer at a provider you already pay, and both can run with no outbound internet if you host the model too. What separates them is the license and which features survive on each provider.

License and provider coverage are separate questions

A tool can be free to self-host without being open source. CodeRabbit's self-hosted deployment ships as a container image you run in your own environment, and it is scoped to the Enterprise plan, with the docs putting the entry point at 500 or more user seats. That is a reasonable product to sell, and it is a procurement conversation rather than a git clone. The reverse also happens, where a permissively licensed project cannot do a specific thing on your forge because the provider API does not expose the hook that feature needs.

So the questions that matter for a self-managed team are what the license permits and what the tool can actually do on your forge.

PR-Agent is MIT, and the license is held by the project

The PR-Agent repository carries an MIT license held by the project itself, not by a vendor, and the README states plainly that this is a community-owned project Qodo donated and that it is separate from Qodo's commercial product. That distinction matters when you are choosing something to run for the next three years: the license cannot be re-scoped by a company that later changes direction.

The most useful document in this whole space is the supported platforms matrix, because it lists where features differ per provider instead of claiming uniform support. Describe, Review, Improve, Ask, Add Docs, and Help work on GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea. Ask on code lines works on GitHub, GitLab, and Bitbucket only. Similar Issues is GitHub only. Update CHANGELOG runs everywhere but posts as a pull request comment on Bitbucket, Azure DevOps, and Gitea, because those providers cannot push files through the API path the tool uses. Generate Labels on Gitea is marked as not yet verified.

That matrix is the reason to check before you assume. A team on Azure Repos that wants comment-anchored questions is asking for something the project does not list as supported there. The deployment paths for the non-GitHub forges are covered in PR-Agent on GitLab, Azure DevOps and Bitbucket.

One upgrade detail catches people out: Docker images from 0.34.2 onward are published under the pragent/pr-agent namespace, and the older codiumai/pr-agent namespace is a frozen archive with no new pushes. Any pinned image reference needs updating before you move versions.

Kodus splits its license between AGPL-3.0 and an enterprise file license

Kodus is open source in a way that needs one clarification, because the license is split by file rather than applied to the whole repository. Filenames containing .ee. and everything under an ee/ directory fall under the Kodus Enterprise Code License; the rest of the source is AGPL-3.0.

That enterprise license grants Community users the right to run the unmodified enterprise code as needed to operate Community features, including code review and BYOK model providers, in a self-hosted deployment for internal purposes, production included, within the limits the software enforces. It does not grant the right to modify that code, to bypass the Community limits, or to use Enterprise-only features. Offering Kodus as a hosted or managed service to third parties is not internal use, so a team planning to resell it is outside the grant.

The Community limits are specific rather than vague. The pricing documentation puts Community at up to 10 Kody Rules and up to 3 active plugins, with reviews unlimited on every plan because the model calls run on your own key and Kodus does not mark up tokens. Teams is 10 dollars per active developer per month, cloud only, and Enterprise is contract-priced. The published hard cap is that pull requests with more than 2,000 changed files are not reviewed, which is the kind of limit that only shows up on generated-code branches.

The repository README gives the self-hosting floor as Docker on a VM you control, with at least 2 CPU cores, 8 GB of RAM, and 60 GB of free disk. It names self-managed GitLab and Forgejo as the on-premises forges it connects to, and lists GitHub, GitLab, Bitbucket, Azure DevOps, and Forgejo for pull request reviews. Self-hosted instances send one anonymous heartbeat per day carrying aggregated counters with no code, names, or identifiers, and KODUS_TELEMETRY_DISABLED=true turns it off.

The commercial self-hosted tier, and where the seat floor bites

CodeRabbit's self-hosted option runs the review agent in your infrastructure, with the platform integration connecting through a service account or app, and a reverse tunnel for platforms that cannot accept inbound connections. The supported platform list covers GitHub Enterprise Server, GitLab self-managed, Azure DevOps, and Bitbucket Data Center. The docs scope the whole thing to Enterprise customers with 500 or more user seats, which is the number to bring to a budget conversation before you evaluate the product at all.

Qodo's deployment model table is the page to read if air-gapping is on your requirements list. On-premises and air-gapped deployments are documented for GitHub Enterprise, GitLab Self-Managed, Bitbucket Data Center, and Gerrit. Bitbucket Cloud and Azure DevOps Cloud are listed as multi-tenant and single-tenant only, with on-premises marked unavailable, and Azure DevOps has no on-premises entry in that table at all.

For a team on Azure DevOps Server that is the deciding line, since there is no documented Qodo on-premises path for Azure DevOps. The wider per-tool picture across Services and Server is worth reading in full, and it is laid out in AI code review on Azure DevOps Services vs Server, per tool.

Feature coverage across the options

	PR-Agent	Kodus	CodeRabbit self-hosted	Qodo on-prem
License	MIT, held by the project	AGPL-3.0 core, enterprise-licensed `.ee.` files	Proprietary	Proprietary
Self-hosted path	CLI, Docker, webhook, CI pipeline	Docker on a VM you control	Container image, Enterprise plan only	Contract, per provider
GitLab Self-Managed	Yes	Yes	Yes	Yes, air-gapped documented
Azure Repos	Yes per the provider matrix (Services and Server not split)	Yes, provider list does not split editions	Listed as Azure DevOps, edition not qualified	Cloud only, no on-premises entry
Bitbucket Data Center	Yes	Yes	Yes	Yes, air-gapped documented
Air-gapped	Yes, with a self-hosted model	Yes, with a self-hosted model	Private-network option via reverse tunnel	Documented for GitHub Enterprise, GitLab SM, Bitbucket DC, Gerrit
Cost	None	Community free, Teams 10 dollars per active dev per month	Enterprise contract	Contract
Documented limits	Per-provider feature gaps in the matrix	10 Kody Rules and 3 plugins on Community, 2,000 changed files	500+ user seats	Not stated in the deployment table

Neither PR-Agent nor Kodus splits Azure DevOps Services from Azure DevOps Server in its provider list, so if you run Server, treat the Azure DevOps row as needing a direct test rather than a documentation check.

What GitLab ships itself, and what running it offline takes

GitLab's own AI review is Duo, and which feature runs depends on the seat. A user holding a GitLab Duo Enterprise seat gets GitLab Duo Code Review, which is single-pass and scoped to the merge request and its file diffs. Everyone else gets Code Review Flow, which needs no add-on but consumes GitLab Credits, and a group Owner can configure all reviews to use Code Review Flow regardless of seat type. The routing table is in the GitLab Duo in merge requests documentation.

Running that offline is a separate project with its own prerequisites. Offline flow execution needs GitLab 18.9 or later, and the setup requires an opt-out exemption of cloud licensing arranged before purchase, which means it is a sales conversation and not a config flag. You then move the AI Gateway image, the Agent Platform Flows executor image, the vLLM inference server image, and the model weights to the internal registry and filesystem by hand, roughly 0.6 GiB, 0.5 GiB, and 9 GiB compressed before the weights, per the offline deployment documentation. The self-managed angle where review policy comes from your team instead of a vendor default is covered in GitLab Self-Managed AI review that follows your own rules.

Which of these fits your team

If forking and modifying the reviewer matters to you, PR-Agent is the only option in this set that grants it, and you accept the per-provider gaps its matrix documents instead of discovering them during rollout. The cost is operational: you run it, you own the model routing, and you own the upgrades.

If the part you care about is review policy your team writes in plain language, plus delivery metrics and a dashboard, Kodus covers the same forges with a self-hosting floor you can size from the README, and the trade-off moves from licensing to the Community limits on rules and plugins. A team that wants more than 10 rules is looking at a per-developer fee rather than a fork.

If the constraint is that nothing leaves the network, the open source pair is the practical field for Bitbucket Data Center and GitLab Self-Managed, and it is the only field for Azure DevOps Server. Commercial self-hosting starts with an Enterprise contract and a seat threshold, and Qodo's own table does not list Azure DevOps on-premises. That is a narrow field, but it is a real one, and the difference between the two options comes down to whether you want to operate a CLI-and-webhook tool you can modify or a self-hosted service with a rule layer and a UI.

FAQ

Are there open source AI code review tools that work on GitLab Self-Managed and Azure Repos?

Yes. PR-Agent (MIT) and Kodus (AGPL-3.0 core) both review pull requests on GitLab, Bitbucket, and Azure DevOps, and both can be self-hosted. PR-Agent documents which features differ per provider in its supported platforms matrix; Kodus publishes its Community limits and self-hosting requirements in its docs.

Is Kodus fully open source?

The license is split by file. Files containing .ee. in the name and everything under an ee/ directory fall under the Kodus Enterprise Code License; the rest of the source is AGPL-3.0. Community users may run the unmodified enterprise code for internal use, including production, within the limits the software enforces, but may not modify it or use Enterprise-only features.

Can CodeRabbit be self-hosted without an Enterprise contract?

No. CodeRabbit's self-hosted deployment is documented as an Enterprise plan feature, and the docs state it is available to customers with 500 or more user seats.

Is there an on-premises Qodo deployment for Azure DevOps?

Qodo's deployment model table lists on-premises and air-gapped support for GitHub Enterprise, GitLab Self-Managed, Bitbucket Data Center, and Gerrit. Bitbucket Cloud and Azure DevOps Cloud are listed as multi-tenant and single-tenant only, and the table has no on-premises entry for Azure DevOps.

Cutting pull request review time with AI: GitLab, Azure Repos, Bitbucket

Emil Reiter — Wed, 28 Oct 2026 11:15:01 +0000

Reducing review time with an AI reviewer is mostly not about the model. It is about six configuration decisions, and each of the three forges on this beat implements them differently. On GitLab both code review features run on GitLab.com, Self-Managed and Dedicated, but they are gated by different add-ons. On Azure Repos Copilot code review runs on Services only, in limited preview, and requires Azure Pipelines. Bitbucket Data Center has no native AI reviewer at all, so review time is set by merge checks and whatever bot you wire in through the REST API.

The levers are the same everywhere. When the review starts, which files it reads, whether it runs on a draft, whether a finding actually blocks the merge, whether a new push triggers a new review, and how much effort each review is allowed to spend. Below is what each forge documents for those six, and where the defaults work against you.

The six levers that set review latency

An AI reviewer adds a step to a workflow that already has a human bottleneck, so the useful question is whether it removes more waiting than it adds. That depends on these:

Trigger: on every push, on PR creation, or only when someone asks.
Scope: which files get reviewed and which are skipped, including how large diffs are handled.
Draft behavior: whether a review runs, or a gate silently disappears, before the PR is marked ready.
Blocking: whether a finding stops the merge or is only a comment.
Re-review: whether new commits get a fresh review and whether the bot remembers what it already said.
Effort and cost: how much the reviewer is allowed to think, and who pays for it.

Those six are also where most "we turned on AI review and nothing got faster" reports come from. A review that runs but does not block anything is a comment feed. A gate that disappears on drafts is not a gate. A reviewer with no scoping reviews lock files and generated code forever.

GitLab: two review features, two add-on paths

GitLab runs one of two code review features depending on your add-on and group settings. The non-agentic one is GitLab Duo Code Review, which requires the GitLab Duo Enterprise add-on and is Premium/Ultimate. The agentic one is Code Review Flow, part of the GitLab Duo Agent Platform, available on Free, Premium and Ultimate and paid for with GitLab Credits.

Which one runs is decided by the seat of the user who initiates the review. If that user holds a Duo Enterprise seat, GitLab runs the non-agentic feature by default, because it does not consume GitLab Credits. A group Owner can override that and route all reviews through Code Review Flow. Both features can run in the same project, which is worth knowing before you assume everyone on the team gets the same reviewer.

The self-managed detail that decides whether any of this is usable: Code Review Flow runs as a CI/CD job and needs a runner with the gitlab--duo tag and an executor that supports Docker images, or GitLab hosted runners enabled for the project. On an air-gapped instance with no such runner, the flow has nowhere to execute. The non-agentic feature does not have that requirement, but it does depend on the AI Gateway request timeout, and reviews that do not finish in that window surface as a generic error.

For triggering, automatic reviews are a project setting since 18.0. Group and instance level automatic reviews arrived in 18.4 behind the cascading_auto_duo_code_review_settings flag, which was removed in 18.7. GitLab skips draft merge requests, merge requests with no changes, and anything matching your exclusion rules. Code Review Flow also has a Start a new review on push option, and its follow-up reviews use earlier Duo threads and replies to judge the new changes.

The blocking lever on GitLab is the weakest of the three. A user's request for changes blocks a merge on Premium and Ultimate, and a bot can bypass it. GitLab Duo approving or requesting changes is beta in 19.5 behind duo_code_review_decisions, disabled by default, and a Duo approval does not count toward required approvals. If you want an AI reviewer to hold a merge, the reliable path is a required external status check with Status checks must succeed turned on, which is a separate setting from the check itself.

For teams on self-managed GitLab with their own rules, that combination is the one worth testing: a required status check for the gate, plus review instructions scoped to the project so the reviewer follows your standards instead of generic advice. I wrote about the add-on paths and rule scoping separately in AI review on self-managed GitLab that follows your own rules.

On large merge requests, GitLab Duo Code Review sends the diffs plus the original contents of changed files, and if that request fails it retries without the file contents. The retry shrinks the prompt and also shrinks the context, so comments can be less specific. If the retry fails too, you get a generic error message. Splitting large merge requests and excluding irrelevant files is the documented mitigation. I covered the general problem in what GitLab, Azure DevOps and Bitbucket hide in large PRs.

Azure Repos: Copilot code review is Services-only and preview-gated

GitHub Copilot code review for Azure Repos is in limited preview and applies to Azure DevOps Services. A Project Collection Administrator enables it for the organization, a Project Administrator manages project defaults, and a repository owner turns it on per repository. Individual users also opt in through Preview features unless an administrator enables it for everyone.

Two constraints change the plan more than anything else in that page. Copilot code review requires Azure Pipelines, and self-hosted agent pools and Managed DevOps Pools are not supported. For a team whose pipelines run entirely on self-hosted agents, the feature is not a smaller version of itself, it is unavailable. The second is that automatic review is not part of enablement. It is a separate branch policy, Automatically request Copilot code review, that you set per target branch. Enabling the feature makes it available; the policy is what makes it run without a manual request.

Effort is a per-project default that repository admins can override when the project allows it, and higher effort consumes more tokens and costs more. That is a reasonable place to start a review-time experiment: leave the default low on most repositories, raise it where the diffs are riskier, and compare against what the pipeline costs you in wall-clock time.

The draft-PR behavior on Azure Repos deserves its own look because it affects every gate, not just the AI one. A draft pull request suppresses build validation policies so they do not run automatically, disables voting, and does not auto-add required reviewers. Publishing the PR assigns reviewers and evaluates policies. Marking a published PR as a draft removes all existing votes. So a PR that sits in draft while someone iterates looks unblocked, and any gate you wired to build validation or a required reviewer is simply absent until the PR is published.

Once a PR is published, Azure Repos gives you a policy model with a real blocking lever: a status check policy that a bot can post to, plus the minimum reviewer and build validation policies. If you are wiring an AI reviewer into that model, the status check policy is the piece that actually gates the merge, and the build expiration setting (Immediately, After n hours, or Never) decides how stale a passing build is allowed to get before it stops counting.

For Azure DevOps Server, none of the above applies. Copilot code review is a Services feature, so a Server team looking to cut review time is choosing between third-party tools and their own pipeline job.

Bitbucket Data Center: the gate and the finding are the same object

Bitbucket Data Center has no native AI reviewer, so the review-time question becomes which merge checks you enforce and what you post into Code Insights. Merge checks are set at Project settings > Merge checks and inherited by repositories, with repository admins able to override unless a project admin has restricted repository-level customization (available from Bitbucket 8.10, and restricting it deletes any saved repository-level settings for that check). Minimum approvals and default reviewers are separate checks and both must be met.

The Code Insights merge check is where an AI reviewer gets to block a merge, and its scope is narrow in a way that matters. Annotations only block merging if they are on the diff. An annotation placed on a changed file outside the changed lines, or on a file that did not change, will not block anything. So the same finding can gate the merge or be invisible to the gate depending on where the line anchor lands. This is the opposite of Azure Repos and GitLab, where the finding surface and the gate are two different objects that you connect.

The other Code Insights constraints are operational. Annotations display only on lines changed in the unified diff, so they are absent in side-by-side, commit, and iterative diff views. A rerun must delete the previous annotations first, because there is no de-duplication, and posting more than 1,000 annotations rejects the whole request. A reviewer that re-posts the same findings on every push will eventually hit one of those limits rather than a merge check.

Bitbucket Data Center is also the one forge of the three that lets you ask for the delta. Its changes resource accepts changeScope=UNREVIEWED, which uses a per-user last reviewed commit, so a reviewer can fetch only what changed since that user last looked. Azure Repos tracks something similar through changeTrackingId and firstComparingIteration, and GitLab does not have a cross-version diff API, so the delta there comes from the repository compare endpoint.

What third-party reviewers document for these forges

If you want a native reviewer on Bitbucket Data Center, or a self-hosted one on Azure DevOps Server, the options are third-party tools, and their docs are the only honest source for what they support.

CodeRabbit documents self-hosted deployment as Enterprise-only, for customers with 500 or more user seats, running the review agent as a container inside your infrastructure with a bring-your-own-model setup. The supported platforms listed are GitHub Enterprise Server, GitLab self-managed, Azure DevOps and Bitbucket Data Center. Deployment and configuration instructions are provided during onboarding rather than published. For scope, it uses path filters and path instructions, where exclusions win over includes regardless of order, and there is an Azure DevOps-specific caveat: repository inventory and diff hydration apply the default ignored paths directly rather than through your configured filters, so an override does not take effect on those two paths.

Qodo documents an on-premises deployment on Kubernetes, with integrations for GitLab Server, Bitbucket Data Center, Azure DevOps and Gerrit. Cloud-hosted Git instances use a separate install path.

Kodus is open source and self-hostable with your own model keys, running on Docker on a VM you control (2 CPU cores, 8 GB RAM, 60 GB disk minimum) or as a hosted service. It reviews pull requests on GitLab, Bitbucket, Azure DevOps and GitHub, including self-managed GitLab, and its Kody Rules are written in plain language and scoped to an organization, repository, path or review scope, which is the lever that maps to the scope row in the table below. The CLI can review a working tree, staged diff, branch or commit, so a pre-push review does not need a pull request to exist. The trade-off sits in the plan split: the Community tier caps Kody Rules at 10 and active plugins at 3, so teams that want many scoped rule sets or integrations are choosing between paying and trimming the ruleset.

	GitLab	Azure Repos	Bitbucket Data Center
Native AI reviewer	Duo Code Review (Duo Enterprise add-on) or Code Review Flow (GitLab Credits)	Copilot code review, limited preview	None
Edition scope	GitLab.com, Self-Managed, Dedicated	Services only	n/a
Automatic review	Project setting since 18.0; group/instance 18.4+	Separate branch policy per target branch	n/a
Self-hosted execution	Code Review Flow needs a runner with the `gitlab--duo` tag	Requires Azure Pipelines; self-hosted agent pools not supported	n/a
Draft PR behavior	Skipped by automatic reviews	Suppresses build validation, disables voting, no auto reviewers	n/a
Blocking a merge	Request changes (Premium/Ultimate, bypassable); Duo decisions beta in 19.5	Status check policy, build validation, minimum reviewers	Merge checks; Code Insights blocks only on-diff annotations
Re-review on push	"Start a new review on push"; follow-up reviews reuse earlier threads	New policy evaluation per push	`changeScope=UNREVIEWED` via last reviewed commit
Effort or cost control	Model selection per feature; GitLab Credits	Default effort level per project/repo	n/a

What this means when you are picking levers

Two of these three forges let you build a real gate for an AI reviewer, and one makes it awkward. On Azure Repos the status check policy is a first-class blocking object and the draft-PR behavior is the thing most likely to surprise you, because a gate you configured can be absent without any error. On GitLab the gate exists but the AI reviewer's own approval does not count toward required approvals, so the check that holds the merge is the status check, not the bot's verdict. On Bitbucket Data Center the finding and the gate are the same object, which is simpler to reason about and much more sensitive to where a line anchor lands.

If you are on Bitbucket Data Center or Azure DevOps Server, no native option is on the table, and the honest comparison is between CodeRabbit's Enterprise-only self-hosted path, Qodo's Kubernetes deployment, and Kodus's open-source self-hosting with your own keys. Those are different shapes of commitment: a seat threshold, a Kubernetes platform, or a VM and a ruleset budget. Which one fits depends less on review quality than on what your team already runs and how much of the configuration you are willing to own.

For the effort lever, the default should be the cheap end. Raise review effort on the repositories where diffs are riskier, and measure the change in review latency and cost rather than assuming a heavier review is a better one. A reviewer that runs on every push at the highest effort level and posts findings nobody can merge-block with is just a slower comment feed.

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.