The value of a feature or a bugfix is not calculated from the effort required but from the need or desire for said feature or bugfix. So whether or not the barrier to entry has been lowered by llm's is irrelevant. What matters as to it's value is the result.
That might be true of the raw, unknowable "true" value of the thing, but that's not the same as what people are willing to pay for a thing.
When one evaluates a purchase, implicit in that evaluation is the option to do the work one's self. If the price you are offering a thing is more than the cost of doing it myself, then I will not buy from you.
LLM coding proponents keep saying that it reduces the cost of development to near-zero. We keep hearing about all the "things we wouldn't have done before because it was just too expensive to get people to do it."
If this is true, any day now, the customers and clients and consumers are going to catch wise and start doing it for themselves. I mean, it's been almost a year since LLMs supposedly "10x'd" everyone's productivity. I'm still waiting to see where all this singularity is, so I doubt it actually is true. But it doesn't mean you're going to achieve ungodly margins on your software sales, especially when we're talking about open source software. Value absolutely does have a component that is the cost of the inputs.
The important part is the quality of the code, how well-considered its design is, how well it gels with existing code, how readable it is to other humans, how well documented it is, how well its author understands it (and thus, can make surgical changes if needed), and how well it was tested.
A PR that implements a sought out feature or bug fix can be practically worthless if it doesn’t check some percentage of those boxes. The line differs per project naturally, but almost nobody wants a PR that is missing all of them.