When AI Reviews AI, “Time to First Review” Stops Meaning What You Think
GitHub is pushing parallel coding agents while new research finds 248,641 AI-authored pull requests reviewed by AI. The old latency metric now needs a subject.
By Ahmad Hajjar
On September 3, 2026, GitHub published a guide to running several Copilot agents at once. Each agent works in an isolated Git worktree, so developers can start multiple tasks in parallel and spend their time, in GitHub's words, "reviewing and making decisions."
That changes more than code generation. It changes what a fast code review metric means.
A pull request can now receive an automated review within seconds. The dashboard turns green. The human who owns the decision may not have looked at it yet.
AI is now present on both sides of the pull request
The shift is already visible in research.
On August 21, researchers Niruthiha Selvanayagam and Taher A. Ghaleb published AI-to-AI Code Reviews of GitHub Pull Requests. They identified 248,641 AI-attributed pull requests that received at least one AI-attributed review. Of those, 45,269 received a review from a different AI product and 208,145 received a review from the same product.
The authors describe this as a "closed loop" in which one AI agent reviews another agent's contribution. They also found very short observed median review latencies: 1.2 minutes for cross-product pairs and 4.7 minutes for same-product pairs, while warning that incomplete timestamps and reviewer composition limit the comparison.
A familiar engineering metric has become ambiguous. "First review" used to be a reasonable proxy for "someone picked this up." It can now record an automated response that happened before any human attention.
A fast first review can describe three different systems
A median first-review time of two minutes could mean:
- maintainers respond almost immediately
- an AI reviewer comments immediately and humans respond later
- non-AI automation records a review event before any judgment happens
Those are operationally different systems. Combining them into one number hides the distinction that engineering leaders need.
This matters because the action depends on the cause. A slow human pickup time may point to unclear ownership or overloaded reviewers. A fast automated pickup followed by a long wait for approval may point to a new bottleneck after the bot. A fast automated review followed by a fast merge may still raise a governance question: where did accountable human judgment happen?
No single number answers all three.
Public GitHub organizations already look very different
GitQuick currently publishes dashboards for 20 open-source GitHub organizations. The table below uses their latest rolling analysis runs, completed between September 2 and September 7, 2026.
The AI review share is the percentage of recorded review events attributed to known AI-review accounts. Bot review share includes AI reviewers plus other automation such as dependency and workflow bots.
| Organization | AI review share | All bot review share | Median first review | Reviews measured |
|---|---|---|---|---|
| Omacom | 68.8% | 69.0% | 2 min | 3,055 |
| 37signals | 45.7% | 46.6% | 2 min | 5,597 |
| OpenAI | 35.9% | 36.7% | 12 min | 11,279 |
| Google Cloud | 25.6% | 31.3% | 3 min | 7,172 |
| Microsoft | 22.6% | 41.9% | 1.0 h | 112,494 |
| 5.8% | 9.1% | 2.9 h | 7,467 | |
| Anthropic | 2.2% | 3.1% | 1.8 h | 2,079 |
| AWS | 1.4% | 21.2% | 1.2 h | 8,513 |
| Adobe | 0.7% | 14.6% | 17 min | 3,154 |
| Apple | 0.0% | 0.0% | 4.3 h | 1,771 |
Automation explains part of the difference, but it does not explain everything. Apple has no detected bot reviews in this window and still reaches a median first review in 4.3 hours. AWS and Adobe add another complication: both have substantial bot review activity, but very little of it is classified as AI review.
A first-review median therefore cannot be compared across organizations, or across an automation rollout, without checking who generated the first event. Teams need the human, AI, and other-bot split beside the latency number. Otherwise a faster result may reflect quicker automated feedback, quicker human attention, or a different mixture of the two.
Measure human attention separately from automated activity
If AI reviewers are part of your workflow, start with four questions.
1. Who produced the first review event?
Separate human, AI, and other bot reviews. Otherwise the adoption of an automated reviewer can make latency appear to improve overnight even when human response time is unchanged.
2. What happened after that event?
Measure time to approval and time from approval to merge. A quick automated comment does not tell you whether the pull request progressed through the rest of the review lifecycle.
3. Did review coverage change?
Track pull requests merged without a qualifying human review or approval. Review activity is not the same as review coverage, and neither proves review quality.
4. Did the change persist?
Compare the same organization across analysis windows. A one-week improvement may be a release cycle, a holiday, or a temporary backlog cleanup. A persistent shift deserves a process explanation.
This is the point of GitQuick's analysis history and comparison views. They show whether a workflow change improved throughput, moved the bottleneck to another stage, changed the long tail, or merely changed which account generated the first event.
What GitQuick can and cannot tell you
GitQuick analyzes pull request metadata. It classifies review accounts as human, AI, or other automation using account-login patterns, then shows that split alongside latency, review coverage, approval, throughput, backlog pressure, and reviewer load.
It does not read source code, judge whether a review comment was correct, or currently identify whether the pull request itself was authored by an AI agent. That means GitQuick cannot detect the complete AI-to-AI loop described in the paper.
It can expose one side of the loop that most aggregate dashboards flatten: whether measured review activity came from people or automation, and whether the rest of the delivery process improved with it.
The metric did not become useless. It became conditional.
Time to first review still matters. But it now needs a subject.
Time to first automated review measures how quickly tooling reacts. Time to first human review measures how quickly accountable attention arrives. Time to approval and merge show whether the pull request actually moved.
Teams adopting parallel coding agents should record a baseline before the rollout, then compare the same stages afterward. More pull requests and faster bot responses are activity gains. The delivery gain appears only if review coverage, human attention, throughput, and the long tail improve with them.
The dashboards below are public and require no GitHub installation:
For the underlying stage definitions, read Your Cycle Time Is One Number. Your PR Pipeline Has Four Stages. For the difference between AI and bot review activity, read Review Depth Is Now an Organization Setting.
See who is reviewing your pull requests, and what happens next →
Disclaimer: This analysis uses public GitHub metadata and the named primary sources. Reviewer classification is based on account-login heuristics and can misclassify accounts that do not follow common naming patterns. Review counts measure review activity, not review quality. Public showcase windows roll over time, so current dashboards may differ from the figures captured on September 8, 2026. GitQuick is not affiliated with or endorsed by GitHub or any organization mentioned.