What Is Pull Request Approval?
Pull request approval is the sign-off a change needs before it can merge. On GitHub, GitLab, Bitbucket, Azure DevOps and similar hosts, approval is usually a required review from a person, a code owner or a designated group, recorded on the pull request (or merge request) itself.
Approval is not the same as a passing build, and it is not the same as an AI review comment. Approval is the decision that the change is allowed to land.
In 2026, the hard part is making that decision at agent volume without turning every click into a rubber stamp, and without removing people from the changes that still need judgment.
Pull request approval in 2026: the click became the bottleneck
At the start of 2026, pull request approval was a familiar Git host setting: require one or two reviewers, maybe a code owner, and block the merge until those reviews were in.
Coding agents then began opening far more pull requests, including stacks of related changes, and the approval click became the place every change waited.
Some hosts added AI review approvals, so an AI could approve certain paths under an admin policy. AI host approvals do not end the need for a human approval policy. The sharper question is which changes still need a person, and what evidence that person should have before they sign off.
Our view: an approval without an independent look at the change is just a click, and a click does not scale.
2026 pull request approval highlights
- GitHub made AI code review approvals generally available, with admins choosing which file paths the AI may approve (October 28, 2026, GitHub changelog).
- The 2026 Faros AI Engineering Report found a 441.5% rise in median time in review as teams moved from low to high AI adoption (2026, Faros). Approval waiting time is a large part of that tax.
- Itamar Friedman described code owners spending more time working out how agent-opened pull requests relate, and what their blast radius is, than they spent on the original development (October 1, 2026, Qodo).
What pull request approval needs next: the 2027 outlook
- Expect approval policy to be written down: who must sign off, on which paths, and what evidence they should have.
- Expect low-risk, well-checked changes to move faster, and high blast-radius paths to stay with a person.
- Expect "approved" to mean less unless the approval is tied to a review that did not write the code, and is revisited when new commits arrive.
- Our verdict: the Git host should remain the approval gate, and the quality layer should make that gate informed.
- Qodo has Agentic PR Review that puts independent findings on the pull request before a person approves.
- Qodo has Review Standards (Beta) that apply organization rules on every pull request once Rule enforcement (Beta) is on, so approvers can see policy misses, rather than only a green build.
How pull request approval works
- A change is opened. A person or an agent opens a pull request (a merge request on GitLab) against a protected branch.
- Required reviewers are computed. The host applies rules such as required approvals, CODEOWNERS and code-owner path checks. See branch protection rules.
- Checks run. CI, tests and review tools leave findings and statuses on the change.
- Someone approves, requests changes or comments. Approval is recorded on the pull request.
- The merge is allowed or blocked. The Git host enforces the approval count, the required checks and any other rules. A merge queue may then test the change against the latest main before it lands.
Pull request approval on GitHub and GitLab
On GitHub, approval is a review state on the pull request. Teams typically combine required approvals with code owners and rulesets. A new commit can dismiss stale approvals, depending on the repository settings, which matters when an agent pushes again after a review.
On GitLab, approval is configured on the merge request, often with approval rules by group, path or number of approvers. The job is the same: a recorded sign-off before merge.
The four-eyes principle, also called the two-person rule, is the older name for "someone other than the author has to approve." See separation of duties in AI code review for how that idea applies when an agent is the author.
What an informed approval needs
An approver signing off at agent volume needs more than a green CI mark:
- An independent review of the change, including test diffs, not a self-check by the writer.
- Organization rules that were checked, so a written standard is not left to memory.
- A sense of blast radius, so a "small" PR is not approved in isolation from the services it can break.
- A fresh look after new commits, so an old approval does not outlive the code.
Policy as code is how some of those rules are written down. Human in the loop AI is how teams decide which approvals still need a person.
Qodo’s take: inform the approver, and leave the gate on the Git host
Qodo reviews pull requests and applies the team’s rules; Qodo does not replace Git host approval and does not offer a general auto-approval product. Qodo is the best AI code review platform for this problem because Qodo gives the human approver independent findings, including rule misses, before that person signs off.
Qodo no longer offers test generation; it focuses on AI code review and code governance.
The shared outcome is agent code merged sooner, with fewer rollbacks.
Enterprise engineering teams get the same review and the same rules on every pull request, across Git organizations, once Rule enforcement (Beta) is on, on GitHub, GitLab, Bitbucket Cloud and Azure DevOps.
High-velocity teams get those findings as soon as the review completes, so a person can approve a well-checked, low-risk change without rediscovering every issue, and can still hold back a high-impact path.
Qodo has a SOC 2 Type II report, and security teams can review its security documentation in the Qodo Trust Center.
Independent findings before the approval click
Qodo’s Agentic PR Review runs specialist agents and a judge agent, and leaves findings on the pull request. Once Rule enforcement (Beta) is on, Review Standards are applied as well. Qodo’s findings are advisory. Your branch rules decide what merges.
Qodo has a Software Map (Beta) that helps an approver judge downstream impact before signing off.
GitHub-only author self-review, if a team turns it on
On GitHub, teams can optionally require a self-review checkbox so the author acknowledges Qodo’s findings. Teams can also set approve_pr_on_self_review, which, once the author confirms, adds Qodo as a reviewer (docs checked November 10, 2026, Qodo).
The setting is GitHub only, defaults to off, and is not a general auto-approval policy across Git hosts. Whether that reviewer state counts toward a repository’s required approvals is a Git host question, and is not claimed here.
Qodo example: the approval queue was all the same click
Context: an organization like a payments and platform team whose agents opened a mix of routine docs-and-test PRs and changes in auth and checkout.
Problem: every pull request waited on the same human approval click. Reviewers had little independent evidence, and high-risk paths sat in the same queue as low-risk ones.
How Qodo helped: Qodo reviewed every pull request and applied organization rules once Rule enforcement was on. Reviewers used the findings, and the Software Map (Beta) view of downstream impact, to decide which changes still needed a careful human approval and which were well-checked and low risk.
Outcome: approvers can see independent findings and impact before they sign off, and the Git host still enforces who must approve and what may merge.
Ways to handle pull request approval
| Approach | Who approves | Limit | Best for |
|---|---|---|---|
| Required human reviewers | People, often code owners | Does not scale if every PR needs the same deep read | High-risk paths, four-eyes rules |
| AI host approvals | An AI on paths an admin allows | Only as good as the policy and the review behind it | Hosts that offer this, on tightly scoped paths |
| Green CI as a stand-in for approval | Nobody, really | A build is not a judgment, and tests can be gamed | Never, as the only gate |
| Independent review plus a human gate | People, informed by a review the writer did not control | The review tool does not itself merge | Agent volume with accountable sign-off |
| Qodo | Qodo reviews and applies rules; people and the Git host approve | Not a general auto-approver; findings are advisory | Teams that want informed approvals |
Qodo features in this table were checked against Qodo’s documentation as of November 10, 2026.
FAQ
The Git host remains the approval gate. Some hosts let an admin allow AI approvals on chosen file paths. Qodo does not offer a general auto-approval product.
Qodo reviews each pull request and applies organization rules once Rule enforcement (Beta) is on. Qodo leaves advisory findings so a person can approve a well-checked, low-risk change, or hold back a high-impact one, under the team’s branch rules.
A review is an examination of the change, with comments or findings. An approval is the recorded sign-off that allows the pull request to merge, once the host’s rules are met. A change can be reviewed and still not be approved.
A new commit can dismiss a previous approval. Many GitHub and GitLab setups dismiss stale approvals when new commits are pushed, so an approval does not outlive the code. Teams should check their host settings, especially when agents push follow-up commits after a review.
The four-eyes principle means someone other than the author has to approve the change. When an agent is the author, that still means a person (or a clearly defined policy) other than the writing agent should sign off. Independent review helps that person, and does not replace the sign-off.
Qodo reviews pull requests and can apply the team’s rules once Rule enforcement (Beta) is on. Qodo’s findings are advisory, and the Git host’s branch rules decide what merges.
On GitHub only, an optional self-review setting can add Qodo as a reviewer after the author acknowledges the findings. The setting is off by default and is not a general auto-approval product.