Who is accountable when an AI-generated pull request causes a bug in production?

The human who approved and merged it. A tool can't carry responsibility, so the policy should say that the approving reviewer owns the outcome whoever or whatever wrote the code. The Linux kernel takes the same line for patches written with AI help.

Should developers disclose that a pull request was written by AI?

Yes. It costs one checkbox or one commit trailer, and it tells the reviewer to look for the mistakes AI makes, such as packages that don't exist, tests that only confirm what the code already does, and changes nobody asked for.

Reviewing AI-Generated Pull Requests: Policy and Checklist

Q: Can Copilot approve pull requests on GitHub?

Yes, since September 1, 2026, in public preview. It's off by default. When an admin turns it on, a Copilot approval counts toward the repository's required-approvals rule, and repository admins can limit it to chosen file paths.

Lines of code on a dark editor screen Image: Unsplash, used under the Unsplash License.

If the person who opened a pull request can't tell you why a line changed, the pull request isn't ready. That holds however clean the diff looks and however green the checks are. It's the whole policy in one sentence; the rest of this page is the checklist that enforces it, a policy you can paste into your handbook, and one GitHub setting worth checking this week.

The sentence got its best airing in May, as a joke. A post on r/ClaudeAI titled "Reviewing AI-generated pull requests in 2026" showed a mock rejection letter for pull request #4471. The reviewer had read a 4,000-line diff, admired "Claude's commitment to refactoring code that was working fine yesterday", asked why one change was made and got back "the AI thought it would be cleaner." The letter signs off: "I look forward to reverting your commits soon." It collected about 3,800 upvotes. Commenters pointed out that the image carries the logo of Limestone Digital, an AI company, and that the poster's account was ten days old, so treat the post as an ad. The replies are the useful part. "This needs to happen in businesses. Ai should be used appropriately," wrote u/florodude. Another commenter described a Deloitte managing director who "wants his teams to merge slop by letting Claude review PRs" (u/Long-Possibility-951). And the counterpoint, from someone who has worked in banking software: "Claude's code is usually better than most of the banking software code i've seen in the last 25 years" (u/yopla).

https://www.reddit.com/r/ClaudeAI/comments/1teuh5w/reviewing_aigenerated_pull_requests_in_2026/

Both camps can be right. The code may well be good; the problem is a merge nobody vouched for.

Who needs this

Any team where some pull requests are mostly written by Copilot, Claude Code, Cursor or an autonomous agent. The review gap is real and measured. A study posted in May 2026 for the EASE 2026 conference looked at 33,596 agent-authored pull requests on GitHub from the AIDev dataset: 61% had no recorded review at all, and 84% either had none or were reviewed only by other agents. In repositories where humans opened pull requests too, the agents' work got some review about as often as people's did, but a human-only review was still about three times rarer for it.

Table 1 of the arXiv paper "These Aren't the Reviews You're Looking For": review presence and reviewer composition for 33,596 agent-authored pull requests, with 61.38% receiving no review Screenshot: Table 1, Duma et al., "These Aren't the Reviews You're Looking For", arXiv.

If your repositories look like that, this policy is for you. If every pull request already gets a careful human review, you need only the disclosure rule and the GitHub setting below.

The 9-point AI pull request review checklist

Run it on any pull request flagged as AI-assisted. The first three are pass/fail; the other six are where AI code tends to fail.

