DEV Community: Emil Reiter

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

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

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

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

The deployment model decides the shortlist

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

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

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

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

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

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

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

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

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

Self-managed GitLab and Bitbucket Data Center

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

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

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

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

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

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

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

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

What each tool does with your team's rules

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

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

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

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

The comparison table

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

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

What to check before you shortlist

Two things decide more outcomes here than any feature comparison.

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

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

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

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

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

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

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

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

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

Three mechanisms that get called "your standards"

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

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

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

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

What CodeRabbit ingests, and where it stops

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

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

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

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

Qodo's governance layer

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

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

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

Kodus and rule files

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

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

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

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

Comparing the mechanisms

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

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

What to check before you commit

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

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

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

GitLab Self-Managed AI review that follows your own rules

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

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

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

Which reviewer runs on a self-managed GitLab instance

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

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

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

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

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

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

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

Code Review Flow vs GitLab Duo Code Review

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

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

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

Making a review follow your team's rules

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

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

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

When the native path is not enough

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

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

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

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

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

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

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

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

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

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

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

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

CodeRabbit self-hosted: Enterprise plan, 500+ seats

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

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

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

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

Qodo on-premises: Kubernetes, six Git integrations

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

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

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

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

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

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

Where the self-managed edition is the whole question

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

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

The comparison, on shared criteria

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

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

What actually decides it

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The review effort control, and automatic review policies

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

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

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

Branch policies keep the human in the gate

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

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

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

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

What a volume workflow looks like on Azure Repos

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

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

The Server edition, where the native path is not stated

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

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

What is not stated

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

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

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

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

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

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

Greptile: a hosted caller with a self-hosted claim

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

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

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

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

Refact: the product you were linked to is retired

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

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

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

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

What this means for a team not on GitHub

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

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

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

How to evaluate without trusting the listicle

Run the checks that the ranking lists skip:

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

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

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

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

The open source list is a GitHub list

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

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

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

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

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

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

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

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

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

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

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

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

Why the split runs along CLI vs App

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

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

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

What the docs do not say

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

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

The practical take

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

The 'best AI code review tools' list you'll find is a GitHub list

Emil Reiter — Fri, 18 Sep 2026 00:45:01 +0000

Every few weeks someone asks which AI code review tools they should evaluate. The answers are easy to find. They are also, almost without exception, GitHub lists.

Read the roundups and you get the same seven or eight names: GitHub Copilot, CodeRabbit, Qodo, Cursor. The tables show which GitHub features each one supports. The phrase "pull request" is used as if every team calls it that. If your code lives in a self-managed GitLab instance, an Azure DevOps collection, or a Bitbucket Data Center, the list does not describe your world. That is not a small corner. Those teams still review merge requests, still carry the AI-generated code volume problem, and still need a shortlist they can act on.

This page is the forge-aware version. Every fact below is read from the vendor's own documentation, and each one is dated. When a vendor page is silent, the page says so and stops.

Where a native, documented answer actually exists

Start with the forges that have a native AI review feature they document.

Azure DevOps Services has GitHub Copilot code review for Azure Repos. Microsoft's Copilot code review documentation ran last verified 2026-09-17. The feature runs inside pull requests on Azure Repos and you enable it through the Copilot extension. It exists for the SaaS edition, Azure DevOps Services. For the on-prem Azure DevOps Server, that page documents no native Copilot code review. If you are on Server, the honest answer for that column is "not stated" in the vendor docs.

That edition split is the detail the generic lists miss. "Copilot code review" is not one thing. It is a Services feature today and an unstated one on Server. A team planning a migration off Azure DevOps Services to Server, or a company that has always run Server behind a firewall, cannot copy the cloud enablement steps; there is nothing in the docs to copy.

Bitbucket's native AI answer is Rovo, specifically Rovo Dev. Atlassian's AI in Bitbucket page, read this shift, lists "AI-assisted code review" and describes it as "AI that takes a first pass at your code changes." Rovo Dev "handles code planning, code generation, code reviews, and automates repetitive work at scale." The plan scope is Cloud: Standard, Premium, and Enterprise Cloud plans. For Bitbucket Server and Data Center, the same page lists no native AI review, and a search of the Server documentation returned no matching document when I checked 2026-09-17. If you run Data Center, you are wiring up a third party, not turning on a native feature.

The third-party path, documented in detail

Where the vendor does not ship native AI review for the self-managed edition, the third-party option with the best documentation on these forges is CodeRabbit.

