We Analyzed 10,000+ OSS Pull Requests from AWS and GoogleCloudPlatform. Here's What Their Review Pipelines Reveal.

I compared AWS open source with GoogleCloudPlatform using GitQuick's Compare Analysis: same one-month window, same public GitHub metadata, same review-process metrics.

The result is not a simple "AWS is better" or "GCP is better" story.

It is more interesting than that.

GoogleCloudPlatform looks optimized for speed. AWS looks optimized for control.

And if I had to choose which signal matters more for a serious engineering organization, I would pick control.

GCP wins the happy path

Let's be fair: GoogleCloudPlatform is fast.

In this dataset, GCP handled 6,559 PRs compared to AWS's 3,645. It opened more PRs per week, merged more PRs per week, responded slightly faster at the median, and merged faster at the median.

That is not a slow organization. That is a high-throughput machine.

But high throughput is not the same thing as a healthy review system.

The median path tells you what happens when things go well.

It does not tell you whether the process is safe.

AWS wins the control layer

The stronger signal is not median merge speed.

It is this:

AWS has fewer unreviewed merges, faster approvals, better long-tail review control, and slightly more reviewers per PR.

That matters.

Because a review pipeline is not only judged by how fast the easy PRs move. It is judged by what happens when the system is under pressure.

Approve or Comment, That Is The Question

AWS looks more approval-driven. GCP looks more comment-driven.

That difference shows up clearly in the review breakdown:

GCP has a lot of activity. AWS has more explicit review resolution.

That is the part I would not ignore.

Comment-heavy review is not automatically better

A common engineering trap is to confuse discussion with review discipline.

A PR thread can be active and still not have a strong review gate.

GCP has more comment-heavy review activity and a higher re-review rate. That can mean healthy collaboration. It can also mean the process loops more before reaching a clear decision.

AWS, by contrast, seems to push PRs toward approval faster.

That does not prove better code quality. GitHub metadata cannot prove that.

But from a process-health perspective, AWS looks cleaner.

Less ambiguity. Faster approval. Fewer unreviewed merges. Better tail behavior.

That is what a governed review pipeline looks like.

The Invisible Automations

There is one caveat, and it is important.

GitQuick's current bot heuristic marks AWS as having much higher bot review activity:

• GCP bot reviews: 0.9%
• AWS bot reviews: 13.0%

But the GCP reviewer leaderboard tells a more complicated story.

GCP's top reviewers include:

• gemini-code-assist - 1,214 reviews
• codebot-robot - 849 reviews

Those are clearly automation-like or AI-assisted accounts, even if they do not match the simple bot-detection heuristic.

So the honest conclusion is not:

GCP has no automation.

The honest conclusion is:

Bot detection is no longer enough. Modern review pipelines need AI-assisted reviewer detection too.

This is exactly where PR analytics needs to evolve.

The old world was easy: detect [bot], Dependabot, GitHub Actions, and a few obvious patterns.

The new world is messier. AI reviewers, coding agents, automation accounts, internal bots, and human-operated service accounts all blur the line. (see my previous blog about Microsoft: The Pseudo-Bot Reviewer)

If you only measure "bots," you will undercount the automation layer.

Key Takeaways for GCP

If I were looking at this from the GoogleCloudPlatform side, I would not start by trying to get even faster. GCP is already fast.

I would start with the control signals.

The first question is the 21.9% merged-without-review rate. Maybe many of those PRs are docs, generated code, dependency bumps, bot-created updates, or low-risk changes. If so, fine - but that should be known, not assumed.

The next question is why review activity is so comment-heavy. GCP has a lot of review movement, but only 32% of reviews are approvals, compared to 54% for AWS. That can mean healthy discussion. It can also mean PRs spend too much time in an ambiguous state: looked at, commented on, but not clearly resolved.

So the practical action for GCP would be:

• break down unreviewed merges by repo, PR type, author type, and PR size
• separate acceptable unreviewed merges from risky ones
• classify AI-assisted and automation accounts explicitly
• reduce the gap between first review and approval
• turn meaningful review activity into clearer review outcomes

GCP does not look slow. It looks like a high-speed system where the governance layer deserves closer inspection.

Key Takeaways for AWS

AWS has the stronger governance signals in this comparison, but that does not mean the pipeline is done.

The obvious strength is review control: fewer unreviewed merges, faster approval, better P90 review latency, and more explicit approvals. AWS should protect that. The wrong lesson would be to chase GCP's faster median merge time by weakening the review gate.

But AWS still has improvement room.

The 9.6% merged-without-review rate is much better than GCP's, but it is still worth auditing. If those PRs are generated code, docs, dependency updates, or safe automation, fine. If they include human-authored code changes in important repos, that is a different story.

AWS should also look at where it can reduce low-risk waiting time without losing control. GCP is faster at median first review and median time to merge, so there may be room for better reviewer routing, auto-merge after approval, clearer PR readiness checks, or repo-specific automation.

So the practical action for AWS would be:

• preserve the review gate
• audit the remaining unreviewed merges
• reduce median waiting time where risk is low
• watch automation concentration carefully
• make sure automation supports human judgment rather than replacing unclear ownership

AWS should not try to become GCP. Its advantage in this dataset is not raw speed. It is governed speed. The next step is making that governed path even smoother.

Key takeaways for the rest of us

The lesson for us is not that every team should copy AWS or GCP. Most engineering teams are much smaller, less public, and less complex than either of them. But the signals still matter.

1. Median speed is not enough. A team can look fast at the median while still having weak control at the edges. Always check P90 review latency, P90 approval time, and long-tail merge behavior.

2. Merge-without-review should be a first-class metric. If code is landing without recorded review, that is not a small process detail. It is a governance signal. Maybe it is acceptable in some repos. Maybe it is not. But it should not be invisible.

3. Review activity is not the same as review resolution. Comments are useful, but comments alone do not mean the review process is healthy. Look at approvals, changes requested, re-review loops, and approval-to-merge time.

4. Automation is becoming harder to measure. The old bot heuristics are no longer enough. AI-assisted reviewers, coding agents, service accounts, and internal automation blur the line between human review and machine-assisted review.

5. The best review systems combine speed and control. GCP shows impressive throughput. AWS shows stronger governance signals. The ideal system probably looks like a combination of both: fast response, low unreviewed merge rate, explicit approvals, and controlled long-tail behavior.

See the dashboards

Both dashboards are public and require no signup:

• GoogleCloudPlatform dashboard
• AWS open source dashboard

You can inspect the metrics yourself and disagree with my interpretation. The value is not in declaring a winner. The value is in making the review process visible enough to argue about it with data.

Try GitQuick on your own organization

GitQuick analyzes GitHub pull request metadata and surfaces review-process signals like:

• time to first review
• approval time
• time to merge
• merge-without-review rate
• reviewer load
• bot and automation activity
• backlog pressure
• long-tail delivery risk

Run it on your own GitHub organization and compare the result with what you think is happening inside your review process.

You may find that your bottleneck is not where you expected.

Try GitQuick free →

Disclaimer: this analysis uses public GitHub metadata only. It measures review-process signals, not code quality, architecture quality, security posture, or the internal engineering culture of AWS or GoogleCloudPlatform. GitQuick is not affiliated with or endorsed by AWS, Google, GitHub, or any of the organizations mentioned.