Live data from Hacker News

I don't want your PRs anymore

dpc.pw

91–100 of 148 posts

Re: I don't want your PRs anymore

#91

Somehow, this seems like a serious negative consequence of LLMs to me. We should consider how security patches move through the ecosystem. Changes like this are understandable but only because PRs from LLMs are so bad and prolific. When a new exploit is discovered, the number of sites that require a change goes up exponentially due to LLMs not using libraries. At the same time, the library contributors will likely no…

Code changes are cheaper to make now and kind of more expensive to verify.

So you can still contribute, you just not need to provide the code, just the issue.

Which isn't as bad as it sounds, it kind of feels bad to rewrite somebody's code right away when it is theoretically correct, but opinionated codebases seem to work very well if the maintainer opinions are sane.

Re: I don't want your PRs anymore

#92
Luckily we have had the perfect paradigm for this kind of mindset for decades: proprietary software. The spirit of open source is already essentially dead due to it being co-opted by companies and individuals working only for their own gain, and for it to rise again we probably need a total reset.

Re: I don't want your PRs anymore

#93
post #26

Earlier quoted context omitted.

The cost of forking open source code was always effectively zero.

It's not really, because you now have the cost of maintaining that fork, even if it's just for yourself.

I'm talking about the literal process of forking an open source project. You're just making a copy of a set of files.

Re: I don't want your PRs anymore

#94
post #40

I have come to a similar realization recently - its what I call "Take it home OSS" - i.e. fork freely, modify it to your liking using AI coding agents, and stop waiting for upstream permissions. We seem to be gravitating towards a future where there is not much need to submit PRs or issues, except for critical bugs or security fixes. It's as if OSS is raw material, and your fork is your product.

This has always been the case, and is really the main practical advantage of open source. Contributing code back is an act of community service which people do not always have time for. The main issue is that over time, other people will contribute back their own acts of community service, which may be bug fixes or features that you want to take advantage of. As upstream and your own fork diverge, it will take more and more work to update your patches. So if you intend to follow upstream, it benefits you to send your patches back.

Re: I don't want your PRs anymore

#95
post #55

Earlier quoted context omitted.

...that assumes LLMs will contribute garbage code in the first place. Will they, though?

The LLM isn’t contributing garbage, the user is by (likely) not testing/verifying it meets all requirements. I haven’t yet used an LLM which didn’t require some handholding to get to a good code contribution on projects with any complexity.

[dead]

Re: I don't want your PRs anymore

#96
post #68
post #55

Earlier quoted context omitted.

...that assumes LLMs will contribute garbage code in the first place. Will they, though?

The problem isn't that it can't write good code. It's that the guy prompting it often doesn't know enough to tell the difference. Way too many vibe coders these days who can generate a PR in 5 seconds, but can’t explain a single line of it.

That’s 100% the trick to it all. I don’t always write code using LLMs. Sometimes I do. The thing that LLMs have unlocked for me is the motivation to put together really solid design documentation for features before implementing them. I’ve been doing this long enough that I’ve usually got a pretty good idea of how I want it to work and where the gotchas are, and pre-LLMs would “vibe code” in the sense that I would write code based on my own gut feeling of how it should be structured and work. Sometimes with some sketches on paper first.

Now… especially for critical functionality/shared plumbing, I’m going to be writing a Markdown spec for it and I’m going to be getting Claude or Codex to do review it with me before I pass it around to the team. I’m going to miss details that the LLM is going to catch. The LLM is going to miss details that I’m going to catch. Together, after a few iterations, we end up with a rock solid plan, complete with incremental implementation phases that either I or an LLM can execute on in bite-sized chunks and review.

Re: I don't want your PRs anymore

#97
post #66
post #40

I have come to a similar realization recently - its what I call "Take it home OSS" - i.e. fork freely, modify it to your liking using AI coding agents, and stop waiting for upstream permissions. We seem to be gravitating towards a future where there is not much need to submit PRs or issues, except for critical bugs or security fixes. It's as if OSS is raw material, and your fork is your product.

Recently I've been air-dropped into such a legacy project at work in order to save a cybersecurity-focused release date. Millions of lines of open-source code checked in a decade ago prior to the Subversion-to-Git migration, then patched everywhere to the point where diffs for the CVEs don't apply and we're not even sure what upstream versions best describe the forks. By the end, the project manager begged me to turn…

> west manifest

Zephyr-based project?

Re: I don't want your PRs anymore

#98

Given that submitters are just using LLMs to produce the PR anyway, it makes sense that the author can just run that prompt himself. Just share the 'prompt' (whether or not it is actually formatted as a prompt for an LLM), which is not too different than a feature request by any other name.

If your use of LLMs is limited to one shot prompts you must be new.

Re: I don't want your PRs anymore

#99
post #65

Earlier quoted context omitted.

This is very shortsighted and it’s like polishing gun to shoot your foot with it. If it’s "take it home OSS" and "there is not much need to submit PRs or issues" then why would anybody submit PRs and issues for "for critical bugs or security fixes"? If they have fix and it works for them, they’re fine, afterall. And while we’re at it, why would anybody share anything? It’s just too much hassle. People will either com…

> then why would anybody submit PRs and issues for "for critical bugs or security fixes"? Why do they do that at present? There are plenty of cases where it's a hassle but people still do it, presumably out of a sense of common decency.

> common decency

Another self-serving reason is so that you can upgrade in the future without having to worry about continually pulling your own private patch set forward.

Post reply on HN