AI code review for Azure Repos currently consists mainly of built-in features, connected review services and in-house tooling; the costs usually depend on triggers, the scope of changes, parallelism and the operating model. When choosing between them, the “AI” label matters less than how cleanly the review fits into your pull request process.
This article sets out the position as of 01/11/2026 for Azure DevOps Services. It looks at the selection questions for teams that want to establish reviews, policies and responsibilities in Azure Repos on a binding basis.
If you need them, you will find more detailed explanations of terms and process components elsewhere on this website, including required reviewers, automatable code review, the four-eyes principle, branch policies as code, open threads, permissions and exceptions, the Azure Repos or GitHub decision and merge conflicts.
What options are available for AI code review in Azure Repos
At present, there are essentially three relevant routes for Azure Repos:
- a built-in review feature in Azure DevOps Services,
- connected review services that work with pull requests via comments or statuses,
- in-house tooling based on the Azure Repos interfaces.
According to Microsoft Learn, in “Sprint 279 Update”, “Copilot code reviews” and “Review pull requests” (all accessed on 01/11/2026), the built-in option is currently in Public Preview. It can be enabled at organisation, project or repository level, can take custom instructions into account and can start automatically via branch policy.
For classification purposes, however, activation matters less than this: according to “Review pull requests”, the feature always leaves a comment review. That makes it a review indication, not a required-reviewer approval.
Alongside that, there are review services that connect to pull requests. In Azure Repos, this is typically done technically via status messages or comments. Whether such a service merely provides indications in your process or fits into the policy chain depends on how it is connected.
The third route is in-house tooling. Azure Repos provides branch policies, status checks and administration via the REST API or the “az repos policy” command for this, as Microsoft Learn describes in “Branch policies overview” and “Branch policies” (accessed on 01/11/2026).
If you want to keep watching the market, you can find updates on the planned status of Polier in the changelog.
What you should check for every option: blocking, re-review, data path
The first crucial point is its role in the merge path. In Azure Repos, an AI review is only process-relevant if it appears in branch policies as a required component. Comments on their own are indications. A status check is a machine-readable response on the pull request that you can use as a condition for completion.
So for each option, check briefly and in writing:
- does it provide only comments or also a usable status,
- can that status be included as a mandatory rule,
- under which identity does the result appear,
- and what happens after new pushes in the same pull request.
The last point in particular is often considered too late. If the diff changes after an initial review, you need clarity on whether a fresh review is started automatically and whether older results still count in the process. Without that definition, a review can quickly look more complete than it really is.
The data path is just as important. For each variant, record which pull request contents are transferred, where processing and storage are intended to take place, which logs are generated and which operator roles are involved. For data protection, DORA, NIS2 and co-determination, what matters is not marketing language but this concrete chain; you should have the legal assessment checked with a lawyer or the data protection officer.
If you want to assess the planned status of Polier, the page on security and data sets out the intended separation between the current position and the plan. For Azure DevOps Services, the plan is a direct SaaS with automatic self-service sign-up; one separate instance per customer in the publisher’s Azure in Germany, in the Germany West Central region, with its own database, storage, Key Vault, Service Bus and Container Apps Environment. The customer’s own branch policies apply, and the agent itself never merges. The intended framework for subscriptions and quotas is set out on pricing and packages; reliable measurements belong on proof and measurements only once real runs exist.
Limits that affect your process decision
Another limit lies not in the model but in the deployment status. According to Microsoft Learn “Copilot code reviews” and the release notes “Sprint 279 Update” (both accessed on 01/11/2026), the built-in review feature for Azure Repos is in Public Preview. There is no SLA for preview features; behaviour, limits and billing may also still change. For your process decision, what matters is therefore whether you use such a feature only as a supplement or plan it into a binding workflow.
There are also documented usage limits. According to Microsoft Learn “Copilot code reviews” (accessed on 01/11/2026), only active pull requests without merge conflicts are reviewed, in repositories up to 10 GB, with up to 100 changed files and 100 changes. At the same time, upper limits apply to concurrent reviews:
- 1 per pull request
- 5 per organisation
- 2 per user
A parallelism limit restricts how many reviews can be started or running at the same time.
For architectures using Azure DevOps Server, a different framework currently applies. According to Microsoft documentation, checked on 24/10/2026, Copilot code review was not available there; similarly, the Azure DevOps MCP Server did not support Azure DevOps Server on that date. If you run Services and Server in parallel, you should therefore assess selection, rollout and target picture separately.
What really drives costs in AI code review
What matters is less a single model price than your trigger profile. Costs rise above all when you start reviews broadly and automatically: on every pull request, again after further commits or additionally at several levels such as repository and project. The more tightly the review is coupled to the standard workflow, the more important the number of actual runs becomes.
A second driver is the scope of changes being processed. Large diffs, many affected files and frequent revisions increase the processing required for each review run. For the built-in feature in Azure Repos, the documented limits are also relevant here: in “Copilot code reviews” (accessed on 01/11/2026), Microsoft Learn cites active pull requests without merge conflicts, repositories up to 10 GB and up to 100 changed files and 100 changes.
Parallelism is another factor. If many pull requests are to be reviewed at the same time, quotas and waiting situations directly affect planning. According to Microsoft Learn “Copilot code reviews” (accessed on 01/11/2026), the limits are 1 concurrent review per pull request, 5 per organisation and 2 per user.
For the built-in option, the billing route is documented: Microsoft Learn “Sprint 279 Update” and “Copilot code reviews” (each accessed on 01/11/2026) mention Azure Cost Management.
If you are assessing future agent-based approaches: for Polier, the planned status is that tokens are included in the subscription as a quota per package. The product is in development and was not available on 01/11/2026.
How to set up a sound selection in Azure Repos
First define what should be binding in your process and what should merely be support. In Azure Repos, that distinction determines the choice of tool: indications via comment are different from a status that you evaluate in policies.
For the decision, a short assessment matrix with five points is often enough:
- connection to status checks or comments only
- behaviour on new iterations of a pull request
- visible limits on scope and parallelism
- billing route and internal cost model
- suitability for Azure DevOps Services today and Azure DevOps Server later
Then start by using the review on non-critical branches or in selected repositories. That will show you how many additional review runs actually arise and where your team needs interventions or exceptions.
If your organisation wants to keep a change of repository target open, make sure policies, review rules and evaluations are not tied unnecessarily to a single mechanism.
Common questions you should ask before making a choice
Which branch policies should you tighten up before any AI review?
Before you assess a review tool, your merge path should already be clearly defined. In “Branch policies overview”, “Branch policies” and “Secure repositories and pull requests in Azure Repos” (accessed on 01/11/2026), Microsoft Learn lists, among others, these policies: minimum number of reviewers, linked work items, resolved comments, build validation, status checks, automatically included reviewers and limit merge types.
For main branches, Microsoft recommends, among other things, tightly restricting permissions to bypass policies, requiring at least two reviewers, having sensitive paths checked automatically, checking linked work items, enabling build validation and requiring comment resolution. Only on that basis can you judge what useful role an additional AI review can actually play.
Is “Limit merge types” a security feature or more of a governance issue?
More of a governance issue. In “Secure repositories and pull requests in Azure Repos” (accessed on 01/11/2026), Microsoft Learn explains that “Limit merge types” controls history but is not a direct security control.
In practice, that means: if your audit model needs the exact sequence of commits, you should choose merge strategies deliberately. Squash creates a tidier target history, but combines the source commits into a single commit.
What does Microsoft’s direction towards GitHub mean for your choice in Azure Repos?
You should not make your decision only for today’s situation. In “Sprint 279 Update” (accessed on 01/11/2026), Microsoft Learn mentions Enterprise Live Migrations as a Public Preview. This allows repositories to be moved to GitHub Enterprise Cloud with their history, branches, tags, pull request metadata and branch policies; Azure Boards and Azure Pipelines can continue to be used.
For selection and process design, that means:
- do not tie rules unnecessarily to individual mechanisms
- keep statuses, reviews and evidence clearly separate
- think ahead to a target picture for Azure DevOps Services and possible later migrations
That way, you avoid a review decision made today causing unnecessary rework later.
Next step
Do not treat the decision as a tool question, but as a process decision. Beforehand, set down in writing which review results are only informative and which may actually influence the merge path.
For approval in your environment, four clarifications are usually enough:
- Who assesses indications and exceptions?
- When is a fresh run required after changes?
- Which contents leave the pull request for external processing?
- How do you allocate consumption and budget internally?
If you take the planned status of Polier into account: the coding agent from ballmüller solutions, Berlin, is in development and was not available on 01/11/2026. For Azure DevOps Services, the intention is a reviewer identity that sets a pull request status; your branch policies continue to apply, and the agent never merges itself.