Hacker News
points by crote 1 day ago | 0 comments
Sorry, but thousands of pushes per second, per repository?! In what world could that possibly seem like a sound idea?

Sure, it's nice that you can technically handle it, but to me it sounds like at that point something has gone absolutely horribly wrong in the way you set up your agents. Last time I checked, GitHub was intended as a platform to upstream finished work items, not a realtime cross-agent chat channel.

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?

How about introducing rate limits instead, nudging people to not have agents push every individual single-line changes to GH, but instead have them collaborate as a local cluster and only upstreaming PR-sized chunks of finished work?

If you still need thousands of pushes per second you'd be looking at millions of lines of code, and at that point you're looking at an insane monorepo which is growing at a rate of terabytes per day, and which basically instantly becomes unusable due to being impossible to clone or check out.

[–] clivedup 1 day ago
My understanding is that forks on GitHub share the same storage in the GH backend.

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.

[–] sethev 15 hours ago
A different way of looking at this is that it gives GitHub a huge amount of headroom. The architecture they're describing sounds more efficient at lower rates too, it's not like better throughput and efficiency only benefit repos that are reaching the maximum limits.
[–] zbentley 4 hours ago
Plenty of people (and agents), me included, use commit-and-push as an equivalent to "Save". You spill coffee on a day of unpushed work once, you stop caring about dogma like "commits should be finished, testable, reviewable units of work with discrete, human-readable descriptions" and start treating your Git remote as your backup system.

Besides, you can push amends to your branch, or describe/review/squash your changes at PR merge time anyway, so what's the harm of a zillion pushes? Other than "GitHub engineers have to invent a novel database", that is. But that's probably enrichment for them.

[–] FabCH 16 hours ago
You basically described Google’s monorepo… about 10 years ago.

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…

[–] MisterMunchkin 22 hours ago
Yeah it’s just total slop. If your code is slop anyway, why commit it? Just push it at major milestones. It’s not like it matters if you lose it.
[–] mitxela 1 day ago
Welcome to the new AI future, where everyone is insane and reality doesn't matter.

I'm starting to think AI isn't a productivity machine, but rather a machine for hypnotising people into the false belief of productivity.

[–] gonzalohm 18 hours ago
That's exactly my thoughts! AI generated code is not good code, it's just engineered to look good
[–] swat535 16 hours ago
How do people afford such costs though? At that rate, you're not running flagship models due to cost and limits.. right..?
[–] conartist6 21 hours ago
You weren't supposed to notice
[–] __s 1 day ago
Yesterday's "web scale" is today's "agentic workload"
[–] locknitpicker 21 hours ago
> Sorry, but thousands of pushes per second, per repository?! In what world could that possibly seem like a sound idea?

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.