Yeah, the smarter way to use LLM-based agents is carefully defined tasks. Mozilla describes their vulnerability assessment processes in this blog post.

Mozilla describes the process they've used: building a harness that instructs a model to find a specific category of vulnerability on a specific interface, and then write up its findings. It's a narrow enough context that the model gets specific instructions, and a simple definition of success, and it sets up many such tasks that can be fed into the existing process for verifying and triaging bugs. Note that the output for this LLM pipeline basically feeds into the same interface for accepting bug reports from the public, or from their human contributors within the project.

There's a couple of takeaways here, too:

• This pipeline is model agnostic. Mozilla set it up before Mythos was released, and its description of other models (Opus 4.7, Codex) confirms that Mythos is better but not a true game changer. The ability to swap out other models provides some assurance that the work done to develop the pipeline will be useful when cheaper or better models come along, or when a model becomes unavailable (like when a provider decides a particular model is too expensive to run, or a provider goes under).
• The increase in automated output (and presumably automation-assisted contributions from the public) has given the humans more work to do. Automation in this context actually increases the demand for human labor.
• Other projects will need to develop their own custom pipelines, specific to their project, to get good results from LLM based agents.

There are ways to use these tools, but none of it really seems like a truly revolutionary/disruptive change to how large projects are managed.