Sounds like a lot of FUD to me — if major projects balk at the emergence of new classes of tools, perhaps the management strategy wasn’t resilient in the first place?

Further: sitting down to discuss how your project will adapt to change is never a waste of time, I’m surprised you stated it like that.

In such a setting, you’re working within a trusted party — and for a major project, that likely means extremely competent maintainers and contributors.

I don’t think these people will have any difficulty adapting to the usage of these tools …

> if major projects balk at the emergence of new classes of tools, perhaps the management strategy wasn’t resilient in the first place?

It's not the tools, it's the quality. No FOSS dev would care where the code came from if it followed the contributor's guidelines and coding style.

This is why it's a spam issue. a bunch of low quality submissions only gum up the time of such developers and slows the entire process down.

>that likely means extremely competent maintainers and contributors.

Your assumption falls apart here, sadly. Dunning-Kruger hits hard here for new contributors powered by LLMs and the maintainers suffer the brunt of the hit.

> Further: sitting down to discuss how your project will adapt to change is never a waste of time, I’m surprised you stated it like that.

It is a waste of time for large-scale volunteer-led projects who now have to deal with tons of shit — when the very topic is "how do we fend off this stuff that we do not want, because our project relies on much deeper knowledge than these submissions ever demonstrate?"