Tell HN: OpenClaw is getting ~75 pull requests an hour

6 points by petetnt 73 days ago | 3 comments

Someone mentioned in a previous HN thread related to the topic this week that OpenClaw had absolute staggering amount of issues and pull requests open.

https://github.com/openclaw/openclaw/pulls

I have been following the repo this week and it seems that the situation has only accelerated. In the beginning of the week the repo was getting around 25 PRs per hour, now the rate is closer to 100 per hour.

I haven't pulled accurate statistics, but quick look and napkin math shows that this is hundreds of thousands lines of code sent to review every day. With the struggling GitHub tooling you can see that so far in the past 7 days 4663 PRs were opened, and 653 of those were merged, generating around quarter a million added lines. This month (1.-6.3.) the project has consumed 765031 build minutes, 531 days worth of compute. And like mentioned, this is only accelerating daily.

What do you think about this future of open source software development?

Horos 73 days ago |

Something worth sitting with, rather than a conclusion:

As PR velocity reaches this scale — 100 per hour, hundreds of thousands of lines a day — I find myself wondering about the collective immune system side of this.

If we're not yet organized around injection and obfuscation at the community level, PR saturation itself becomes a distinguishable attack vector — and not just for backdoors.

Two distinct risks worth separating:

Offensive saturation: flood a competitor or a fast-moving startup with automated PRs. Their human review bandwidth collapses. Real community contributions drown in noise. The project slows, maintainers burn out, momentum dies. No backdoor needed — attrition is enough.

Forced opening: a project overwhelmed by volume lowers its review standards to survive. It merges faster, checks less. The saturation wasn't meant to block — it was meant to open. Once standards drop, real injection becomes trivial.

The unsettling part: this vector requires no particular skill, is already available, and is organically indistinguishable from legitimate viral growth. To envision an open source that survives AI, maybe we need to envision an open source AI that protects open source.

Genuinely curious if others are thinking about this, and whether anyone has seen serious work in this direction already.

gus_massa 73 days ago |

Too lazy to look.

How many are duplicates? How many are good?

I guess open source will be fine, but I'm worry that new contributors will have a hard time to get notices in the sea of automatic pull requests.

Horos 73 days ago | |

And to put it plainly: we won't be able to manage LLM-generated contributions without LLMs. It's physically impossible at this scale.

Which means the immune system has to be built from the same substrate as the threat. The question isn't whether to use AI for review — it's whether that review layer will be open, distributed, and community-owned, or closed, centralized, and controlled by whoever gets there first.

But there's a layer above that which is easy to skip over: human supervision.

Not line-by-line review — that's already gone. What remains is supervision of curated logs, at ratios that might look something like 1 in 10^10. The human role is no longer technical production. It's oversight. And that's a genuinely new function that we don't have good tools for yet.

The flow is perpetual. It doesn't stop, it doesn't slow down, it only accelerates. Which means we'll need to build tooling specifically designed to absorb volume, abstract it into supervisable signals, and train us to work at that level of abstraction — where the unit of human attention is no longer a line of code or a PR, but a pattern across millions of automated actions.

Automation isn't the threat to manage. It's the only viable response to production at this frequency. The question is whether we build the abstraction layer deliberately, as a community, before someone builds it for us.