No, it is a tooling problem.

The tooling is telling laymen that they built wonderful things that definitely work and perfectly fix and add features.

The tooling gasses them up and is simply wrong in these cases.

If your tool regularly lies, gaslights and produces wrong results, that's a tooling issue.

Nope. If the tooling is fooling then the tooling IS the problem.

Forks need to be normalized again.

Logistically & brand-wise, they're messy to deal with, but they result in a "filter" of sorts that the original project can pick & choose to upstream back into their code.

It’s not just popular projects. On a small utility I have I received a PR that was more lines than the project had. I’m happy to be a good maintainer, but reviewing something that’s effectively an AI rewrite isn’t something I care to review and since I can’t vet it, can’t blindly accept it.

I think some sort of reputation score would make more sense, assuming it’s possible to design one that can’t be easily faked

I like to send Claude Code or Codex on max settings off to try a problem in parallel while I work on it.

In a complex codebase it’s funny how often they’ll come back with gigantic commits that just make everything worse or accomplish the goal but have 1000 lines of unnecessary complexity.

Every time they present it with a confident summary. I can see how a junior or just lazy dev would think this is their ticket to becoming a contributor to a repo with some big thing to put on their resume.

I've been working on a project myself over the last few weeks where the documentation is quite minimal. To no surprise the LLMs fell flat at being able to generate any sort of meaningful code. However, I realized that if I focused first on building out documentation and coding tools (linters, parsers, formatters, etc...), LLMs can do a decent job at solving fundamental problems.

Similar for me, but regarding the Classic Macintosh APIs. The difference is that there are plenty of books, and some source code available… just not enough to stop Codex from writing subtly wrong gibberish.

I get the impression that the “10x velocity!!!!” claims still only reflect which areas have a sufficient corpus to learn from, rather than any inductive reasoning.

I have had the same result when trying similar things for graphics on modern consoles. I hear so much great stuff about AI coding but in my niche it just seems to fall flat. Even just rubber ducking around graphics and performance they sound like a beginner who has read a lot of good blogs but with no practical experience.

When I saw it treats SPE code in the same manner as shader code on GPUs that was an enlightening moment. It made so much sense to treat it like that. That move while complicated removes a lot of potential performance issues.

I've struggled with this "responsibility" take. What does it mean in the context of an open source project? As far as I understand it, the original contributors of bugs are often not the ones fixing them (though they can be). Is it that if you write enough buggy code you get banned as a contributor? Is it that you're not allowed to say Claude ate my homework?

> the solution I liked the best was the linux "developers take full responsibility" approach.

The people who can realistically submit a Linux patch that will ever get looked at is already a super select group through who-you-know network effects.

You can't apply the same system to random open source projects, the best option for people that run random small to medium sized open source projects is just to ban all unsolicited PRs, otherwise you're going to spend way too much effort sorting through the slop.

> … and submitting a PR without testing, and which have at least been locally tested to some degree.

There’s no need to test the PR when you already asked the AI to not make any mistakes.

Ask ChatGPT: You'll get an authoritative answer!

Thats the thing, what if the codebases had CLAUDE.md / AGENTS.md files, which clearly dictated that

A) tests need to pass

B) anything you write needs tests

C) the code quality must adhere to these standards

etc.etc.... Helping the LLMs that people Vibe code with, produce better quality results.

By not having these in place, it means people who want to help out, cant. because htey dont understand whats going on.

adding stuff to these files, woudl allow developers to give guidelines / guardrails for developement using these agents.

Should the barrier of entry be someone who knows how to code? or should the barrier of entry be someone who is motivated to help with open-source software.

A good argument to use could be: I can use Claude myself, so I will if I need to, but you using Claude on my behalf doesn’t save me any work, it just introduces another layer of noise into the mix. (Yes calling the guy “noise” haha)

Over the last month, I've been using Claude to assist in some things that were at the edge of my ability (or maybe just a hair's breadth beyond it). I've added features to open source projects that everyone's been waiting years for. I always fork it telling myself that I want to be able to submit PRs, but really I'm just making the changes for myself, since I don't even have the nerve to show it off.

If these people can make changes to the emulators that will actually make the games more playable for them, the changes don't have to go back into the official project. It works for them and makes things better.

Right now, I've been working on some changes to the mkv container spec to have embedded scripting cable of doing Black Mirror: Bandersnatch in interactive mode. VLC and mpv. I've already added mutable torrent support to Transmission, and it works. But yeh, if someone took a look at it who really knew the code, they'd see it was AI slop and do a hard pass.

At some point it used to be in order to have things that you can show got merged into popular public projects in job interviews, but I'm not sure that is the case anymore since some of these people have no intention (as far as i can tell) of finding a SE job

> what is the appeal of blindly blasting open source projects with high-volume PRs?

The prestige of being "the one that added feature X to OSS project Y". The things that would've been actually useful (bug diagnostics/troubleshooting, merging duplicate issues & PRs) do not offer the same level of prestige.

