I.e.: "What do we want this software to do" and more importantly "What do we want this software to *not* do".

It depends on where the project is in its lifespan. "What do we want this software to do/not do" is mostly a question for a project that's still adding features. If the project isn't adding features- and a lot of the kind of projects that are chronically short on developer time aren't- it's mostly made up its mind about what it will and won't do. In that case, the main job is dealing with bugs and maintaining compatibility with any changes in dependencies. There is some question about what exactly classifies as a bug- it does require judgment about whether the alleged behavior is intended or not- but even that is less of an issue with security bugs.

Getting back to the original question, I suspect most less active projects will find LLM bug finding to be a bad thing overall. They're less active either because they're in maintenance mode or because the developer just doesn't have time to do more. Either way, a sudden flood of bug reports is likely to be overwhelming. Meanwhile, the developer wasn't doing a whole lot with the project already, so being able to spend a little less time on it once the flood of bugs is dealt with won't be much consolation.