AI Pull Request Review: Use Review Events as Evidence, Not a Quality Score
A new survey finds higher evidence demands for AI-authored pull requests. Learn how to read review events without mistaking activity for verification quality.
By Ahmad Hajjar
The October 15 preprint Plausible Is Not Enough: Trust and Evidence in AI-Authored Pull Request Review surveyed 239 practitioners in 31 countries. Among its respondents, 64.9% reported lower initial trust in AI-authored pull requests than in human-authored pull requests. Another 61.1% reported higher evidence requirements.
The chart shows submitted GitHub review-event states in three public snapshots. It does not identify AI-authored pull requests or measure review quality.
The study is timely because AI-generated code can look complete before a reviewer has enough evidence to approve it. The practical question is not whether a pull request received more review activity. It is whether someone verified the change and accepted responsibility for the decision.
What the study measured
The researchers used matched questions about human-authored and AI-authored pull requests. This within-respondent design let each participant compare the evidence they would expect in the two cases.
The results describe reported judgment, not observed behavior in production repositories. The paper did not classify GitHub pull requests, inspect defects after merge, or measure whether a particular review process prevented incidents.
Several reported differences still matter for review policy:
- 64.9% rated their initial trust in AI-authored pull requests lower.
- 61.1% reported higher evidence requirements for AI-authored pull requests.
- 43.9% would block an AI-authored pull request when uncertainty remained, compared with 19.4% for a human-authored pull request.
- Unclear ownership was more likely to pause an AI-authored pull request review, 29.3% compared with 14.6%.
The authors describe the problem as “an evidence-ownership problem.” They argue that review tools should “make uncertainty visible before approval.”
Those are survey findings from one preprint. They are not universal adoption rates or proof that every AI-assisted change needs the same control. They support a narrower conclusion: teams should define what evidence an approval represents.
Review events are activity, not proof
GitHub records submitted reviews with states such as APPROVED, CHANGES_REQUESTED, and COMMENTED. GitQuick aggregates those states in its Review Rounds metric.
For a selected analysis window, GitQuick calculates:
- total submitted review events;
- counts for approved, changes requested, and commented states;
- each state’s share of all review events;
- average review events per pull request.
The average uses every pull request in the run as its denominator, including pull requests with no submitted review. A COMMENTED review is a submitted review event, not a count of every inline comment. The metric also does not reconstruct a clean sequence of first round, second round, and final round.
This boundary matters. Five review events can mean careful verification, repeated requests for missing context, automated noise, or several reviewers submitting separate assessments. One approval can follow extensive offline testing. Event counts alone cannot distinguish those cases.
Use Review Rounds to describe visible workflow activity. Do not turn the total or the approval share into a quality score.
What current public review activity looks like
GitQuick’s public Showcase listed 21 organizations when the following data was fetched on November 4, 2026. The table uses three runs that ended that day and covers October 4 to November 4.
| Organization | PRs in run | Review events | Avg events per PR | Approved | Changes requested | Commented |
|---|---|---|---|---|---|---|
| Adobe | 2,286 | 2,391 | 1.05 | 50.4% | 3.0% | 46.6% |
| Anthropic | 3,531 | 1,163 | 0.33 | 74.5% | 1.2% | 24.2% |
| Apple | 1,252 | 2,168 | 1.73 | 48.2% | 3.3% | 48.5% |
The percentages are shares of submitted review events, not shares of pull requests. One pull request can contribute several events. A pull request with no submitted review contributes to the average-per-PR denominator but not to the event-state percentages.
The rows are examples, not rankings. These organizations have different repositories, contributor models, automation, and branch policies. The data does not reveal which pull requests were AI-authored. It also cannot show whether a reviewer inspected tests, executed the code locally, checked project context, or resolved every uncertainty.
That is why a higher average is not automatically better, and a higher approval share is not automatically safer.
Define the evidence before measuring the workflow
A useful AI pull request policy starts with observable requirements.
First, define disclosure. Decide what qualifies as AI-assisted work and how a contributor records it. Missing disclosure should remain unknown rather than being silently classified as human-authored.
Second, define approval evidence. Depending on the repository, that can include:
- named tests and their results;
- a short explanation of the behavior verified;
- links to CI, security, or performance evidence;
- a responsible human owner;
- human review for protected paths or high-risk changes;
- an explicit note for unresolved assumptions.
Third, keep the evidence in a durable location. Pull request descriptions, checks, review summaries, and linked artifacts can be audited later. Evidence left only inside an agent session is invisible to repository analytics and future maintainers.
Measure policy adoption without claiming quality
After defining the policy, track several independent signals.
Review-event mix shows how approval, change-request, and commented activity changes. Re-review rate shows whether some approval occurred after the first changes-requested review, but it does not prove that the same reviewer returned or that every issue was resolved.
Merged-without-review and merged-without-approval measures expose visible coverage gaps. Bot and AI review shares show who generated recorded review activity. AI reviews are a subset of bot reviews in GitQuick, so the two percentages are not equivalent.
Segment the results by repository and stable time window. Inspect real pull requests before changing branch protection or reviewer allocation.
GitQuick exposes Review Rounds in Metrics and compares the event-state mix between analyses in Compare. It does not identify AI-authored code, inspect test execution, recover agent-session reasoning, or grade review quality. Use it to locate workflow changes, then verify the evidence in GitHub.
Takeaway
The new study reports a higher evidence bar for AI-authored pull requests among its respondents. Repository review events can show where approvals, change requests, and comments occurred. They cannot show whether the evidence behind an approval was sufficient.
Define the evidence first. Measure the visible workflow second. Keep quality and accountability judgments attached to the underlying pull request.
For related analysis, read AI Code Review Quality: What Workflow Metrics Can and Cannot Prove and AI Slop in Pull Requests: What the 25% Statistic Actually Measures.
Explore the Adobe public Showcase, compare all public organizations, or try GitQuick on your organization.
Disclaimer: The research figures come from a preprint submitted on October 15, 2026, based on a survey of 239 practitioners in 31 countries. GitQuick Showcase figures use public GitHub metadata for organization-wide windows from October 4 to November 4, 2026, fetched on November 4. Public metadata cannot establish AI authorship, verification quality, code quality, developer performance, intent, or causality. GitQuick is not affiliated with or endorsed by the paper’s authors, GitHub, or any organization mentioned.