Code reviews can be automated to some extent: in pull requests, machines are mainly good at checking rules that are clearly defined, repeatable and can be assessed the same way for every change. People remain responsible for intent, design, impact and risk.
For teams using Azure DevOps, this is mainly a question of the review model. A pull request brings together the change, the discussion and the approvals before merge. Automation becomes useful where you can translate criteria into rules in advance and place them in Branch Policies, builds, status checks and comments.
This distinction is helpful:
- rule-based checks,
- AI suggestions,
- human decision.
Important details often lie in the settings, for example for required reviewers or resetting reviewer votes after new pushes.
If you would like to follow the status of Polier: Polier by ballmüller solutions is in development and not yet available as of 01.11.2026. You can find the current status in the changelog, questions on security and data with status and date on the overview page, provisional information on packages and sign-up on the pricing page; reliable metrics would only appear under Proof after real-world runs.
What machines are good at checking today
In pull requests, machines are useful wherever the outcome is unambiguous: pass or fail. This mainly concerns minimum technical criteria that can be applied in the same way to every change.
Typical examples are:
- build succeeded or failed,
- tests passed or failed,
- static analysis with clear rules,
- known vulnerabilities in dependencies,
- status messages from connected review systems.
A Status Check is a technical signal from a service to the pull request, for example from a build, test or an external check.
In Azure Repos, the key combination here is Build validation and Status checks. Both are part of Branch Policies; in Azure Repos these policies are switched off by default and must be enabled deliberately (Microsoft Learn, “Branch policies and branch policy settings”, accessed on 01.11.2026; and “Branch policies overview”, accessed on 01.11.2026).
The boundary matters: such checks assess whether defined rules have been met. They do not assess whether a change is appropriate from a business point of view, whether a design remains understandable or whether a risk is acceptable in the given context.
In practice, this means: first define a small number of clear minimum rules for every pull request. Suitable rules are those that leave no room for discretion:
- does the change build,
- do the agreed tests run,
- do scanners or analysers return a defined status,
- is the result available in good time before approval.
Where teams manage many repositories, such standards can be maintained not only in the interface but also through az repos policy or the REST API (Microsoft Learn, “Branch policies and branch policy settings”, accessed on 01.11.2026). This is particularly relevant for consistent minimum checks across multiple projects.
What should remain human: design, intent, risk
Not every good change can be recognised through rules. In pull requests, there are questions that can only be answered properly with system knowledge, product understanding and responsibility.
These include in particular:
- whether the solution fits the intended architecture,
- whether the change is in the right place in the system,
- whether the consequences for operations, maintenance and troubleshooting remain manageable,
- whether edge cases, rollback and future extensions have been considered,
- whether the risk to the affected system has been assessed appropriately.
These points depend on context. A pattern that is sensible in one repository may be problematic in another. This is especially true for permissions, data flows, interfaces and changes in sensitive modules. A tool can flag anomalies. Whether that amounts to a sound objection is for people to decide.
That is why the distinction between indication and judgement matters. A comment describes an observation or a question. The actual review decision remains with people who understand the target state, side effects and priorities of the change.
For critical branches, Microsoft recommends as a starting point, among other things, granting the permissions Bypass policies when completing pull requests and Bypass policies when pushing only to a small admin group, requiring at least two reviewers and automatically involving reviewers for sensitive paths (Microsoft Learn, “Secure repositories with branch policies and pull requests”, accessed on 01.11.2026).
In short: people do not only review code. They take responsibility for intent, impact and approval.
Layer pull requests sensibly instead of putting everything into one review
A pull request becomes easier to decide when not every review question arrives at the same stage. Otherwise, formal defects, open questions and real approval decisions all compete within a single discussion.
That is why a fixed order per branch makes sense:
- technical evidence,
- clarification of open points,
- review decision according to team rules.
The first layer should contain only things with a clear outcome. In Azure Repos, these are mainly Build validation and Status checks. Such checks should be visible early so that reviewers do not spend time on changes that fail basic requirements.
The second layer keeps the process tidy. In Azure Repos, Check for linked work items and Check for comment resolution are particularly useful for this. Before completion, this makes it clear:
- what the change belongs to,
- which discussions are still open,
- whether follow-up questions have actually been dealt with.
Only after that should the actual approval count. With Require a minimum number of reviewers, the relevant part often lies in the options: may requesters approve their own changes? May the person who pushed last approve? Should new pushes weaken earlier approvals? These details influence the review process more strongly than the mere number of reviewers (Microsoft Learn, “Branch policies and branch policy settings”, accessed on 01.11.2026).
Important for governance: in Azure Repos, these policies are each switched off by default. If you want a multi-stage review model, you have to define it deliberately for each branch (Microsoft Learn, “Branch policies overview” and “Branch policies and branch policy settings”, accessed on 01.11.2026).
Where AI review fits in Azure DevOps – and where it does not
In Azure DevOps, AI review is mainly suited as an additional commenting check within the pull request. It fits where you want to see indications of anomalies, ambiguities or possible risks without automatically turning them into an approval decision.
For Azure Repos, Microsoft states that Copilot code review is available in Public Preview. The feature can be enabled per organisation, project or repository, run through a Managed DevOps Pool, guided with Custom Instructions, and also started automatically. Since Sprint 280, the effort levels Lite and Balanced have been available for this (Microsoft Learn, “Sprint 279 Update” and “Copilot code reviews”, accessed on 01.11.2026).
One point is crucial for understanding this: the result always appears as a Comment review. That means it does not count as a required reviewer approval and does not block a merge (Microsoft Learn, “Review pull requests” and “Copilot code reviews”, accessed on 01.11.2026).
Its scope is also limited. Only the following are assessed:
- active pull requests,
- pull requests without merge conflicts,
- repositories up to 10 GB,
- changes with up to 100 changed files and 100 changes.
In addition, there are limits on parallel reviews per pull request, per organisation and per user. Preview features also have no SLA and may change (Microsoft Learn, “Copilot code reviews”, accessed on 01.11.2026).
The data path needs scrutiny. According to the Microsoft Learn FAQ, the data residency of this review feature does not correspond to the data residency boundaries of an Azure DevOps organisation; processing may therefore also take place outside the EU. According to the FAQ, pull request content is not used to train foundation models; on retention, Microsoft refers to the service documentation (Microsoft Learn FAQ, “Copilot code reviews FAQ”, accessed on 01.11.2026). You should clarify questions on data protection, DORA, NIS2 or co-determination with a lawyer or the data protection officer.
Frequent questions you should clarify before deciding
Is an AI comment enough for governance and audit purposes?
Not automatically. For many teams, what matters in a pull request is not only the indication itself, but also who makes a decision and which policy is attached to it. An audit trail is the traceable record of rules, discussion, approvals and merge. So check separately:
- which forms of evidence are only meant to document,
- which forms of evidence actually control the merge,
- which identity sets a status or an approval.
This distinction is particularly important in Azure Repos because comments, statuses and reviewer votes have different functions.
What role does the merge strategy play for traceability?
A bigger one than is often assumed. According to Microsoft, Limit merge types controls the history, but it is not a direct security mechanism (Microsoft Learn, “Secure repositories with branch policies and pull requests”, accessed on 01.11.2026). A squash merge often keeps the target branch more compact, but it combines the commit sequence of the source branch. If your evidence model depends on the exact commit order, you should assess the merge strategy consciously rather than setting it out of habit.
What does Public Preview mean for a selection decision?
Above all: assess it differently from a regular platform building block. Microsoft points out that preview features come without SLA and may change (Microsoft Learn, “Copilot code reviews”, accessed on 01.11.2026). For your selection, this typically means:
- check limits and exclusions in advance,
- do not base a mandatory process solely on a preview,
- consider rollout, operation and support separately.
Does the situation change on Azure DevOps Server?
Probably not in the short term. According to Microsoft documentation, Copilot code review was not available there on 24.10.2026; Microsoft’s AI path is aimed at Azure DevOps Services. The Azure DevOps MCP servers also did not support Azure DevOps Server on that date. If you are planning on-premises, you should assess your roadmap separately for Services and Server.
Next step
Start with an operating decision, not a tool decision: what in your pull request process should block as a binding rule, what should merely make something visible, and what may only be decided by named individuals?
Check these separately:
- mandatory rules for each target branch,
- the role of comments, statuses and reviewer votes,
- data paths and responsibilities,
- whether Services or Server determine your constraints.
Particularly with AI support, a short preliminary review with data protection, information security and – where relevant – the works council is worthwhile; you should clarify questions on DORA, NIS2 and co-determination with a lawyer or the data protection officer.
Polier by ballmüller solutions is in development and not yet available as of 01.11.2026.