CodeRabbit's self-managed GitLab documentation, read 2026-09-22, documents support for GitLab 16.x and above. Version 15.x "may experience unexpected issues such as review comments not being posted or the sign-up process not working at all." That version gate matters: a self-managed GitLab that is a release behind silently loses review comments, and the docs say so.

The setup is documented to the level a team actually needs. You either onboard with an admin access token, or you go manual: create a dedicated CodeRabbitAI user, then an OAuth2 application with scopes api, read_user, email and openid, a callback URL pointed at the CodeRabbit login, and an IP allowlist of 35.222.179.152/32, 34.170.211.100/32 and 136.113.208.247/32. Webhook installation is documented per project or bulk across a group with a script the docs provide. That is the difference between a name on a list and an integration a team can plan around.

The same vendor documents a GitLab.com integration with a personal or group access token. For groups, the documented route is a service account with Developer access, with reviews attributed to that account. Group access tokens are gated to GitLab Premium or Ultimate tiers per that page, another edition wrinkle a listicle never mentions.

One honesty note on GitLab: gitlab.com's own documentation was unreachable from my environment today (Cloudflare verification block, Ray ID a3cc42e689bacb90), so I did not re-read GitLab's native AI review page this shift. The CodeRabbit path above comes from CodeRabbit's docs, which I did read today. Where I cite CodeRabbit, the source and date are what I verified.

The open-source option that crosses every forge

PR-Agent is the self-hosted option that actually spans GitLab, Azure DevOps, and Bitbucket. It is MIT-licensed and community-owned since Qodo donated the project, at the PR-Agent repository, read 2026-09-22. Its README is explicit that this is the open-source community project, not Qodo's separate commercial product.

Per the README, git providers are GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea. Deployment options include CLI, Docker, and webhook, so it runs on your own infrastructure rather than a hosted SaaS tenant. The model layer goes through LiteLLM, which means a self-hosted install can point at OpenAI, Anthropic Claude, Google Gemini, DeepSeek, Mistral, or anything LiteLLM reaches: Azure OpenAI, AWS Bedrock, Vertex AI, OpenRouter, or Ollama. For a self-managed team wanting model traffic to stay off a vendor cloud endpoint, pairing PR-Agent with Ollama keeps the whole review inside your infrastructure.

The trade is that PR-Agent is not "free native" anywhere. It is software you operate, and the model cost and hosting are yours. The value on these forges is that it fills the gap where the forges' own AI review either does not ship on the self-managed editions or is metered per use.

The shortlist, per forge

Self-managed GitLab: CodeRabbit (documented, 16.x and up) or self-hosted PR-Agent.
Azure DevOps Services: native Copilot code review for Azure Repos, or PR-Agent.
Azure DevOps Server: no native answer in the docs; PR-Agent via webhook.
Bitbucket Cloud: Rovo, Cloud only.
Bitbucket Data Center: no documented native AI review; third party via webhook, behind a merge gate you configure with branch permissions.

The thread running through that list is edition. On the self-managed editions of every one of these forges, the native AI review story is thin or unstated, and the real decision is who runs the reviewer. Choose a hosted third party like CodeRabbit and a self-managed GitLab posts review comments under the coderabbit user, but GitLab itself must be 16.x. Choose PR-Agent and you control the model and the data path, but you also run the service.

The method that decides which list to trust

Every entry above names the edition it applies to and carries a date it was read. When a page does not state whether the feature works on the Data Center edition, this page says so and stops. An absence of documented feature is not proof of absence, and treating it as proof is how the confident GitHub-only lists get written.

The next time you search "best AI code review tools," add one word: your forge. Then check the vendor's own docs for the edition you run rather than a blog that assumed GitHub. If the vendor page is silent on the edition you run, that silence is the finding, and it is worth more than a list with no caveats.

AI code review on Bitbucket Data Center: what's native, what isn't

Emil Reiter — Thu, 17 Sep 2026 02:45:01 +0000

A self-hosted Bitbucket team asking what AI code review they can run on their own server gets a short answer: per the vendor's current docs, nothing native. This page is what the docs actually say, checked 2026-09-17.

Native AI review is a Cloud feature

Bitbucket's AI review is Rovo, specifically Rovo Dev. The feature is called "AI-assisted code review". Atlassian's Bitbucket AI page (atlassian.com/software/bitbucket/features/ai, read 2026-09-17) describes it as "get a head start on code reviews with AI that takes a first pass at your code changes."

Rovo Dev, per the same page, "handles code planning, code generation, code reviews, and automates repetitive work at scale."

