zlacker

>>chwtut+(OP)
To play devil’s advocate: We’ve vendored a few open source projects by just asking an LLM to fix obvious bugs that have been open for 12+ months (some projects are abandoned, others active).

If upstream can’t be bothered to fix such stuff (we’re talking major functionality gaps that a $10-100/month LLM can one-shot), isn’t my extremely well tested fix (typically a few dozen or maybe hundred lines) something they should accept?

The alternative is getting hard forked by an LLM, and having the fork evolve faster / better than upstream.

Telling people like me to f—— off is just going to accelerate irrelevance in situations like this.

>>hedora+OB2
I agree with you, but I don't envy the maintainers. The problem is that it's really hard to tell if someone is skilled like you or just shoveling what an LLM wrote up to the maintainers to have them "figure it out." Honestly, getting a library hard forked and maintained by people that can keep up with the incoming PRs would be a relief to a lot of folks...

>>TheTay+6C2
Oh, to be clear, there’s no way we’d want incoming code for these forks.

Incoming bug reports or design docs an LLM could implement? Sure.

Maybe something like the Linux approach (tree of well-tested, thematic branches from lieutenants) would work better. We’d be happy to be lieutenants that shepherded our forks back to upstream.