Just wanted to say that reading all the comments here, I'm getting flashbacks to alt.aol.sucks.

Instant gratification? This feels like the exact same phenomenon as kids trying to profiteer from repackaged game mods and ripped game assets.

At this point these could just be gamers who want to play a game and are being annoyed by something not being right.

Maybe they use Claude or whatever and tell it to fix the problem and then just blindly submit it.

I could see people doing that without knowing enough to be able to compile and test the code, ignoring whether it’s good or not. So they just submit it and hope it gets merged to “fix” the problem, having no understanding of what’s involved or how much of a burden that is.

Now imagine a whole bunch of people doing that for a whole bunch of really complex bugs in 75 different games. It’s not like the PlayStation three was a simple system.

First, you don't have to feel guilty of anything, since forking open source projects to make changes tailored to your use case is as old as open source itself. It is, in fact, the primary benefit of open source.

Second, it is not a given that your change would be accepted regardless of who wrote it. Maybe the feature is too niche for its complexity, maybe it is better implemented with more generality or extensibility that does not make sense for your own use. In those cases, your change might have been rejected upstream, so having it only locally is a perfect fine solution.

Third, if you believe it is actually useful for broader users, open an issue requesting that feature, and say LLM implemented it in an hour. Then the maintainers can prompt their own LLM to implement it with ease, or do whatever they want with their project.

I did this recently too, didn't really care about the code quality of a small tool, just asked Claude to add in the features I wanted and it produced something that worked.

I just pushed the changes to my fork of the project and left it at that. Leaves the feature around for me and anyone that stumbles across my fork, without wasting the original dev's time looking at code I didn't care to look at.

Even before AI coding I think it was relatively common to fork some code and edit it to have something you want, then to either leave it as a personal version, or to never actually get a response on the PR.

As a maintainer, discovering that a PR is AI-generated just absolutely saps any motivation I have to actually review it. I've never been a great reviewer, and AI means I have to watch out for really different kinds of errors. There's also the potential for extra friction with interactions with the "author": some people try to pull a "I'm just a smol bean, not a programmer, how dare you ask me to do anything" in response to changes, while others just play a middleman role in between you and the AI they're using.

If you're actually motivated to get a working fix upstream, and you're willing to do more than be a passive player, then it's not necessarily a problem to submit it (subject to responsible disclosure, of course)... but you also say that you don't have the time to properly engineer it, which makes me think you don't have the time to be sufficiently engaged in the upstreaming process anyways.

If you're upfront about the provenance and amount of effort that went into it, is there really a problem?

I feel like the issue is people contributing code they don't understand and presenting it as if they do.

It’s a reasonable when you frame it like this: the consequences of one AI-assisted addition are small… but maintainers are responsible for the codebase’s long-term quality after years of additions. The bar's higher. (Similarly, my friends like it when I host an occasional dinner party, but things would really suck at a restaurant run by nothing but my clones.)

Just go for it. Do it enough, and over time you'll either find yourself resilient enough, or conclude that people do not actually deserve it (or rather that you do not deserve the struggle), and you'll be cured of this compulsion. The only way to go is forward.

> What’s the future look like here?

For practically no effort, you were able to customise free software to your liking.

That's a surprising and really cool dynamic.

Is your "about an hour of ... using Codex 5.5" really something others can't do for themselves, that it's worth communicating the change?

It isn't clear that AI generated code is copyrightable, so that portion of the code wouldn't able to have the license enforced against violators, and so the authors wouldn't accept such code. Of course if its permissively licensed, the authors probably don't care to enforce the license, so might be fine including the code.

To submit the code, at minimum, you should review and fix the code diff, run the appropriate static analysis tools against it, write the pull request description and commit messages yourself, read the contribution guidelines, make sure everything matches that, disclose that you used AI and for what, and the prompts used.

There is nothing wrong with forking, and one man's "better" version is another's bloat. Also, making a fork rather than a PR avoids burdening maintainers.

If you don't have time to properly engineer it, then you can't submit. Why would you feel guilty? Others can throw a coin in the laundromat, too, if they are so inclined.

The same as it does now.

I'm glad it works for you, but please do not submit low-effort stuff like this, if you're not willing to do the rest of the work to make it maintainable.

I get the desire to help -- that's fine -- but AI code is abundant and of low value. Don't sandbag them with more work and increase their maintenance burden, with stuff they could easily vibe code themselves.

> I feel guilty that I’m getting a better version of this software and others aren’t

Why? None of what you did is special. What stops anyone else from asking their AI to implement the same feature you did, if they need it?

>Is this the right outcome?

Yes, if you can't vouch for the quality of the code that is the correct outcome. The long term health and maintainability of an open source project takes precedence over adding another feature. This was the case before repos were flooded with AI slop as well. Virtually no project would have accepted a random code dump if the person submitting it does not understand it because that just means the burden falls on someone else which would very quickly get any software project into big trouble.

Will they get there? They rely so much on existing content.

But in such a niche area where the documentation or other solutions often flat out don’t exist how are they supposed to get better through training?