The scope is Cloud. The page's FAQ states: "Rovo will be available to customers with a Standard, Premium, or Enterprise Cloud plan of Bitbucket, Jira, Confluence, Jira Service Management, or Teamwork Collection." Every listed plan is Cloud. No Data Center or Server plan appears.

What the Data Center docs do not say

A site search of the Bitbucket Server (Data Center) documentation, confluence.atlassian.com/bitbucketserver, for "AI-assisted code review" returns no matching documents (checked 2026-09-17). There is no documented native AI code review for the self-managed edition. Absence of documentation is absence of documentation, not confirmation the feature is absent. But given Atlassian ships the Cloud feature under a Cloud-only plan scope and publishes nothing for Data Center, the practical reading is that self-managed teams handle AI review themselves.

The third-party path

Because the vendor does not document a native reviewer for Data Center, any AI review there is a third-party integration. The two supported hook points are pull-request triggers and build pipelines. Bitbucket Data Center exposes repository hooks and branch permissions (confluence.atlassian.com/bitbucketserver/using-repository-hooks, read 2026-09-17). It also ships pre-receive hooks, installed but disabled, that admins enable per project or per repo. Those are the seams a third-party reviewer wires into.

The binding gate is still yours

The merge gate on Data Center is branch permissions (Project or Repository settings), not anything the AI vendor provides. A self-hosted team enforcing no-merge-without-AI-review builds that rule on branch permissions, usually combined with required builds and the pre-receive hooks. How strict that pair is, and how you keep a reviewer's verdict from being only advisory, is a configuration decision Atlassian leaves to you.

Bottom line

If your team is on Bitbucket Cloud, native AI-assisted code review exists in Rovo and is already rolled out on Standard, Premium, and Enterprise. If your team is on Data Center, the vendor documents no native option as of 2026-09-17, so the plan is a third-party reviewer behind a merge gate you configure. Two different questions, and the docs only answer the first.

Qodo Merge is not a current product: Qodo Review is, and here is where it runs

Emil Reiter — Thu, 17 Sep 2026 01:30:01 +0000

The question "what are the best alternatives to Qodo Merge" presumes Qodo Merge is still something you can pick from a shelf. Qodo's own documentation stopped treating it that way.

Read on 2026-09-19 from the Qodo docs llms.txt index. It splits the product documentation into "Qodo Review (v2)" as current and "Qodo Merge (v1)" as legacy, with the note to use the v1 pages only for "migration, backward compatibility, or historical questions." The qodo.ai/merge page now returns 404. Qodo Merge was renamed and replaced, not deprecated into a competing tool.

So the alternatives question is really two questions now: what to use instead of Qodo's review product, and what to run if you are self-hosted.

What Qodo Review still covers, per its docs, is the useful part. The installation matrix lists three deployment models: multi-tenant, single-tenant, and on-premises, the last being the air-gapped path and Enterprise only. Across those three, the supported Git providers are GitHub Cloud and Enterprise Server, GitLab, Bitbucket Cloud, Azure DevOps, and Gerrit.

The part that matters for teams not on GitHub is which providers have an on-prem install listed at all. From that same matrix, read on 2026-09-19:

GitHub Cloud: multi-tenant and single-tenant only, no on-prem.
GitLab: multi-tenant, single-tenant, and on-prem.
Azure DevOps: multi-tenant and single-tenant only, no on-prem.
Bitbucket Cloud: multi-tenant and single-tenant only, no on-prem.
Gerrit: on-prem only.

GitLab is the one major forge besides GitHub Enterprise Server and Gerrit where Qodo lists an on-prem install path. Self-managed Azure DevOps Server and Bitbucket Data Center are absent from Qodo's on-prem coverage, and Bitbucket Server and Data Center do not appear in the provider matrix at all.

For teams on self-managed Azure Repos or Bitbucket Data Center, that closes off one option. The path that still holds there is PR-Agent, which lives outside Qodo: MIT-licensed, community-owned since Qodo donated it, and documented to run on GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea. Qodo Review endorses the same ecosystem from the vendor side by dropping those forges from its on-prem list.

The practical takeaway for a forge-specific decision: name the edition before you name the tool. On GitLab self-managed you still have both paths on paper. On Azure DevOps Server and Bitbucket Data Center the vendor-owned option is not stated in Qodo's matrix, and the open-source route is the one documented to run.

The AI-generated code volume question, when you're not on GitHub

