kodus-ai

Open source AI code review: which part is actually open Open source AI code review describes at least five different arrangements, and the license badge on the repository tells you almost none of them. What actually decides how a review behaves is where the diff goes and which process holds it. Those two answers can be unrelated to the license file sitting at the root of the repo. This matters more now than it did a year ago, because most of the code arriving in review was written by an agent. If the reviewer runs inside your infrastructure with your model key, the agent's diff never leaves. If the reviewer is hosted, every agent pull request ships that diff to somebody else's service, and the pace agents set means that happens far more often than it used to. The license field on the repository is the weakest signal available GitHub's API reports a license for a repository by reading the license file it can recognize. For kodustech/kodus-ai, that field comes back as NOASSERTION, even though the README carries an AGPLv3 badge. The reason is visible in the repo's own license file: it is a dual-license arrangement. Source outside the Enterprise Code is AGPL-3.0, while any file with .ee. in its name or inside an ee/ directory falls under a separate Kodus Enterprise Code License. That second license permits a self-hosted Community user to run the unmodified Enterprise Code needed for Community features, including code review and bring-your-own-key, in production. It does not permit modifying that code, and it does not permit using Enterprise-only features. A single SPDX identifier cannot express that. The license field on a repo page is a convenience for scanning dependencies, and it has no way to say which directories the permissive half covers. Two more examples from the same category. the-pr-agent/pr-agent reports MIT, and the LICENSE file confirms plain MIT. alibaba/open-code-review reports Apache-2.0 and the README states it plainly, Copyright 2026 Alibaba. Those two are the easy cases, and they are easy precisely because the whole project is under one license. Five things teams mean when they say a reviewer is open source The repository is the client, and the reviewer is hosted sourcery-ai/sourcery is MIT, and the repository is genuinely open. Read the top-level contents and you find a license, a pre-commit-hooks.yaml, a write-up about building an LSP client, packaging metadata, and a demo GIF. The README's installation path for pull request reviews is adding the GitHub App, and it says the reviews use OpenAI and Anthropic models, which means the diff of the PR is sent to those providers. For private repositories the README points to a Team or Pro plan. The code being open and the review being open are two separate facts here. If your question is whether the thing commenting on your PRs can be audited and run by you, the MIT license does not answer it. Sourcery's README is unusually direct about where the product stands: it says the goal is the kind of review you would expect from a colleague, and that they are not there yet. Self-hostable, with a carve-out that the badge hides Kodus is the shape most teams picture when they hear the phrase, and it still has an edge worth reading before you commit. The repository describes itself as open source, self-hosted AI code review with bring-your-own-LLM, and the docs state that all source is available to inspect, use, and improve. The self-host path is documented rather than implied: Docker on a VM you control, at least 2 CPU cores, 8 GB of RAM, and 60 GB of free disk. The CLI talks to your instance over HTTPS through KODUS_API_URL and a team key, and the documented CI shape is a JSON review with --fail-on error so the pipeline fails on findings above a threshold. The carve-out is the .ee. split described above, and there is one operational detail that belongs in the same paragraph. A self-hosted instance sends one anonymous heartbeat per day, carrying aggregated counters and no code, names, or identifiers, and it can be turned off with KODUS_TELEMETRY_DISABLED=true. A self-hosted review tool that phones home once a day is a different posture from one that never does, and the honest version of the claim includes the phone call. A community-maintained legacy project sitting next to the vendor's product PR-Agent is the case that breaks the usual assumption that an open-source reviewer is the company's product. The README says outright that the repository is not the Qodo offering for open-source projects, and describes PR-Agent as an open-source, AI-powered code review agent and a community-maintained legacy project of Qodo, distinct from Qodo's primary offering. It carries 13,868 stars as of 1 November 2026, which makes it one of the largest repositories in the category. That structure has visible costs. Releases from 0.34.2 onward publish to a new Docker Hub namespace, while older images stay at the legacy namespace as a frozen archive with nothing new pushed. The README also notes that /help_docs has been disabled since v0.36.1 pending a fix for a credential-exposure issue. If you pin an image or call a command, you are depending on a community project's release cadence, and the vendor's paid product will move on its own schedule. A CLI that never touches your pull request alibaba/open-code-review is Apache-2.0 and installs from npm as @alibaba-group/open-code-review, giving you an ocr command. You configure a provider and a model, then run ocr review against staged changes, a branch range, or a single commit, or ocr scan over whole files where there is no useful diff. There is no app to install on the forge and no hosted review step, which means the review is a step in your pipeline that you own end to end. It also publishes a benchmark with a method attached, which is rare enough in this category to be worth naming. The README describes a set built from 50 popular open-source repositories, 200 real pull requests, and 10 programming languages, cross-validated by more than 80 senior engineers into 1,505 annotated ground-truth issues, and links the AACR-Bench dataset on Hugging Face. The dataset description lists 2,145 review comments, made up of 1,505 expert-verified correct comments and 640 incorrect ones. The README also reports the result that goes against the vendor interest: recall is lower than a general-purpose agent's, described as a deliberate trade in favor of precision. A published dataset you can inspect is the thing that separates a benchmark from a claim. When a tool reports a precision number with no corpus behind it, there is nothing to check. A GitHub Action where you inherit the security posture Anthropic's claude-code-security-review is MIT and runs as a GitHub Action on the PR diff, posting findings as comments, with a default model and a 20-minute analysis timeout. The repository's security section says the action is not hardened against prompt injection attacks and should only be used to review trusted pull requests, and recommends configuring the repository to require approval for all external contributors. That is the right disclosure, and it is also the part teams skip. Running the reviewer yourself does not remove the fact that the reviewer reads a diff, and a diff is attacker-controlled text whenever an outside contributor can open a PR. Owning the infrastructure changes who holds the data. It does not change what the model is being asked to trust. Free for open source projects is a different thing again CodeRabbit's OSS plan gives public repositories Team features with no paid subscription, and its review limits vary by repository star count. Nothing about that is open source software. The company's code is not published, the reviews run on CodeRabbit's infrastructure, and the free tier is priced against your project's popularity rather than released under a license. The distinction is easy to blur because both arrangements end with a maintainer paying nothing. One of them means you can read and run the code. The other means you were granted free usage of a service, on terms that can change. If you are comparing hosted reviewers and want to know what a free arrangement really includes, the tier boundaries matter more than the price of zero, which is the same question I looked at in what the free tier of a hosted reviewer actually covers. For contrast, Copilot code review is closed and hosted, and its defaults are documented in GitHub's own instructions: Copilot leaves a Comment review by default, which does not count toward required approvals, and approvals are off by default at the enterprise, organization, and repository levels. There is no repo to read and no license to check, so the useful questions move to configuration, which is the territory covered in what the platform decides for you. The five shapes side by side | Project | What the repository contains | License covering the review path | Where the diff goes | What you run yourself | | - | - | - | - | - | | Sourcery | Editor client, pre-commit hook, packaging | MIT for the repo; hosted service for PR reviews | To OpenAI and Anthropic through Sourcery | The client, not the reviewer | | Kodus | The reviewer, self-host deployment, CLI | AGPL-3.0, with .ee. files under a separate Enterprise Code License | To the model provider you key, or to your own instance | The instance, the model key, the CI step | | PR-Agent | The reviewer, actions, CLI, configuration | MIT | To whichever model you configure | The action or container, on a community release cadence | | Alibaba Open Code Review | A CLI with no forge integration | Apache-2.0 | To the provider endpoint you configure | Everything, including when it runs | | Anthropic security review | A GitHub Action for security findings | MIT | To Anthropic's API on each run | The action, and the injection risk with it | What to check before you call a reviewer open source Read the license file, not the badge, and check whether it is one license or a split with a directory-based carve-out. Then open the README and look for the sentence that says what the project is not, because vendors write those sentences to stop a specific misunderstanding, and that misunderstanding is usually the one you are about to have. Then trace the diff: which endpoint receives it, whose key is attached, and whether the review happens in a process you control. Finally, run the install instructions once on a throwaway repository and see what the pipeline actually needs. The npm package, the container namespace, the required API key, and the disabled command are all visible before you commit a team to it. The reason to do this before adoption rather than after is volume. An agent-authored change is still a diff, and the reviewer reads it the same way. Choosing a self-hosted reviewer means the increasing number of those diffs stays inside your network boundary, and the trade is that you now operate the review path, which has its own real cost. Choosing a hosted reviewer means the operational burden is somebody else's, and the diff leaves on every push. Both are defensible, and the license badge does not tell you which one you picked. Two smaller checks belong in the same pass, because they decide how much the reviewer can enforce once it is running. Confirm which rule files it actually reads from your repository, since a reviewer that ignores your conventions will produce findings your team learns to dismiss, which is the problem behind which rule files a reviewer actually reads. And price the self-hosted path honestly, since the hardware floor and the operational time are the parts that get left out of the comparison, which is what the self-hosting cost is about.

