now imagine how many other devs and maintainers are contemplating this but just haven't been pushed to their personal breaking point yet. or take note of how many, when asked about the spam problem, just nervously go "yeah it's kinda rough haha...". or how many will vent about it on their twitter-like of choice with increasing frequency.

remember hacktoberfest 2020? that's just all public-facing source 365 days a year now, except instead of "updated README.md" it's some vaguely-plausible fix... then you read the PR body and someone couldn't even be bothered to, or, just as likely couldn't explain it themselves. and that sort of sinking dread sets in.

▲

scronkfinkle 5 hours ago | parent | next [-]

> remember hacktoberfest 2020?

Oh man, if you read the threads about that it's such a time capsule of a different era:

e.g. from this thread: https://news.ycombinator.com/item?id=31628342

> I am honestly surprised how little SPAM there is on GitHub in general. Please don’t take that as a challenge!

	▲	throwup238 4 hours ago \| parent [-]
		Microsoft took it as a challenge.

▲

ssl-3 5 hours ago | parent | prev | next [-]

> now imagine how many other devs and maintainers are contemplating this but just haven't been pushed to their personal breaking point yet. or take note of how many, when asked about the spam problem, just nervously go "yeah it's kinda rough haha..."

At first, my brain parsed "spam" as in ye olde email spam. It took a moment for it to sink in that you meant code spam, instead.

But now that the two concepts are linked in my little pea brain: I kind of want to see how a system like SpamAssassin would work when applied to pull requests like it has been applied to email.

It can use reputation, real-time blacklists, triggers for form, and et cetera, with weighted scores for every aspect that are ultimately factored into one final score.

If final score is passing, the PR is presented for a human to review like a PR was (say) 5 years ago. If the final score fails, it goes into the circular file where it will probably die.

▲

BrtByte 4 hours ago | parent | next [-]

The funny part is that we'd probably recreate the entire email spam arms race

	▲	ssl-3 3 hours ago \| parent [-]
		That's OK. Maybe it's even inevitable. I've been on both sides of the spam arms race at different times of my life. While they'll never be able to claim victory, the good guys (usually!) seem to be winning -- and that's a lot better than accepting defeat.

▲

jeremyjh 4 hours ago | parent | prev [-]

There are reputation and vouch systems but there is definitely room for innovation; I don’t think there is any clear leader.

▲

BrtByte 4 hours ago | parent | prev | next [-]

The asymmetry is what makes this feel unsustainable

▲

jwcooper 5 hours ago | parent | prev [-]

I would guess we'll start seeing more open source projects with much tighter restrictions on who can participate. Closed contributions and heavily automated (or even closed) issue tracking is probably already happening and will spread faster.

I entirely sympathize with these maintainers too. I've had 2 instances where an LLM has surfaced a bug and I just couldn't get myself to open a PR and dump more work onto these maintainers, even after manually writing one up (neither were critical bugs, it's fine).

Seeing popular projects (like hermes) having 5k issues and 5k pull requests is madness.

▲

Marsymars 4 hours ago | parent | next [-]

> Seeing popular projects (like hermes) having 5k issues and 5k pull requests is madness.

It's actually got nearly 30k open pull requests!

▲

user43928 4 hours ago | parent | prev | next [-]

Modern problems require modern solutions.

Why not set up a triage bot with only read permissions on the project and restricted network access in order to triage issues?

Perhaps this way one could turn the influx of spam into a source of useful information.

▲

jeremyjh 4 hours ago | parent [-]

These exist. Very elaborate systems in many cases. Otherwise Hermes would probably have 30,000. Like a lot of agent tools they merge a ton of slop though so I wouldn’t consider them leaders.

	▲	user43928 3 hours ago \| parent \| next [-]
		So, what is the problem then? Genuine question. Is having a prioritized list of reported issues still not useful in practice?
	▲	Marsymars 4 hours ago \| parent \| prev [-]
		> Otherwise Hermes would probably have 30,000. It already does!

▲

staminade 4 hours ago | parent | prev [-]

On the other hand we'll probably see a lot more fully vibecoded projects gaining traction, because of the rate at which they can move once human design and review gets taken out of the equation.

For example, I recently came across Hucre, https://github.com/productdevbook/hucre, which is a JS spreadsheet library apparently developed entirely in the past few months and which has already gained 2.2k GH stars.

Is it any good? Who knows, but the alternatives for spreadsheet handling in JS aren't great, either being limited, semi-commercial, or unmaintained. And creating a new one without LLM-assistance is a huge, painful, mostly thankless undertaking. It's not surprising that a zero-dependency option that promises to do everything this can do would be popular.

Everyone has had the experience of butting their head against functionality limitations of open-source libraries. Fully vibecoded libraries will be able to add functionality at a rate that human-authored ones can't. Code quality might suffer, but if a library has a feature you need, and you've got a deadline to hit, are you going to avoid using it? Is the average developer? Or the average LLM?

I think we're about to hit an interesting period of human-only projects competing with vibecoded ones, and it'll be an acid test as to whether the pro and anti claims about AI-coding bear out in terms of code reliably.