Automated pull request review is connected after integrating with the version control system and works with the main providers, including self-hosted variants. The plan level determines coverage: a personal one usually looks only at your own changes, a team one lets you enable repositories for all contributors and set lists of who should and should not be reviewed. That is the first decision worth making deliberately: reviewing everything indiscriminately quickly turns into a stream people stop reading.
The most important thing to understand before adoption is how the check's result is read. Success means there are neither new findings nor unresolved old remarks. A neutral result appears when there are findings, when a run was cancelled or superseded by a fresher one, and also on an internal error - and it is neutral that is the default behavior when findings exist. Failure arises only when unresolved findings exist and the corresponding behavior is enabled. Three different causes produce the same neutral result, and from it alone you cannot tell findings from a malfunction.
From this follows a conclusion that saves weeks of misunderstanding. Until the failure setting is enabled, the check does not block merging by itself - it informs. A team that counts on automatic blocking without having enabled it lives with a false sense of protection: remarks appear while merges proceed as usual. That is worth checking once, deliberately: create a test pull request with a known finding and see what happens to the merge button. An answer obtained by experiment is more reliable than an answer obtained from a settings page.
It helps to lay the result values out in a table once. Below is that map. It also settles the question of a missing skipped status: the review does not publish such a conclusion, and if your automation waits for it, it waits for something that will not come. A branch of code written for a non-existent state never runs and for years looks like an act of thoroughness.
| Result | What it means |
|---|---|
| Success | No findings and no unresolved earlier remarks |
| Neutral | There are findings, the run was cancelled or superseded, or there was an internal error; the default when findings exist |
| Failure | There are unresolved findings and the corresponding behavior is enabled |
|---|
| Skipped | The review does not publish such a conclusion |
|---|
The enterprise programmatic interface has a separate entry for starting a review, and it has limits on rate and on rights. A dry-run mode stands apart: it performs the analysis without consequences in the version control system - it leaves no comments and publishes no status. But it is important to understand that a dry run is not ephemeral: findings are stored and it is billed. It also has its own separate rate limit, stricter than the ordinary one.
That is a typical example of a property easy to take for obvious and get wrong. The word dry usually means free and traceless; here it means without side effects in the repository. The difference shows up in the bill and in accumulated findings, and it is better to learn about it from the documentation than from an expense report. The same exercise is worth doing with every mode named by a word from everyday language: check what exactly it does not do instead of inferring it from the name.
Blocking a merge is not a property of the review at all but a property of the provider. The review publishes a check status; the decision about whether that status is required for merging is made by branch protection on the version control side. So there are two settings, and they have to agree: the failure behavior on the review side and the requirement for that check in the branch rules. One enabled without the other gives two familiar surprises - either a failure that stops nobody, or a required check that never fails. These two mechanisms are worth separating in your head once and for all: one produces a signal, the other decides what to do with it.
Adopting review makes sense the same way adopting an automation does: gradually and with measurement. Start with a few repositories where there is someone to triage findings, and watch a single number - the share of remarks that were acted upon. If it stays high, the coverage can be widened. If the share closed without changes is growing, that does not mean the review is bad: more often it means it is looking at code its rules were not tuned for. And if the review is driven programmatically, it pays to narrow the key's scope from the start and to keep the request identifier - otherwise working out why a run behaved unexpectedly will have to be done from indirect evidence.
The engineering conclusion is simple: automated review is a signal you build into your process rather than a ready process. Decide in advance whether it blocks merging, who triages findings, what counts as a resolved remark and how that relates to branch protection on the provider's side. Without those decisions it becomes a stream of comments people start scrolling past within a month and switch off a month later.
The typical failures are predictable. Expecting a merge block without the failure setting enabled. Treating a dry run as free and traceless. Relying on a non-existent skipped status. Setting the failure behavior and branch protection so that they do not agree. And adopting review without an owner for findings - then remarks accumulate with nobody to resolve them.