It's not unreasonable to imagine thousands of commits per second to the kernel, especially if you consider that bots might be watching LKML and applying patches to various forks.
> Handling thousands of git pushes per second implies thousands of issues, thousands of PRs, tens of thousands of comments, thousands of Actions runs, and dozens of releases. How's that part of their infra going to scale?
For each issue my agent might raise 5 independent PRs as experiments.
Further, the more changes there are, the more important it is that they don't conflict, which means smaller changes, which means even more changes.
Bots interleaving typos, single line whitespace fixes, single dependency bumps, etc.
Companies pay GitHub for enterprise repositories. It’s not completely wild that a 2026 large scale company would have the same scale as 2016 Google…
I'm starting to think AI isn't a productivity machine, but rather a machine for hypnotising people into the false belief of productivity.
The only conceivable scenario that I can imagine leading to this volume of writes is a push-based GitOps repository for a huge cluster holding a large volume of apps, each one with many services. Each commit in one if these services triggers a commit to the gitops repo to update the reference to the new container image, which in turns triggers a deployment update.
There is no software project on earth that justifies a rate of changes in magnitudes of dozen of commits per second. This is a symptom of a huge problem, not a sign of times. Even in monorepo mania this sort of thing is inconceivable.
But that's also what you get with vibecoding: lots of output from people who do not have a clue about what they are doing.