Open source AI code review on GitLab, Azure Repos, Bitbucket DC 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 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.

Where AI review saves time: the write-back, not the analysis A tool that "supports Azure DevOps" may only be able to read your pull request. What cuts review time is the write-back: posting an inline comment where the problem is, replying and resolving a thread, applying a committable suggestion, submitting a review, marking the pull request ready, merging it. Those are separate capabilities from the analysis, and on some hosts they are missing entirely. That distinction matters for anyone trying to cut review time, because the analysis quality is the part every vendor page shows you and the write-back surface is the part you have to go digging for in the docs. The digging is worth it, because write-back is what the reviewer actually feels. Reading support and writing support are different claims Take a concrete example. CodeRabbit's Change Stack provider support page documents a per-provider capability matrix, and the Azure DevOps column is almost entirely empty on the writing side. Artifacts open read-only. No inline review comments, no file-level comments, no draft reviews, no submitting a review, no replying or resolving threads, no committable suggestions, no merge, no mark-ready-for-review, and no Change Stack chat. Azure artifacts also miss the live freshness check the other providers get, so an artifact cannot tell you the head has moved past the snapshot you are reading. Read that page carefully, because it is about Change Stack specifically, which is a review workspace sitting on top of CodeRabbit's PR review feature. The claim is narrower than the headline suggests. CodeRabbit can still comment on Azure DevOps pull requests through its PR review feature. The workspace layer, where a reviewer would normally resolve and apply, is read-only on Azure DevOps, and that is where the difference shows up. "We support your provider" and "we can act on your pull request" are two different sentences, and only the second one moves your cycle time. PR-Agent, the open-source reviewer that Qodo donated to the community, shows the same thing from the other direction. Its Azure DevOps installation page is explicit about a host limitation that has nothing to do with AI: Azure Repos Git does not honor YAML pr: triggers, so you wire the pipeline up through Build Validation as a required branch policy instead. The pipeline path also cannot start a run from a pull request comment, which the docs list as an open gap rather than a setting you missed. The webhook path does support a comment trigger, but only for API v2.0, and only after you register the webhook and give PR-Agent a stable identity on the project. On GitHub you type /review in a comment and the agent runs with nothing else to set up. PR-Agent covers GitHub, GitLab, Bitbucket, Azure DevOps and Gitea, so the same tool gives you a different amount of interactivity depending on where your code lives. What the write-back surface looks like per tool The useful way to compare reviewers is to build the list of actions first, then check which ones each tool can perform on your host. This is the list I use: post an inline comment, reply and resolve a thread, apply a committable suggestion, submit a review with a verdict, mark ready for review, merge or enter the merge queue, and run locally before push. | Tool | Hosts listed | Azure Repos write-back | Self-host / local | Notable constraint on the docs | | - | - | - | - | - | | CodeRabbit | GitHub, GitLab, Bitbucket, Azure DevOps | Change Stack artifacts read-only: no comments, suggestions, review submission, or merge | Not advertised as self-hosted | Draft reviews on GitLab and Bitbucket are held by the vendor and expire after 24 hours; Bitbucket needs authentication even for public repos | | PR-Agent (open source) | GitHub, GitLab, Bitbucket, Azure DevOps, Gitea | Pipeline and webhook paths work; no PR-comment trigger on the pipeline path, Build Validation policy required | CLI, Docker, self-hosted | /help_docs disabled since v0.36.1 pending a credential-exposure fix | | GitHub Copilot code review | GitHub and GitHub Enterprise | Not applicable | Runs in GitHub's infrastructure | Hosted review feature, so it is not a candidate if your repos are not on GitHub | | Kodus | GitHub, GitLab, Bitbucket, Azure Repos, Forgejo | Works in pull requests on Azure Repos; self-hosted runners supported | Self-hosted or hosted, CLI, CI/CD | Community tier caps Kody Rules at 10; SSO, RBAC and audit logs are Enterprise only | The Kodus row comes from its repository README, which lists pull request support across those five hosts and self-hosted runners, and from its pricing docs, which put Kody Rules at up to 10 on Community and hold SSO plus audit logs for Enterprise. Qodo also publishes an enterprise Azure DevOps page describing review embedded in the ADO pull request workflow, and while it argues the case well, it does not itemize the write-back actions per provider, so the specifics stay unknown from that page. GitHub's own Copilot code review documentation confirms that feature is scoped to GitHub and GitHub Enterprise. Why this shows up as review time rather than as review quality A reviewer's minute goes into reading and deciding. The bookkeeping that follows is a separate cost, and it is the one that scales with the number of pull requests rather than with their size. If a tool can apply a suggestion in place, the author never re-opens an editor, never re-pushes, never waits for the reviewer to come back. If it cannot, every finding becomes a message that a human has to transcribe into code, which is why tools with identical finding quality can produce different cycle times on different hosts. This is also where the plateau in review time comes from, the one Salesforce reported when code volume rose 30% and review time on the largest pull requests flattened. Teams that measure time-in-review per pull request often find the number stops improving after the first few weeks, even as the tool keeps producing findings. The reading got faster and the bookkeeping did not, so the floor is set by the writing side. There is a cost dimension too. Self-hosting changes which write-back paths are even available to you, because a locally hosted runner can act through the provider API in ways a hosted app cannot, and the tradeoff is operational. That is a separate decision from the one this article is about, and I covered the operational side in what self-hosting AI code review actually costs. How to audit this on your own backlog Do not start from the vendor list. Start from your last fifty merged pull requests and count, per pull request, how many review comments required a code change and how many were resolved without one. The first number is your write-back demand. If it is small, write-back gaps will not hurt you and analysis quality is the only thing worth comparing. If it is large, the capability matrix above is the more important document on any vendor page. Then run the check by hand once, on your actual host. Open a pull request, ask the tool to review it, and try to do each of these from inside the provider: apply the suggested change, resolve the resulting thread, answer the agent in the same thread, and mark the pull request ready. Whatever refuses is your real write-back surface. It takes twenty minutes and it beats reading any comparison page, including this one. Two smaller signals are worth watching as you go. One is whether the tool's reply loop survives without a comment trigger; if your host cannot start a run from a pull request comment, then every re-review is a pipeline run, and each one has a cost and a queue position. The other is whether the agent knows the difference between a fresh diff and a snapshot. CodeRabbit's docs say Azure artifacts are static and cannot compare against the head. A reviewer working from a stale artifact is not being helped, and the failure is silent. What to ask a vendor Ask which write-back actions are supported on your provider, by name, and ask for the docs page rather than the answer. Ask whether the tool can run as you or only as itself, because on some hosts the actions run under the tool's own identity and that changes who can resolve a thread. Ask what happens to a draft review if the session drops, and ask how a re-review gets triggered once the author pushes a fix. If the answer is a matrix with a mostly empty column for your host, that is not a defect in the product. It is a fact about what the review will feel like, and it is better to learn it from the docs than from a sprint that did not get shorter. Claims checked as of 2026-10-05.