Clicking Approve takes a second and carries more weight than it looks. On many projects, an approval is the last human step before a change goes live, and with AI agents writing more of the code, it's often the only one. That makes it worth slowing down for, especially when the author is an agent that can't answer follow-up questions in person.

An approval says the reviewer has checked the change and believes it's ready to merge. Repository rules decide how many approvals are needed and from whom, and code owners can be required for sensitive files. AI adds new twists: the person who asked an agent for the work may count as its author, and an AI reviewer may be allowed to approve too. Knowing whose approval counted matters as much as seeing the word Approved, and the settings that decide it are worth checking once, so there are no surprises.

The best practice is easy to state and harder to follow: approve only what you could explain to someone else. If you can't, ask questions, request changes, or close the pull request. A thoughtful no protects the project more than a quick yes, and closing an agent's pull request costs nothing, since the agent can always try again.

The meaning of an approval

An Approve review submits feedback and approves merging the changes in a pull request [1]. On repositories that require reviews, it's also what unlocks the merge button.

That makes an approval a statement of responsibility, not a reaction. Approving says I looked at this, and I'd stand behind merging it. With agents writing more of the code, it's often the only human statement made about a change before it ships.

If a review was partial, saying so helps. An approval comment like Checked the copy and layout only, not the payment logic tells others what still needs a look.

Who counts as the author of an agent's work

When Copilot cloud agent does the work, its commits are authored by Copilot, with the person who asked for the change marked as co-author [2]. For approvals, GitHub treats that person like an author: they can't approve the pull request, and their approval won't count toward required reviews.

The rule closes an obvious gap. Without it, one person could ask an agent for a change and approve the result alone, with nobody else ever looking.

In practice, agent pull requests need a second person. Teams that rely on agents should plan reviewer time just as they would for any other contributor.

Code owners for sensitive files

Code owners for sensitive files

A CODEOWNERS file names the people or teams responsible for parts of a repository. It lives in the .github folder, the root, or a docs folder, and each line pairs a file pattern with owners [3].

Code owners are automatically asked to review pull requests that change their files. With Require review from Code Owners turned on in branch protection, those pull requests can't merge until an owner approves.

For AI-heavy projects, code owners are a strong safeguard. Assigning workflow files, payment code, and database migrations to the people who understand them means any agent change to those files gets the right reviewer automatically.

Pro Tip! Code owners need write access to the repository, so check permissions before adding a team to the file.

When an AI reviewer approves

Copilot code review normally leaves a Comment review, which doesn't count toward required approvals [4]. Since 1 September, 2026, admins can let it submit approving reviews that do satisfy a required-approval rule, a feature in public preview [5].

When this is turned on, an AI approval is dismissed if new commits are pushed, and admins can limit which files it may approve. Even so, GitHub notes that Copilot is not guaranteed to spot all problems in a pull request [6].

This is a setting worth checking in any repository that uses agents. If both the work and the approval come from AI, a person may never see a change before it merges, so knowing the configuration is part of supervising it.

Checking whose approval counted

A green Approved label doesn't say who approved. The pull request's sidebar and timeline do: each review shows the reviewer's name and decision, and bots are labeled as bots.

Before merging, it's worth checking that at least one approval came from a person who looked at the change, ideally someone other than whoever requested the agent's work. Approvals from people without write access don't count toward requirements at all [7].

A review of an earlier version isn't a review of what's about to merge. If an approval was dismissed by a later commit, the timeline shows that too.

Approving only what can be explained

Kubernetes, one of the largest open-source projects, holds contributors fully responsible for every change in an AI-assisted pull request [8]. Its policy lets reviewers ask about AI-assisted code and closes pull requests whose authors can't explain why a change was made [9].

The same standard works for approving. If a reviewer can't explain what a change does and why it's safe, approving it passes the risk along without anyone owning it.

For non-developers, explaining doesn't mean reading every line. It means being able to say what the change does for users, which files it touches, and how it was checked. When any of those is unclear, a question is the right review.

Closing an AI pull request

Closing an agent's pull request is a normal outcome. Agents can try again in minutes, so an attempt that misread the task, wandered out of scope, or isn't worth reviewing costs very little to discard. The pull request and its branch stay available if anyone needs them later.

A closing comment explaining what went wrong makes the next attempt better, whether the agent tries again or a person picks up the task. Closing also keeps the list of open pull requests honest about what's actually in progress.

The habit to avoid is merging something just because it exists. An approval earned by persistence rather than quality is how problems slip into a project.

A checklist before approving

A short, consistent routine makes AI pull requests manageable. Before approving, check that:

  • The description matches what the files actually change
  • The scope fits the request, with no unexplained workflow, dependency, or database files
  • The checks that matter actually ran and passed
  • The result was tried, through a preview or screenshots
  • The change can be explained in a sentence or two

None of these requires reading code line by line. Together, they cover the most common ways agent work goes wrong: doing more than asked, passing checks that tested nothing, and looking right without being right.

Writing the checklist into the repository's pull request template keeps it in front of every reviewer, so the routine doesn't depend on memory.