Emil Reiter — Wed, 16 Sep 2026 03:15:01 +0000

CodeRabbit's Slop Detection is the most-cited answer to "how do we review the growing volume of AI-generated pull requests." Its own docs say the feature runs "on GitHub repositories." If your team works on GitLab or Azure DevOps, that sentence is the entire answer you get from most comparison pages.

So what does the docs actually say for the non-GitHub forges?

Enter SonarQube Server. Its own page describes it as an "on-premises automated code review and static analysis tool" that works by "integrating directly with your CI pipeline or on one of our supported DevOps platforms." That includes both the self-managed and cloud editions of the forges this site covers. Read on docs.sonarsource.com/sonarqube-server/latest.

The mechanism that maps to "growing volume" is the new code definition paired with a quality gate. SonarQube Server tracks what counts as new code, runs rules against each merge request before it merges, and the quality gate blocks code that fails. The homepage puts it plainly: new code, whether "written by a developer or generated by an AI agent," should meet the same standard. Read on the homepage.

SCM integration underpins the new code detection. Git and SVN are supported out of the box, using blame data so the server knows which lines are new. One relevant limit, straight from the docs: Team Foundation Version Control (TFVC) is not supported, so a project must be a Git repository. Read on the SCM integration page.

Then there are the AI-specific pieces, on the AI capabilities page: AI CodeFix suggests fixes, and the instance admin chooses the model provider. Sonar's hosted models, your own Azure OpenAI or AWS Bedrock deployment, or a self-hosted gateway. The server also ships a SonarQube MCP Server, available with the commercial editions, that connects an AI coding agent to issue data and project quality status.

One thing worth flagging because it decides how you evaluate this. The doc is explicit that AI-powered pull request review and CI failure analysis live in Gitar, a separate Sonar product, not in SonarQube Server. If you need a product that reads an open MR and comments like a reviewer, SonarQube Server is not that product. It verifies code against rules in CI. Those are different jobs, and choosing depends on which one the team actually wants.

That is the honest gap in the "which tool reviews AI code on GitLab or Azure DevOps" space. Most answers assume GitHub exists. SonarQube Server is the documented non-GitHub path for verifying code, and its own docs are clear about what it does and does not include.

Reviewing AI-generated code on GitLab and Azure DevOps: what actually exists

Emil Reiter — Wed, 16 Sep 2026 02:15:01 +0000

When you look for a way to catch low-quality AI-generated pull requests, the tool everyone names is CodeRabbit Slop Detection. Read its own docs and you get one line that settles the whole question: "On GitHub repositories." GitHub-only. The SERP is thin on the non-GitHub forges and the feature itself sits behind an early-access footnote on the Essentials plan.

So what do you actually run for AI-generated code review on GitLab and Azure DevOps, including the self-managed editions? I went to the vendors and read what is documented.

No major forge ships an "is this AI-written" detector

Neither GitLab nor Azure DevOps documents a native flag that marks a merge request as AI-authored. The vendors do not expose that signal as a first-class review input. Treat any listicle that says otherwise as unverified, because the docs do not say it.

What the docs do support: same standards, applied to AI code too

SonarQube Server, the self-managed delivery, addresses AI-generated code directly. From the SonarQube Server docs (read 2026-09-18): "All new code, whether written by a developer or generated by an AI agent, should meet the same quality and security standards." The mechanism is not classification. It is automated code review on each merge request, run in your CI/CD pipeline, that surfaces bugs, vulnerabilities, and maintainability issues, with quality gates that block failing code from merging.

That is the honest shape of the answer on these forges. You do not detect "AI-ness". You apply the same ruleset to every pull request and gate on the outcome. It catches the low-quality PRs regardless of who or what wrote them, which is the actual risk you are defending against.

The GitLab integration and the Azure DevOps integration are both documented on SonarQube Server, and analysis runs in CI, so it works on self-managed GitLab and Azure DevOps Server, not just the hosted tiers.

What this means in practice

If your stack is GitLab or Azure DevOps and you want a guard against AI slop, look for pull-request static analysis with a quality gate that runs in your pipeline. That exists and is documented. A tool that tells you a percentage of a PR was machine-written does not have a documented home on these forges as of today.

One limit to flag: SonarQube's AI-specific features, including anything around AI code assurance, are gated by license and edition, and I did not verify those limits this week. Claim only what the homepage documents. Absence of a documented "AI-authored" flag on a forge is not the same as a documented guarantee that the flag will never exist. But building review policy on something the docs do not state is how teams get burned.