I agree 100%. If you open a PR, you need to add value somehow - having thought about the problem, understanding the code base deeply or just your time by thinking about a solution you can't otherwise get easily.

The problem is that the last part changed drastically with LLMs. You can get a lot of solutions easily by prompting an LLM. But that also means you don't need outside PRs for that anymore, and just prompt the LLM yourself.

That means two things in my opinion:

1) People haven't internalized that yet. For a lot of people, a functioning solution to a problem with often quite a bit of source code is equivalent to "adding value" - because in the past it was. It meant you thought about the problem, understood it and found a solution. But it was that thinking that added the value.

2) The minimum threshold for adding this "quality" rises quite a bit. A lot of problems can now be solved very fast with an LLM by someone who understands the code base well enough. You don't need a PR for that.

I suspect, that means in the future you could both get and need less contributions to OSS projects in general.

We'll see

▲

menaerus a day ago | parent | next [-]

> But that also means you don't need outside PRs for that anymore, and just prompt the LLM yourself.

No, I don't think that is true. Anyone who used LLMs in greater degree (e.g. at work) knows for a fact that the output and therefore the end result work heavily depends on the human involved, and their thought process. Of course for anything that isn't completely trivial.

▲

xnorswap a day ago | parent | prev | next [-]

If this means that the signal of valued contribution swings from "PRs merged" to "Issues raised with PRs merged" then I'm all for it.

In LLM-friendly repositories it saves everyone's time if the maintainers are the ones steering the machines, and in LLM-unfriendly ones it saves everyone's time by not having generated PRs thrown at the maintainers.

	▲	fl0id a day ago \| parent [-]
		This is not a guarantee, as many issues either do not require a PR, or the developer does not want to implement XYZ for whatever reason.

▲

KolibriFly a day ago | parent | prev [-]

A maintainer literally can't just prompt everything themselves since there are only 24 hours in a day. Open source thrives on all the different use cases the original author never personally ran into.

	▲	thunky a day ago \| parent \| next [-]
		> Open source thrives on all the different use cases the original author never personally ran into. That's what issue trackers are meant to capture. I could see maintainers wanting to take sole control over the code, and rather than swatting down PRs they can just guide AI to fix reported issues themselves, and merge what they approve of. Cut out the middle men.
	▲	imtringued 13 hours ago \| parent \| prev [-]
		The maintainer doesn't have to prompt the feature. The maintainer needs your prompt and the discussion around the prompt. He doesn't need your code. In fact, I would say that for open source projects, the prompt should go through the project's own software factory.