Eventually maintainers will just throw up their hands and leave the repo under the care of a LLM. "Merge PRs that align with the product's vision/design/intention. Meticulously examine for malicious contributions. Email me if there are doubts."
replyThe top tier LLMs would be as good at this as a lot of maintainers, right?
> The top tier LLMs would be as good at this as a lot of maintainers, right?
replyIn some respects maybe in others less so.
So in my situation I am using a client for a system and am using a very specific part of it even though there is a lot of other complicated code in other parts of the client. A LLM is good enough to maintain the code path I am using and of course any changes are triggered / watched over by me. In this situation I am comfortable letting LLMs do most of the code. I would be less enthused if that was outside of my control and the code changes were more often and faster.
yeah maybe. i think it's become a lot more feasible to fork and modify vs wait for new features or fix bugs. the future might be that the main repo for a project forms the "core", and consumers use their own forks which are automatically kept up to date. the core doesn't need to be as configurable or flexible as the forks can add functionality directly. in theory it could be easier for the maintainers.
reply