A statistical study of PRs opened on openclaw/openclaw | Greptile Blog

Introducing TREX: Greptile Now Runs Your Code.TREX Runs Your Code.<br>Learn More

A statistical study of PRs opened on openclaw/openclaw<br>[ Rahul Bathija | 2026-05-08 ]

Contents<br>Table of Contents<br>No sections found

navigation|BlogA statistical study of PRs opened on ope...<br>Table of ContentsTable of Contents<br>No sections found

I'm Rahul, and I work at Greptile, where we build AI agents that review pull requests. Greptile reviews PRs for OpenClaw which became the fastest-growing repo in GitHub history almost overnight. That gave us a front row seat to something strange.

Last December, OpenClaw was getting two pull requests a week. By February, that number jumped to 3,400/week. Before the spike, ~48% of PRs got merged; after, fewer than 9.3% of PRs got merged.

Many of those PRs were low-effort slop which were often generated by people's AI coding agents. For example, one contributor submitted 106 PRs in a single day, with the median time between submissions being three seconds.

In many ways, openclaw/openclaw offers us a preview of what the future of open source contribution may look like. Here are three observations:

PRs will require sender reputation

PR spam today looks like email spam in the early 2000s.

When I first looked at the OpenClaw data, the pattern reminded me of email. In 2000, the ILOVEYOU worm infected 45 million computers in 24 hours because the cost of sending email approached zero and people trusted the platform. As a result, people were receiving a much higher volume of emails, and some of them were malicious. Those same parameters apply to PRs today.

The first fixes are similar: blocklists to manage volume, and confidence-based filters and reputation infrastructure to catch bad actors. Today, whether your email reaches its recipient's inbox comes down to two things: who you are, and your sending history.

Contributors on OpenClaw are already being filtered by their reputation: 8.2% merge rate for first-timers, 10.3% for contributors with 2-5 PRs, 18.6% for 5+.

Mitchell Hashimoto created and maintains Ghostty, one of the most popular open source terminal emulators. As the project gained momentum, people submitted such a high volume of AI-generated PR slop that he needed to limit AI-generated contributions.

A week later, he released a solution: Vouch, a trust management system for open source contributors. Unvouched users can't contribute, and bad actors get explicitly flagged. While Vouch is project-specific for now, Mitchell's vision is for trust decisions to eventually ripple across projects that share similar values. Vouch is the open source equivalent of a sender reputation score. (Worth noting: while Vouch was working well for Ghostty, Mitchell decided to take Ghostty off GitHub.)

More contributors won't help if they all think the same way

Linus Torvalds has a famous line: "Given enough eyeballs, all bugs are shallow."

Having more eyes on the same problem brings diverse perspectives. Different people use software differently, encounter different bugs, and approach fixes in novel ways.

That rule might not hold when everyone converges on Claude / Codex / Cursor / Devin etc. In OpenClaw:

4 contributors submitted PRs with the exact title "feat(web-search): add SearXNG as a search provider." They were 4 of 10+ people who independently tried to add the same feature.

6 people independently fixed the same Brave Search locale bug. 2 submitted PRs with identical titles 94 minutes apart.

5 people independently found the same timeout deadlock in the agent runner.

There are more eyes on OpenClaw than ever, but their perspectives are also being filtered by AI coding agents. If most contributors use the same AI coding agents with the same prompts, then their contributions will resemble each other as well.

The promise and advantage of open source has been diversity of thought. Linus's law only holds if the underlying thinking remains diverse too. A contributor who really studies a codebase will prompt differently than one who doesn't.

What's actually getting merged

In the OpenClaw PR data, features have a 9% merge rate, while refactors merge at 35%.

The contributions requiring a deep understanding of the existing codebase outperform novel feature contributions by nearly 4x. It's the common adage these days; the thinking matters a lot more than the typing. The data backs it up.

For example, the way claude-mem maps Claude Code's hook-captured tool stream into its own resumable Agent SDK observer session is a non-obvious architectural choice that requires a deep understanding of both systems. A software developer who understood this decision would be able to distill it into a checklist, which would become the prompt that makes the agent's output significantly better. An agent prompted to "build a memory system" wouldn't be able to achieve that on its own.

Until 200 years ago, the people who designed buildings also...