I think the author meant 'burnish' there, which is a clever way of showing they didn't use AI :-)
alansaber · 2026-08-28 05:11:42 UTC
Furnish makes more sense.
gilleain · 2026-08-28 05:14:36 UTC
Both are fine, but I also prefer 'furnish', as in put in the main parts of your CV. In a way, 'burnish' is more like 'polish', suggesting an extra layer on top, rather than the fundamental parts.
dumpsterdiver · 2026-08-28 05:10:56 UTC
> The changes were harmless and correct, but that did not make me feel better about accepting or merging them.
So do you have the project’s best interest at heart or not? If you’re more concerned about the intent of a valid contribution than the content, why don’t you ask yourself where your intent is? You rejected a valid contribution based on unverified vibes about the person’s intent, instead of assuming they were just being helpful.
cwillu · 2026-08-28 05:13:28 UTC
The changes were grammar and spelling fixes in comments. It is not sufficient for someone to intend to be helpful.
alansaber · 2026-08-28 05:15:00 UTC
If people can spam low-effort PRs they will. Unverified vibes is you closing your eyes to a very real issue.
customguy · 2026-08-28 05:48:36 UTC
Why not assume someone does have the best interest of their own project at heart? How do you get to question that out of the gate, while pretending automated grammar and spelling fixes to rack up PR counts are benevolent unless proven otherwise? Simply assume the person who made the thing you didn't make, who was the only person (or persons) on the planet to come up with that exact thing, knows what's best for that person (or persons). Just like you would handle your own stuff.
herrherrmann · 2026-08-28 06:07:10 UTC
I think it’s implied that accepting these kinds of PRs will take time away from working on actual improvements to the codebase. So, on the long term it’s better to be strict with these kinds of silly contributions, and focus on changes that matter more (e.g. features or fixes).
inigyou · 2026-08-28 16:55:54 UTC
Interesting. You flagged my sibling comment to this one based on it being from a random word picker.
hsn915 · 2026-08-28 05:11:21 UTC
This is weird though.
Obviously the best way to use AI to furnish your CV is to build your own project using AI.
alansaber · 2026-08-28 05:12:56 UTC
Vibe slop or put on your C.V "contributor to <wellknownproject>"? In terms of social currency B wins easily, unless you can guerilla market as well as Openclaw.
Barrin92 · 2026-08-28 05:34:49 UTC
that won't work because all those millions of 'projects' are unmaintainable vaporware which is exactly why people try to piggyback on the reputation of software that is actually being used and developed by people
timokoesters · 2026-08-28 05:12:14 UTC
Hi Neil, fun to see you on HN. I agree with your points and I you summarized it very well as "Ultimately, open source is built on trust".
AI is destroying trust in open source and many other areas and I think this will discourage teams from publishing their source code in the future.
On the other hand, personal connections are becoming even more important, which is unfair to the younger generation and people who don't live near tech hubs.
inigyou · 2026-08-28 05:14:30 UTC
Today's conception of open source is different from the original anyway. It used to be "we made this thing, here's the code" but now it's turned into some kind of weird parasocial thing more akin to Facebook.
bitwize · 2026-08-28 06:36:13 UTC
I explained GitHub to a friend as "like DeviantArt, but for code".
And it is true, but that just means the bar for expectations has been raised thanks to early open source success. Tarball drops don't cut it anymore (unless you're Alphabet, Inc.) and you actually have to foster a community around what you release in order to attract bug reports and contributions. And you need a code of conduct, and a code of conduct enforcement committee, and a steering committee or board of directors, and...
hypfer · 2026-08-28 06:38:16 UTC
You don't need any of that, usually.
You just scratch your own itch and you're done. There is no need to "attract contribution", usually, as usually, your project will do exactly what you need.
inigyou · 2026-08-28 15:22:42 UTC
if you want success on DeviantArt.
where is sqlite's GitHub? It doesn't have one because it drops tarballs.
locknitpicker · 2026-08-28 06:53:01 UTC
> Today's conception of open source is different from the original anyway. It used to be "we made this thing, here's the code" but now it's turned into some kind of weird parasocial thing more akin to Facebook.
I didn't agree with your comment when I glanced through it, but then further ahead in the discussion I stumbled upon a whole thread of people commenting that PRs generated by AI coding assistants are strealing merit, and even posters talking about the need to tell apart AI PRs from AI-free PRs with proof of work schemes just to feed the merit angle.
I was thinking the same. The amount of effort people went through just for a t-shirt. Now you can try to boost your career, far more valuable, and even with less effort. Of course it will happen, unfortunately.
arjie · 2026-08-28 05:25:15 UTC
This makes sense. Apart from the original thing, I no longer upstream anything. It just takes comparatively more effort than maintaining a private fork with my own idiosyncratic fix. This must mean that even small fixes that non-contributors would make in the past are just happening off the books, so to speak. e.g. I upstreamed a tiny fix to Thrift codegen because some function could be much faster. These days I wouldn't bother. I'd just fork and leave upstream to be upstream.
I suspect many people are like me since it feels like a very normie position to take. That means that contributors are even more likely to be useful because both the drive-by genuine contributors have chosen otherwise and these contributors have increased.
It must be quite painful to be an open source maintainer right now. One wonders what to make of such projects in a future where a feature-list is a sufficient prompt.
zamadatix · 2026-08-28 05:59:35 UTC
I ran through exactly this thought process & LLM based resolution just 8 hours ago with a segfault compiling a project which likely doesn't care about the given platform combo much.
arjie · 2026-08-28 06:51:24 UTC
Classic problem. I recall spending a long time trying to get Freespace 2 SCP working on the Via Unichrome onboard GPU I had decades ago. Who could possibly have cared for that? The intersection of the two sets was probably precisely one person.
By the way, interesting person to have 512 IPv4s (and two /44s? Aren't those enormous?). Root-level http intentionally user/pass gated on your site? I was curious to see.
zamadatix · 2026-08-28 13:50:11 UTC
:D. Tl;dr: it's actually near minimal to dual stack and do BGP between 2 sites of redundant services with advertisement failover to the internet.
/48 is the smallest accepted IPv6 advertisement and /24 the smallest allowed IPv4 advertisement (on the net at least). IPv6 assignments are done on the nibble (/48, /44, /40, ...). Since I only have two sites I could have gotten away with a /23 and something like a /44 but then the RIR pointed out it'd probably be cleaner to manage to get a /40 and give each site a /44 at the same renewal cost. As to why, I've just always worked in or near the networking field and so it seemed cheaper/easier to run it all myself in the long run.
Through another very long story, the Org ID + ASN + IPv4 space + IPv6 space ended up costing something like ~$1k the first year and then ~$500 in yearly renewals. I'm not legally able to resell these for the massive market rate prices of /24s because of them being leased for $0 specifically to dual stack my core hosted services like DNS with my own public IP, but that's fine as I got them to use :).
The largest assignment I've ever had the pleasure of getting and deploying was a /32 (... of IPv6!) for an extremely large healthcare system. Certainly no great record smasher, but I thought it was cool to work on an IPv6 subnet so big it could have been an IPv4 route nonetheless! That one was still also very sparse of course, but similar kinds of reasoning ended up getting to that being much easier/better to work with than a dense assignment.
I also have a small MAC address range (a classical "OUI" sized range is 24 bits of addresses, I have 12 bits of addresses) for a small run of some hardware I was making for a particular customer use case. With the leftovers I put my laptop on it and get the occasional "how the hell?" when they see Wireshark decode my laptop MAC as "Dan_Smith_xx_xx" while packet capturing to troubleshoot.
arjie · 2026-08-28 15:41:23 UTC
Haha, that’s incredible. I saw the MAC listing afterwards too and definitely piqued my curiosity. Terrific stuff :)
jspdown · 2026-08-28 06:00:27 UTC
How could it take less effort to maintain a fork? You have to merge the upstream in every week and fight endlessly on conflicts with your patches.
nevon · 2026-08-28 06:31:54 UTC
Having seen this happening in the past, pre-AI, the answer is usually that they don't. They just stay on that version forever. Or it's maintained until the original author moves on, after which it's someone else's problem to figure out how to move back to the upstream, which has now had years of changes.
arjie · 2026-08-28 06:40:48 UTC
Originally, yes. Nowadays, it's trivial. Agents can handle this flawlessly.
oblio · 2026-08-28 07:34:42 UTC
There can be a point of divergence when even humans can't merge things anymore, so I highly doubt that experience is universal.
Ampersander · 2026-08-28 12:14:37 UTC
No you can't say that! It's the superintelligence. You will be left behind.
geraneum · 2026-08-28 06:17:12 UTC
Discussing the issues, achieving consensus, making sure the fix fits the existing patterns and actually warrants the change, etc. These are and have always been a challenging part of contributing to open source. Typing code in your private fork that satisfies your “idiosyncratic fix” has always existed and been always the easier aspect of such changes. Chances are many of these changes would never be accepted into the repository anyway in the past.
arjie · 2026-08-28 06:29:17 UTC
Certainly, but there was motivation to do that in the past. My patch would probably line up with the rest of the code in the direction that they desired and the cost of fork maintenance would have pushed me to upstream in a way acceptable to maintainers.
geraneum · 2026-08-28 11:06:38 UTC
I find it hard to believe that this is the main motivation for most who contributors to OSS. Do you have a reference, research or poll that corroborate this?
You’re vastly overestimating the value of these “fixes” that now go to private forks, because maintainers also have access to LLMs and can prompt, probably better than a drive by fix since they have better understanding and context of the codebase.
Therefore I believe, in most cases, keeping those fixes to private forks is not a noticeable loss for the OSS projects.
utopiah · 2026-08-28 08:50:47 UTC
Fair enough not to want to get involved but seems problematic for 2 reasons :
- code gets re-regenerated over and over again, so waste of resources
- no signal back upstream that it is indeed a genuine need that is in fact so important some users did dedicate resources for it, maybe more users would benefit from it
arjie · 2026-08-28 09:39:51 UTC
All this is true but I prefer writing AI assisted code and I doubt any maintainer can distinguish me from full spectrum bot. It’s just not productive to either of us.
smooc · 2026-08-28 05:26:59 UTC
So the fixes are still fixes, but we (I am also a OSS maintainer) are unwilling to accept them as they boost the contributor’s status where we think the merit is very or extremely limited.
Why not have these PRs counted differently (by the platform), and/or colored differently in the timeline(s) thus made less visible or more clear?
hypfer · 2026-08-28 05:31:05 UTC
The whole idea of "counting PRs" as a vanity metric is flawed because vanity metrics are flawed.
I don't think that there is a technical solution to be found here, as the problem is anything but technical.
__
A hack/trap:
Comment "Ah yes thanks a lot for the hint :)", then make the changes yourself.
Then see how the person reacts to that.
Hack the grifters. Hack the planet.
flyingshelf · 2026-08-28 05:37:06 UTC
My solution is to ask them for proof of work. Many of these disappear after opening a PR that they never tested. How can you claim to have fixed a visual issue without a screenshot? Insta-close.
__david__ · 2026-08-28 05:39:35 UTC
Or just pull the pr into your local git, git amend --reset-author, and then push it to master yourself.
stackghost · 2026-08-28 06:10:40 UTC
Merging commits/PRs without reading them is how you get a 2024 xz situation.
yard2010 · 2026-08-28 06:25:22 UTC
It still haunts me, that dot they slipped in, in one of the commits, every time I merge a PR
kodoman · 2026-08-28 06:36:06 UTC
Not just that how the maintainer was treated by the attacker which tells you something about the way people feel entitled to maintainers time and efforts for nothing even by people not looking to exploit the project. And the abuse after he received despite it being an easy mistake that the culture encourages people to make.
hypfer · 2026-08-28 06:40:28 UTC
> And the abuse after he received despite it being an easy mistake that the culture encourages people to make.
I believe that that was in part simply people defending their reality.
Because if it's not the maintainers fault, then why did it fail? What are the implications of that? What does it mean for me personally? Do I have to do something differently? Do I have to change my assumptions?
People do not like these feelings. They want to simply push them away.
The easiest way of doing so is blaming that guy and being done with the negative emotion.
Most people do suck at this whole "being human" business.
__david__ · 2026-08-28 06:46:14 UTC
I never suggested that you shouldn’t check the commit before merging!
initramfs · 2026-08-28 06:41:48 UTC
I have noticed a lot of my Github followers who are either newer students or just new to Github have an immaculate green board of commits on their profile page, but it's so over the top I only like the ones that have creative illustrations or just very limited edits. Some seem so automated that it's hard to know how much they actually work on it. Others even are programmed to follow accounts then drop off once the person doesn't reciprocate, which is technically better than them staying but also systematically checking what sticks (also Github should limit some of these automated follows).
Arainach · 2026-08-28 05:36:49 UTC
Change is bad unless it's great.
Unless the change is an obvious improvement, it has to be worth the time for the maintainers to spend attention reviewing it (and supporting the code forever, and all the rest).
Even if these particular changes are "harmless" and easy to review, accepting them sets a precedent that encourages an unsustainable flood of AI-generated changes that will overwhelm the project.
brabel · 2026-08-28 06:45:16 UTC
That’s a totally unnecessary high bar you’re setting. Most change is mediocre (a tautology, I realize). I really don’t believe that you can think that fixing a bunch of spelling mistakes is not a small improvement.
About setting a precedent: if you think like that you probably never accept any contributions at all, by humans or otherwise. Contributions by strangers have always been very minor things in general, things that the author cared enough about to make a pull request. In this case I don’t see the difference except for the fact that ai was used. If you just don’t accept ai at all , fine. But just be clear about it. In this case they are calling spelling correction slop. That’s not what slop means. Pretending human contributions were always “great” and nothing else would do is kind of ridiculous and shows a lack of experience in open source.
Arainach · 2026-08-28 07:11:55 UTC
It's not an unnecessarily high bar.
Change is bad. It takes engineers time to understand and approve. It confuses users. Changes should be made for good reasons, not frivolously.
Just because writing code is easier does not mean you should write more of it. It is more important than ever to carefully consider what you work on and what work you accept.
The user says "this is just spelling corrections" but a maintainer - a volunteer - needs to read all the files and make sure it's harmless and doesn't introduce security vulnerabilities, change meanings, and so on. That's not free.
bwhiting2356 · 2026-08-28 05:38:37 UTC
Why not let them have the status boost? This isn't zero sum.
hypfer · 2026-08-28 05:40:09 UTC
> This isn't zero sum.
True, it is actually negative sum, because fake merit erodes trust in real merit, as it makes it a lot harder to spot the latter.
streetfighter64 · 2026-08-28 06:26:34 UTC
I think Goodhart's law applies really well here. When people make commits for the sake of having made a commit to some famous repo, the "merit" that a commit measures is already useless. Remember Hacktoberfest 2020, before LLMs were popular? https://news.ycombinator.com/item?id=24643894
brabel · 2026-08-28 06:54:26 UTC
What merit was there to have anyway. Would the author accept the same changes from a human?? I am inclined to believe they would, I certainly would. Would you have attributed merit to someone just fixing typos? I mean it’s quite helpful. But I wouldn’t think a commit fixing typos ever attributed merit to a developer. So it’s hard to understand the problem with AI doing this. If it was a bot like dependabot but for fixing grammar errors would that be a problem? I assume no, hence the problem is entirely that the human author of the PR is being attributed nonexistent merit by people who should know better.
streetfighter64 · 2026-08-28 07:01:27 UTC
Well, as I mentioned there was already in 2020 the problem of (human-generated) slop commits causing unnecessary work for maintainers.
The commit in itself might add some minuscule value to the project, but when you take into account the time it takes to check the commit and approve it, you're probably back at negative value again.
Plus, there's the problem of people doing this in an adversarial way. How can you tell whether a random commit touching 100 files is the work of an enthusiastic beginner, or a malicious hacker that's hidden a subtle attack somewhere? Well, you need to spend your time carefully checking it.
So it's way more pragmatic just to set up some automated filter to put all of this stuff in the bin.
Oh and by the way:
> I wouldn’t think a commit fixing typos ever attributed merit to a developer.
The first sentences of the article in question:
> Successful contributions to open source projects are a kind of currency. GitHub in particular encourages this in a number of ways: [...] Potential hiring managers often take note of this. Recruiters often find and screen candidates this way.
tancop · 2026-08-28 13:42:04 UTC
Why should a maintainer care about keeping PR count as a signal of developer status? A good quality contribution is a good quality contribution. You only have a responsibility to your own users, keeping out bad code from your repo while accepting as much good code as you can without getting overworked. You don't have to look after other people status games.
If you judge first time contributors on accepted PRs that's as dumb as doing it based on their activity. It tells you nothing about quality. You're the stupid one for assuming all maintainers are as strict as you are.
croes · 2026-08-28 05:52:29 UTC
Boost for what? That they can type a prompt?
How do you distinguish those who know what they are doing from those who only can write a prompt and copy the result?
Making the haystack bigger is a bad idea if you search the needle
SmarsJerry · 2026-08-28 15:13:37 UTC
Surprisingly prompting takes skill. The more you know about something the more precise you can be and the better AI actually works. I’ve found just saying “here is my bug/issue, fix this” is about the absolute worst way thing you could do, but give it a clear direction and precise step by step instructions and it will not only do well but sometimes blow your mind.
bulbar · 2026-08-28 06:02:51 UTC
Because every merge request and every merge comes with cost and (potential) more cost in the future.
Linux lately received a lot of fixes for drivers nobody has cared about for ages. They decided to remove them. Maybe they should have done this earlier, I don't know, but that happened because every code change comes with cost down the line. For real contributers, this cost is much more limited and they have a higher probability of burden the cost down the line.
Pure AI MRs are just rude, because it's just "here take this, don't really care what this is, but AI said it being good, I won't be around, so you will have to deal with this code after the merge and you better don't overlook anything, because I personally don't really know what I am doing, I only know how to have AI making something that looks convincing. Good luck fixing the bugs this change introduces".
selfhoster1312 · 2026-08-28 07:05:37 UTC
Because letting sloperators near your codebase, even for a very minor obvious and correct change, may have long-term negative consequences for your project. It sends a signal to other sloperators to keep doing what they do, when we really need to send them a signal to get a life, learn a craft, and let Claude burn in hell.
Uptrenda · 2026-08-28 06:08:12 UTC
I think what you're saying is fair, tbh. Imagine you put in months or years into a project to make it a quality piece of work. It develops into something notable and you took all the risk. Then someone comes along to fix a spelling error with a pull request so their name effectively appears on the repo as a "contributor." And you just know right after its going on their resume as "contributed to [...]" or maybe if they're bold "software engineer working on [...]" which implies substantial investment. Then you're effectively sharing credit for YOUR work with someone who did nothing. That is rage inducing. ((Of course: it probably is just juniors trying their best in this horrible industry.))
On the other hand: lets be careful not to dismiss valid but inexperienced attempts to contribute. Having someone want to genuinely contribute to your software is incredibly generous. If someone seems like they're trying its better to give advice than act like a snob because its not good enough. Often pull requests only need small fixes to get in, anyway.
21asdffdsa12 · 2026-08-28 06:11:28 UTC
These fixes, regularly destroy the architecture, accrue bloat for little gain, refuse to rewrite while demanding to rewrite- and many other such funny noises. Most code contribution by LLMs is garbage if you long-term care about the project. Look at closed source projects that ingest all this madness - windows with its seconds to open the explorer and other catastrophes.
gunnarmorling · 2026-08-28 05:40:35 UTC
I very much can relate, as I've also been receiving many of these drive-by PRs lately.
One big problem I have with them is that they take away time from project maintainers for reviewing and helping to get the PRs into shape, which then can't be spent on other, more important things. I feel like the "good first issue" GitHub label is specifically attracting these kinds of contributions.
It's not a black-or-white thing though, and you need to tell apart folks who produce slop PRs against any arbitrary repo, from folks using AI to contribute in a sensible way. We've tried to codify some rules in our contribution guide [1]:
- PRs from apparent bot accounts are closed
- PRs from users who file large numbers against random repos are closed
- You're welcome to use AI, but you need to stand behind your PR and be able to explain it
I'm sure we'll adjust those rules over time, but since we have instantiated them, it definitely has become easier to deal with AI PRs and handle them in an a relatively objective way. It absolutely means that sometimes a PR will be closed which could have been an improvement, but I think this is the right thing to do given the circumstances.
Create AI to review the pull requests and auto ban people for low SNR.
jspdown · 2026-08-28 06:22:01 UTC
AI code review is nice to have an additional pair of eyes but it doesn't substitute to the maintainer eyes.
A big part of a review is deciding if you want that change merged in. Not because of the immediate code but what it means to the project to bring this in.
AI code review, to my eyes, just reduce the number of bugs, they do not shorten the review time. Otherwise, it means you are compromising on the direction of the project.
ReptileMan · 2026-08-28 07:04:10 UTC
I meant AI to judge whether a PR is trash or not for ban purposes. Not AI to do the thorough code review itself.
jspdown · 2026-08-28 10:51:00 UTC
In that case yes I think that can be of real value.
nubinetwork · 2026-08-28 05:55:26 UTC
This is nothing new, people have been making spellcheck commits all over github for years... and that was before ai slop even existed.
jspdown · 2026-08-28 06:11:52 UTC
I help maintain a big project as well and I can totally relates what the author is describing.
The amount of security advisories and PRs opened is getting out of hands.
This is no longer just spell check PRs that you can merge in less than 1 minute of review. Often that's going to be supposed perf improvement, attempts at fixing things that are not broken, or submitting completely new features.
These relatively low effort PRs takes a lot of effort to review or even just to filter out.
hypfer · 2026-08-28 05:56:58 UTC
GitHub flavored FOSS I believe works best for "corporate FOSS" projects and terrible for "FOSS as how it was conceived decades ago".
Or rather I believe that it is engineered exactly for the former.
What it does well is coordination between corps, working in public (while on a corp payroll) and extracting some drive-by-PR value out of random third-parties.
The closer your project is to that shape, the better it works for you. The further it is away, the more pain you will feel.
This has nothing to do with AI slop.
AI slop just turned up a few knobs that were already there.
J253 · 2026-08-28 06:03:33 UTC
I also maintain a popular open source repo and have seen similar. If I receive a low effort single-pass obviously-Clauded PR (many people (agents) don’t even bother using the AGENTS.md file I provide right in the repo?!) with no associated issue I also have no qualms closing. I do generally leave a short note about why I closed (volume of these is around 5/week) showing how far off they (Claude) was and encourage opening an issue where we can start a discussion which rarely happens for the drive-by folks. So I totally feel this but I find myself more disheartened by the practice than angry. It feels like slowly watching open-source go the way of email. Open and free until no-cost spam ruined the inbox for everyone...
jbs789 · 2026-08-28 06:05:05 UTC
Interesting analogy.
Sounds like an opportunity for GitHub/others to better filter these.
bhaak · 2026-08-28 06:09:20 UTC
> If I receive a low effort single-pass obviously-Clauded PR (many people (agents) don’t even bother using the AGENTS.md file I provide right in the repo?!)
Claude doesn't read AGENTS.md automatically, it only looks for CLAUDE.md.
n_plus_1_acc · 2026-08-28 06:12:19 UTC
Very intelligent
J253 · 2026-08-28 06:16:48 UTC
True, but I do have a claude.md as well. Point is, best practice agentic development doesn’t seem to be on display.
initramfs · 2026-08-28 06:37:24 UTC
I only look for humans.md and humans.txt.
oleg_antonyan · 2026-08-28 06:06:44 UTC
Do recruiters actually care about your open source contributions? Especially now when only LLMs read CVs and match them against strict criteria, I doubt there are many companies that actually care about your work outside of work, in fact they might care in opposite direction - thinking that you'll be distracted from work
fhd2 · 2026-08-28 06:13:14 UTC
Just speculating (I use zero automation when recruiting), but automated candidate ranking systems could well still look for signals that were valuable years ago, but no longer are. It's not a given that people using this stuff even understand the criteria under the hood.
Same story as SEO, I presume. Google surely understood their ranking criteria deeply, yet couldn't exactly win that fight.
rightbyte · 2026-08-28 06:58:39 UTC
Google could have easily won that fight by blacklisting scrapping spam sites and spam portals. They just didn't.
There weren't that many with high ranking. I could filter out most of them in like a week of working normally and just right clicking them with the blacklist extension in Firefox.
Nowadays it is probably harder though when Google have broken the internet culture.
fhd2 · 2026-08-28 07:14:22 UTC
If you blacklist them just for yourself, the sites don't care, no economic impact. If Google does the same, they'll work around. There's lots of spam-only sites, but they also often cleverly avoid detecting by mixing in content ranked as valuable/legit. SEO also certainly "attacked" otherwise legitimate sites like Reddit, although what GEO is doing there is far worse I imagine.
rightbyte · 2026-08-28 08:28:10 UTC
Sure. It probably works better in isolation.
But there seemed to be some time lag for a SEO spam sites to climb. Removing the ones that make it would mess up the economics at the time. Like the Stack Overflow mirror sites or like spam phone number pages with no other information but the number.
And I guess plenty of search queries would have no moderation. But I mean I spent like 10 minutes. You could have 10 FTE doing that.
DarmokTanagra · 2026-08-28 06:50:12 UTC
In my experience no, it's usually just something you mention during the tech rounds in passing.
fguerraz · 2026-08-28 06:07:08 UTC
These maintainer who’ve held the sacred fire for years…
21asdffdsa12 · 2026-08-28 06:16:15 UTC
These idea guys who longed for the fire for years- and still don't have it.. full of envy..
fguerraz · 2026-08-28 07:21:13 UTC
I'm sure there are people in this category, but there's also the other category who just want their stuff to work, and now can as AI to do it, without having to follow stupid processes (try contributing to QT...) or arguing for months.
21asdffdsa12 · 2026-08-28 08:42:24 UTC
A ton of these "process" cruft is unneeded and gate-keeping in companies.
But in open-source- process is unpaid for sparse- and the gate-keepers usually have excellent reasons to merge changes not back. If they don't - they are forked.
The reason being that while the software generated "solves" your problem, it generates problems for everyone else using the project.
Like demanding a elevator cabin be tailored to your preferences, ignoring all the other buildings using elevator cabins, to which it no longer is compatible for example.
21asdffdsa12 · 2026-08-28 06:08:46 UTC
“The spirits that I summoned, I cannot now dismiss.”
Ironically this seems like a perfect use for AI from the maintaner side. "Find low-effort/AI-like PR's without associated issues from new contributors. Discuss with the contributors in the PR about how contributions should be made, then reject their PR's. If any bad behavior is detected in this interaction, block the accounts for 24 hours and add them to a list of accounts to review for permanent banning from the project".
Automated PR's can have automated responses. You make a human effort, you get a human response.
mikemcquaid · 2026-08-28 06:26:40 UTC
We do similar in Homebrew by autoclosing opens without the issue template (which implies using the API which often now implies AI).
The weird flip side is that the average good AI contribution is better than the average “I used no AI” contribution. Perhaps it’s because Homebrew has so many declarative guardrails and is so easy for agents to test.
satvikpendem · 2026-08-28 09:47:36 UTC
Next time I'll have Codex use computer usage to manually fill out the template, lol.
mikemcquaid · 2026-08-28 13:10:09 UTC
As long as you have it disclose itself: feel free. We're not anti-AI use, we're just anti-low-effort AI use and don't see the need to apply effort to educate people who haven't applied the effort themselves.
codingisfreedom · 2026-08-28 06:29:24 UTC
I think the idea of leveraging AI to find useless PRs is right.
I didn’t like the second part though where it starts banning people for “bad behavior”.
I get that AI resistance will be a thing in the next few years, but realistically engineers who plan on being around for the next 20-30 years just need to embrace it instead of being sour about it.
Because of machines, things have arguably improved for humanity as a whole. People who seek more elevated/finer products can still turn to handcrafted products.
Mass software will be produced by AI, and it will scale just fine.
Comments
So do you have the project’s best interest at heart or not? If you’re more concerned about the intent of a valid contribution than the content, why don’t you ask yourself where your intent is? You rejected a valid contribution based on unverified vibes about the person’s intent, instead of assuming they were just being helpful.
Obviously the best way to use AI to furnish your CV is to build your own project using AI.
AI is destroying trust in open source and many other areas and I think this will discourage teams from publishing their source code in the future.
On the other hand, personal connections are becoming even more important, which is unfair to the younger generation and people who don't live near tech hubs.
And it is true, but that just means the bar for expectations has been raised thanks to early open source success. Tarball drops don't cut it anymore (unless you're Alphabet, Inc.) and you actually have to foster a community around what you release in order to attract bug reports and contributions. And you need a code of conduct, and a code of conduct enforcement committee, and a steering committee or board of directors, and...
You just scratch your own itch and you're done. There is no need to "attract contribution", usually, as usually, your project will do exactly what you need.
where is sqlite's GitHub? It doesn't have one because it drops tarballs.
I didn't agree with your comment when I glanced through it, but then further ahead in the discussion I stumbled upon a whole thread of people commenting that PRs generated by AI coding assistants are strealing merit, and even posters talking about the need to tell apart AI PRs from AI-free PRs with proof of work schemes just to feed the merit angle.
Crazy times we live in.
I suspect many people are like me since it feels like a very normie position to take. That means that contributors are even more likely to be useful because both the drive-by genuine contributors have chosen otherwise and these contributors have increased.
It must be quite painful to be an open source maintainer right now. One wonders what to make of such projects in a future where a feature-list is a sufficient prompt.
By the way, interesting person to have 512 IPv4s (and two /44s? Aren't those enormous?). Root-level http intentionally user/pass gated on your site? I was curious to see.
/48 is the smallest accepted IPv6 advertisement and /24 the smallest allowed IPv4 advertisement (on the net at least). IPv6 assignments are done on the nibble (/48, /44, /40, ...). Since I only have two sites I could have gotten away with a /23 and something like a /44 but then the RIR pointed out it'd probably be cleaner to manage to get a /40 and give each site a /44 at the same renewal cost. As to why, I've just always worked in or near the networking field and so it seemed cheaper/easier to run it all myself in the long run.
Through another very long story, the Org ID + ASN + IPv4 space + IPv6 space ended up costing something like ~$1k the first year and then ~$500 in yearly renewals. I'm not legally able to resell these for the massive market rate prices of /24s because of them being leased for $0 specifically to dual stack my core hosted services like DNS with my own public IP, but that's fine as I got them to use :).
The largest assignment I've ever had the pleasure of getting and deploying was a /32 (... of IPv6!) for an extremely large healthcare system. Certainly no great record smasher, but I thought it was cool to work on an IPv6 subnet so big it could have been an IPv4 route nonetheless! That one was still also very sparse of course, but similar kinds of reasoning ended up getting to that being much easier/better to work with than a dense assignment.
I also have a small MAC address range (a classical "OUI" sized range is 24 bits of addresses, I have 12 bits of addresses) for a small run of some hardware I was making for a particular customer use case. With the leftovers I put my laptop on it and get the occasional "how the hell?" when they see Wireshark decode my laptop MAC as "Dan_Smith_xx_xx" while packet capturing to troubleshoot.
You’re vastly overestimating the value of these “fixes” that now go to private forks, because maintainers also have access to LLMs and can prompt, probably better than a drive by fix since they have better understanding and context of the codebase.
Therefore I believe, in most cases, keeping those fixes to private forks is not a noticeable loss for the OSS projects.
- code gets re-regenerated over and over again, so waste of resources
- no signal back upstream that it is indeed a genuine need that is in fact so important some users did dedicate resources for it, maybe more users would benefit from it
Why not have these PRs counted differently (by the platform), and/or colored differently in the timeline(s) thus made less visible or more clear?
I don't think that there is a technical solution to be found here, as the problem is anything but technical.
__
A hack/trap:
Comment "Ah yes thanks a lot for the hint :)", then make the changes yourself.
Then see how the person reacts to that.
Hack the grifters. Hack the planet.
I believe that that was in part simply people defending their reality.
Because if it's not the maintainers fault, then why did it fail? What are the implications of that? What does it mean for me personally? Do I have to do something differently? Do I have to change my assumptions?
People do not like these feelings. They want to simply push them away. The easiest way of doing so is blaming that guy and being done with the negative emotion.
Most people do suck at this whole "being human" business.
Unless the change is an obvious improvement, it has to be worth the time for the maintainers to spend attention reviewing it (and supporting the code forever, and all the rest).
Even if these particular changes are "harmless" and easy to review, accepting them sets a precedent that encourages an unsustainable flood of AI-generated changes that will overwhelm the project.
About setting a precedent: if you think like that you probably never accept any contributions at all, by humans or otherwise. Contributions by strangers have always been very minor things in general, things that the author cared enough about to make a pull request. In this case I don’t see the difference except for the fact that ai was used. If you just don’t accept ai at all , fine. But just be clear about it. In this case they are calling spelling correction slop. That’s not what slop means. Pretending human contributions were always “great” and nothing else would do is kind of ridiculous and shows a lack of experience in open source.
Change is bad. It takes engineers time to understand and approve. It confuses users. Changes should be made for good reasons, not frivolously.
Just because writing code is easier does not mean you should write more of it. It is more important than ever to carefully consider what you work on and what work you accept.
The user says "this is just spelling corrections" but a maintainer - a volunteer - needs to read all the files and make sure it's harmless and doesn't introduce security vulnerabilities, change meanings, and so on. That's not free.
True, it is actually negative sum, because fake merit erodes trust in real merit, as it makes it a lot harder to spot the latter.
The commit in itself might add some minuscule value to the project, but when you take into account the time it takes to check the commit and approve it, you're probably back at negative value again.
Plus, there's the problem of people doing this in an adversarial way. How can you tell whether a random commit touching 100 files is the work of an enthusiastic beginner, or a malicious hacker that's hidden a subtle attack somewhere? Well, you need to spend your time carefully checking it.
So it's way more pragmatic just to set up some automated filter to put all of this stuff in the bin.
Oh and by the way:
> I wouldn’t think a commit fixing typos ever attributed merit to a developer.
The first sentences of the article in question:
> Successful contributions to open source projects are a kind of currency. GitHub in particular encourages this in a number of ways: [...] Potential hiring managers often take note of this. Recruiters often find and screen candidates this way.
If you judge first time contributors on accepted PRs that's as dumb as doing it based on their activity. It tells you nothing about quality. You're the stupid one for assuming all maintainers are as strict as you are.
How do you distinguish those who know what they are doing from those who only can write a prompt and copy the result?
Making the haystack bigger is a bad idea if you search the needle
Linux lately received a lot of fixes for drivers nobody has cared about for ages. They decided to remove them. Maybe they should have done this earlier, I don't know, but that happened because every code change comes with cost down the line. For real contributers, this cost is much more limited and they have a higher probability of burden the cost down the line.
Pure AI MRs are just rude, because it's just "here take this, don't really care what this is, but AI said it being good, I won't be around, so you will have to deal with this code after the merge and you better don't overlook anything, because I personally don't really know what I am doing, I only know how to have AI making something that looks convincing. Good luck fixing the bugs this change introduces".
On the other hand: lets be careful not to dismiss valid but inexperienced attempts to contribute. Having someone want to genuinely contribute to your software is incredibly generous. If someone seems like they're trying its better to give advice than act like a snob because its not good enough. Often pull requests only need small fixes to get in, anyway.
One big problem I have with them is that they take away time from project maintainers for reviewing and helping to get the PRs into shape, which then can't be spent on other, more important things. I feel like the "good first issue" GitHub label is specifically attracting these kinds of contributions.
It's not a black-or-white thing though, and you need to tell apart folks who produce slop PRs against any arbitrary repo, from folks using AI to contribute in a sensible way. We've tried to codify some rules in our contribution guide [1]:
- PRs from apparent bot accounts are closed - PRs from users who file large numbers against random repos are closed - You're welcome to use AI, but you need to stand behind your PR and be able to explain it
I'm sure we'll adjust those rules over time, but since we have instantiated them, it definitely has become easier to deal with AI PRs and handle them in an a relatively objective way. It absolutely means that sometimes a PR will be closed which could have been an improvement, but I think this is the right thing to do given the circumstances.
[1] https://github.com/hardwood-hq/hardwood/blob/main/CONTRIBUTI...
AI code review, to my eyes, just reduce the number of bugs, they do not shorten the review time. Otherwise, it means you are compromising on the direction of the project.
The amount of security advisories and PRs opened is getting out of hands. This is no longer just spell check PRs that you can merge in less than 1 minute of review. Often that's going to be supposed perf improvement, attempts at fixing things that are not broken, or submitting completely new features.
These relatively low effort PRs takes a lot of effort to review or even just to filter out.
What it does well is coordination between corps, working in public (while on a corp payroll) and extracting some drive-by-PR value out of random third-parties.
The closer your project is to that shape, the better it works for you. The further it is away, the more pain you will feel.
This has nothing to do with AI slop. AI slop just turned up a few knobs that were already there.
Sounds like an opportunity for GitHub/others to better filter these.
Claude doesn't read AGENTS.md automatically, it only looks for CLAUDE.md.
Same story as SEO, I presume. Google surely understood their ranking criteria deeply, yet couldn't exactly win that fight.
There weren't that many with high ranking. I could filter out most of them in like a week of working normally and just right clicking them with the blacklist extension in Firefox.
Nowadays it is probably harder though when Google have broken the internet culture.
But there seemed to be some time lag for a SEO spam sites to climb. Removing the ones that make it would mess up the economics at the time. Like the Stack Overflow mirror sites or like spam phone number pages with no other information but the number.
And I guess plenty of search queries would have no moderation. But I mean I spent like 10 minutes. You could have 10 FTE doing that.
But in open-source- process is unpaid for sparse- and the gate-keepers usually have excellent reasons to merge changes not back. If they don't - they are forked.
The reason being that while the software generated "solves" your problem, it generates problems for everyone else using the project.
Like demanding a elevator cabin be tailored to your preferences, ignoring all the other buildings using elevator cabins, to which it no longer is compatible for example.
https://en.wikipedia.org/wiki/The_Sorcerer%27s_Apprentice
Automated PR's can have automated responses. You make a human effort, you get a human response.
The weird flip side is that the average good AI contribution is better than the average “I used no AI” contribution. Perhaps it’s because Homebrew has so many declarative guardrails and is so easy for agents to test.
I didn’t like the second part though where it starts banning people for “bad behavior”.
I get that AI resistance will be a thing in the next few years, but realistically engineers who plan on being around for the next 20-30 years just need to embrace it instead of being sour about it.
Because of machines, things have arguably improved for humanity as a whole. People who seek more elevated/finer products can still turn to handcrafted products.
Mass software will be produced by AI, and it will scale just fine.