AI Code Review Is Faster. What Happens After Changes Requested?
Claude Code Review went generally available on October 15. Here is how to distinguish review activity, change requests, and later approvals.
By Ahmad Hajjar
On October 15, 2026, Anthropic announced that Claude Code Review is generally available. The company says most reviews now take 6–10 minutes, down from roughly 20 minutes during the research preview.
That is a useful improvement in feedback speed. It does not answer a different question: after a reviewer asks for changes, what happens next?
For teams evaluating AI code review, the next useful measurement is not simply how many reviews arrive. It is whether requested changes receive follow-up, and what that follow-up actually establishes.
Historical product illustration: AWS analysis dated August 23, 2026. The October figures below come from separate API snapshots, not this screenshot. The headline Re-review Rate tile is not the conditional approval-follow-up percentage defined below.
What shipped, and what it does not decide
Claude Code Review is available to Team and Enterprise customers. Administrators can choose Quick, Standard, or Deep review effort for each repository. Anthropic describes the feedback from its preview as a request for reviews that were “quieter, sized to each change, and faster.”
The product documentation also draws an important boundary:
“A review never approves or blocks the pull request”
An AI finding, a formal changes-requested review, and an approval are different records. A tool can provide useful findings without submitting a blocking review. Conversely, an approval is a workflow decision, not evidence that every possible defect was found.
That means a formal review-state metric cannot measure every interaction with an AI reviewer. It can still help investigate how a team's recorded review decisions progress.
The follow-up problem is older than this launch
In a GitHub Community discussion dated March 16, 2026, mbenzakis described repeated Copilot feedback after fix pushes and argued:
“Fix pushes should only verify fixes”
That is one user's report about another product, not a benchmark or evidence about Claude's current behavior. But it describes a recognizable process question: is the next review verifying a requested fix, identifying a genuinely new problem, or repeating work?
Counting additional reviews cannot distinguish those cases. Neither can counting comments. Teams need to inspect the sequence of decisions and changes on individual pull requests.
Define three different quantities
Start with three units that are easy to confuse.
Submitted review events count review submissions classified as Approved, Changes Requested, or Commented. A single pull request can have several submissions. These are not individual inline comments, and they are not necessarily distinct revision cycles.
Pull requests with changes requested count distinct PRs with at least one recorded CHANGES_REQUESTED review. Repeated requests on the same PR do not increase this denominator.
Later-approval share asks how many of those PRs have an APPROVED review submitted after their first recorded change request. Divide that count by the number of PRs with changes requested.
This last definition follows the public API's rereview fields. It is deliberately narrower than “issues resolved.” The approving reviewer need not be the person who requested changes. The comparison uses the first request, not the latest one. A PR can qualify even if another change request follows its approval.
What two public snapshots show
The following values were retrieved from the AWS API snapshot and GoogleCloudPlatform API snapshot on October 17, 2026.
| Public organization | Changes-requested review events | PRs with changes requested | PRs with a later approval | Later-approval share |
|---|---|---|---|---|
| AWS | 217 | 155 | 92 | 59.35% |
| GoogleCloudPlatform | 167 | 123 | 82 | 66.67% |
AWS run 564 covers September 15 at 03:00 UTC through October 15 at 03:00 UTC. GoogleCloudPlatform run 566 covers September 15 at 05:01 UTC through October 15 at 05:01 UTC.
The first distinction is between events and PRs. AWS's 217 change-request submissions concern 155 distinct PRs. Treating those 217 submissions as 217 separate fix-and-review cycles would overstate what the data establishes.
The second distinction is between a later approval and a final resolution. AWS's 92 qualifying PRs produce 92 / 155 = 59.35%. That does not mean the remaining PRs failed review. They may still be open, have been closed without merging, or lack a qualifying approval in the observed data.
These are different organizations with different repository mixes and policies. The percentages are not a ranking. Their windows also end on the launch date. They are examples of measurement, not a before-and-after evaluation of Claude or evidence that either organization uses it.
Use the metric to select PRs for inspection
For a practical investigation, choose one repository and a consistent observation window.
First, separate PRs that are still open from those already merged or closed. Recent PRs have had less time to receive follow-up. Comparing them directly with older PRs can distort the interpretation.
Second, inspect a sample with change requests but no later approval. Check whether the author pushed a fix, whether a reviewer returned, and whether the PR was intentionally abandoned. Those imply different actions.
Third, inspect qualifying PRs too. Did the approval address the requested change? Was it from another reviewer? Did a later request remain outstanding? A favorable aggregate should not end the investigation.
Finally, keep automated findings separate from formal review decisions where the underlying records allow it. See why AI review changes the meaning of first-review timing and how to evaluate whether a review process improved.
GitQuick's Metrics view includes Review Activity Breakdown, separating submitted reviews by state. The public showcase API adds the conditional follow-up counts used here, giving teams a starting point for inspecting the underlying workflow.
Faster feedback matters. Whether the team acts on it and verifies the result is a separate question worth measuring.
Inspect the public examples
The dashboards are public and require no GitHub installation:
See your submitted review activity and approval patterns
Disclaimer: This analysis uses public GitHub metadata and the primary sources linked above. Review events and later approvals measure recorded workflow activity, not code quality, issue resolution, or causal effects of AI tools. Missing or unrecorded activity can affect interpretation. The table does not classify reviewers as human or automated; account-name heuristics used elsewhere in GitQuick can misclassify accounts. GitQuick is not affiliated with or endorsed by Anthropic, GitHub, AWS, Google, or the organizations mentioned.