[nlh]

I’ve read so many stories like this that I’ve actually gotten scared of making PRs open source projects.

There’s one in particular where a feature I really wanted didn’t exist, so I forked and had Codex 5.5 assist with building the feature on my local version. It works perfectly. My life has been improved in being able to have this feature now.

Normally I’d want to share it back with the community so others can benefit as well (presumably if I wanted this feature, others probably want it too.) But…I am not pretending this is perfect, great, or even good code. I spent about an hour total on it - it works, I haven’t had any issues with it, but it’s probably slop by any hard-core engineering account. And I neither want to get attacked for submitting slop nor do I have the time to properly engineer it to be hand-coded, so the net result is that it lives on my machine alone.

Is this the right outcome? I feel guilty that I’m getting a better version of this software and others aren’t. I want to help makes others lives easier too, but I don’t want to burden the project maintainers or get yelled at for submitting slop.

What’s the future look like here?

[magnio]

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.

[MBCook]

You could send a comment/open a discussion explain explaining what you did and asking if they would be interested in the feature or a PR.

[hgoel]

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.

[jcranmer]

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.

[djtango]

AI has inverted the effort - in the past a PR meant someone had to come in, read your ticket, documentation, code and tests to successfully author a PR. Subsequently reviewing that PR would typically take less time than authoring it and you would receive fewer PRs.

Now it is it the opposite, maintainers are flooded with low effort PRs that take more effort to review than author, but the author is unable to see why this is problematic to the maintainer and the project.

[toast0]

Exvuse me, I've been doing drive by manual slop PRs for at least a decade.

I certainly didn't read a ticket; I ran into the problem myself. I probably didn't read documentation or write tests either. I just fixed my problem and tried to help others a bit.

Tldr, pr review has always been hard.

[Panzer04]

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.

[MBCook]

Quite possibly never tested, of maybe only tested their problem and not if it broke anything else.

[grebc]

Not quite possibly. 99.99999% likely.

[habinero]

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.

[rgoulter]

> 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?

[perching_aix]

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.

[pabs3]

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.

[nxobject]

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.)

[Barrin92]

>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.

[bakugo]

> 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?

[Auracle]

Because it still took them an hour in addition to testing it, so presumably it’s not ridiculously simple and people have a limited amount of time?

[qwrurt]

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.

[JTbane]

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.

[grebc]

It’s the right outcome. Yours isn’t the better version.