Accountability is clear. A named human is the approver and knows they own the merge.
AI help is disclosed. A checkbox in the PR template, or a commit trailer in the style the Linux kernel uses (Assisted-by: <tool>), so the reviewer knows what to look for.
The author can explain it. Ask one "why" question about a non-obvious line. If the answer is "the AI did it", send it back.
Packages and APIs exist. Look up every new dependency and unfamiliar call in the real registry or docs. A study of 16 code-generating models and 576,000 samples found the average share of hallucinated packages was at least 5.2% for commercial models and 21.7% for open-source ones, and a made-up package name is one an attacker can register.
The logic is right on the edges. Trace one real input by hand, including the empty, null and largest cases.
Tests check intent. A test that asserts whatever the code currently returns proves nothing. Ask whether it would fail if the logic were wrong.
Security checks work. Treat anything touching authentication, authorization, data access or outbound calls as unreviewed until a human has traced it.
No secrets, no pasted licensed code. Scan for keys and for large blocks that look copied from elsewhere.
Scope matches the ticket. Unrequested refactors of working code (the #4471 problem) get split out or dropped.

Where AI-generated code slips through

Failure mode	Why it slips through	What to do
Package or API that doesn't exist	The name looks plausible	Check the registry and the official docs
Plausible but wrong logic	It reads fluently	Trace a real input, test the boundaries
Security check that doesn't hold	The line is there, so it looks handled	Review security code as if unreviewed
Tests that only pass	Assertions copy the code, not the requirement	Break the logic and see if a test fails
Scope creep	"Helpful" refactors ride along	Split unrelated changes out
Comment says one thing, code does another	Reviewers read the comment	Trust the code

Code for a React router configuration on a dark screen Image: Unsplash, used under the Unsplash License.

Check this GitHub setting: Copilot approvals

On September 1, 2026, GitHub let Copilot code review approve pull requests. It's off by default and in public preview on the Pro, Pro+, Max, Business and Enterprise plans. Once an admin turns it on, a Copilot approval counts toward the repository's required-approvals rule, the same way a teammate's does. A new commit dismisses it, as it would a human's.

GitHub changelog of September 1, 2026, section "Turning on approvals": Copilot can submit an approval that counts toward the repository's required-approvals rule Screenshot: "Copilot code review can now approve pull requests", GitHub Changelog, September 1, 2026.

Admins control it at three levels: enterprise, organization and repository, and a repository admin can choose which file paths Copilot may approve. GitHub's own documentation still says Copilot "is not guaranteed to spot all problems" and tells you to "supplement Copilot's feedback with a human review".

We'd keep it off for any path that touches auth, payments, data access or infrastructure. If you want the speed, allow it only on low-risk paths such as docs and test fixtures, and write the list into the policy so nobody widens it quietly. Whatever you choose, look today: an org-wide "on" means one bot approval can now merge into a branch that requires one approval.

The copy-paste policy

The Linux kernel already wrote the core rule for patches made with AI tools. AI agents must not add the Signed-off-by tag, because only a human can certify the Developer Certificate of Origin, and the human submitter is responsible for "reviewing all AI-generated code" and "taking full responsibility for the contribution". The template below applies the same idea to a company repository.

Linux kernel documentation, AI Coding Assistants page: AI agents must not add Signed-off-by tags; the human submitter reviews all AI-generated code and takes full responsibility; Assisted-by tag format Screenshot: "AI Coding Assistants", Linux kernel documentation (docs.kernel.org).

Adapt the bracketed fields. One page is enough for a small team.

[Company Name] AI-Assisted Code Review Policy

Accountability. The engineer who approves and merges a pull request owns its outcome, whether a person or an AI tool wrote the code. AI tools can't be the accountable approver.

Disclosure. Authors mark a pull request as AI-assisted when an AI tool wrote a substantial part of it, using [the PR template checkbox / an Assisted-by: commit trailer].

Explainability. Authors must be able to explain any code they submit. Code the author can't explain isn't ready to merge.

Review standard. AI-assisted pull requests are reviewed against the 9-point checklist. Changes to authentication, authorization, data access, payments or external services always get a human review.

Tests. AI-assisted changes include tests of intended behavior. The reviewer confirms a test would fail if the logic were wrong.

Automated review. AI review tools may comment as a first pass. Copilot approvals (or any bot approval that counts toward required reviews) are [off / allowed only on these paths: docs/**, test/fixtures/**]. Changes to this list need [role]'s sign-off.

Size. Pull requests over [N] changed lines are split before review unless [role] agrees otherwise.

How to adapt it

Make the cheap pull requests cheap and spend people on the risky ones. Cap size, because an assistant writes a huge diff as easily as a small one, and only the small one gets read properly. Have the author run the checklist before asking for review. Sort by what the code touches, not by who wrote it: a README edit doesn't need the scrutiny an auth change does. Let AI reviewers flag style and missing tests so the human can spend the time on logic and security.

If you have one engineer, the policy shrinks to the disclosure trailer and a rule that you re-read AI-written diffs a day later before merging. If you run several orgs on GitHub Enterprise, set Copilot approvals at the enterprise level so a single org can't switch them on alone.

What it doesn't cover

Which coding tools you allow and what data they see: that's the AI coding tools governance policy. Agents that run unattended and open pull requests overnight need their own permissions and logging rules: see governing unattended AI coding agents. Licence compliance beyond a basic scan, and the budget side, which the cost control guide covers.

We didn't test Copilot approvals ourselves; the setting description above is GitHub's changelog and documentation on the day we checked, and it may change while it's in preview.

Checklist (copy/paste)

Policy says the approving human owns every merge
PR template or commit trailer for AI disclosure
Authors must be able to explain submitted code
9-point review checklist adopted for AI-assisted PRs
Copilot approvals checked at enterprise, org and repository level; off or limited to listed paths
Security-touching changes always get a human review
New dependencies looked up in the real registry
PR size cap set

Correction, October 15, 2026: An earlier version said the r/ClaudeAI thread was popular "because every team is hitting the same wall"; it's a joke image post that commenters flagged as an ad, described above as it is. It also said arXiv banned papers with unchecked AI errors in May 2026; arXiv's rule bars authors for a year, and we removed the comparison. The new version adds GitHub's September 1 change to Copilot approvals.