What would "pro-LLM" look like to you?

Ex: Security-critical code contributions should be scrutinized via state of the art tooling, including but not limited to fuzzers, linters, and adversarial LLM review. For non-security-critical code, use of LLMs is encouraged but not required. The bar for code quality should be raised as the skills of coding agents increase; a developer's choice not to use LLMs is no excuse for miskates that an LLM would catch.

▲

eterm a day ago | parent | next [-]

That's an interesting opinion, and I certainly won't downvote you for sharing it, although it's not a position I would ever support. You are right though, that it would strengthen the voted-on position if there were more options either side of the position.

I have Things To Say about LLM reviews.

They are an endless grind. My biggest source of burnout right now is never being able to finish anything, because the LLM always finds, "Just one more thing" every time I send it back.

It's pure polish. The major issues were dealt with long ago. But there's always one more thing that could be done a little better, there's another niche edge case that needs wrapping up.

When human developer time was the limiting factor, it was easy to draw a line in the sand and say enough is enough.

It's harder to say no when it's just one more prompt and one more go-around.

Demanding LLM reviews on volunteer maintainers sounds like a great way to quickly end up with no maintainers.

▲

dooglius a day ago | parent [-]

I'm not advocating for this, but it's a example of a position reasonable enough I'd expect to see some level of support for. I'd view it as less extreme, for example, than requiring all new security-relevant code be in Rust, which is certainly something I've seen argued for in various contexts.

	▲	eterm a day ago \| parent [-]
		While not "only Rust", that development should be done in memory safe languages is the position of the US Government: Held both weakly by CISA: https://www.cisa.gov/resources-tools/resources/memory-safe-l... And more strongly by the NSA: > NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection C/C++ and assembly, to a memory safe language when possible. Some examples of memory safe languages are Python, Java, C#, Go, Delphi/Object Pascal, Swift, Ruby, Rust, and Ada. From https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

▲

tambre a day ago | parent | prev [-]

Meanwhile there's unfortunately still plenty of maintainers refusing to use version control systems...