Egregoros

@p @lumi Well LLM code is going to be statistically average at best, and at very least 90% of code is pure crap nobody wants to read (and so nobody reads).
But it's far from the only problem, like AT&T Unix code was (and quite few times still is) great, but nobody would touch it for anything legal back in the early 90's and even now it's still a bit unclear depending on the versions.

Plus outside of purely code, since then there's also the absolute spam of completely bogus security reports, same breed as people throwing a full set of static analyzers and fuzzers without any kind of thoughts in their brains, except now it's with stuff that doesn't even qualifies as tools.

@lanodan @lumi

> LLM code is going to be statistically average at best, and at very least 90% of code is pure crap nobody wants to read

Sure, yes. Reasonable.

> but nobody would touch it for anything legal back in the early 90's

Right, yeah. on FSE comes from a photo of bwk holding up his copy of Lion's Commentary when AT&T finally announced that they were going to stop suing people for using that book, and there was the whole SCO thing. AT&T got litigious as soon as they possibly could.

(I think copyright assignment mainly makes extraction/relicensing easier.)

> there's also the absolute spam of completely bogus security reports

This is real, yeah, but people that are putting clankers to your codebase are, by their nature, not paying attention to contribution guidelines; I don't think a rule against clanker code stops the spam, it just gives you a thing to point to when you ignore the spam, and you don't really need that. You can just put something about ignoring clanker-submissions and that's kind of a hint to people that are people to avoid looking like clankers.

@lanodan @p @lumi
>>And 9front's even more elegant:
>3. Submitted code is not computer-generated

Technically that bans also completely mundane stuff like auto-generated headers from things like device trees/spec sheet documentation or m4 macro expansions. Of course it will never be enforced that way.

>and at very least 90% of code is pure crap nobody wants to read (and so nobody reads).

Things got way better in the last year or so with new-ish models. If you take the time to set up a workflow for the new models, the results are still somewhat easy to distinguish from non-clanker contributions, but they aren't bad either and usually require some smaller fixups and removal of some overly defensive checks. If done by someone that knows stuff at least. And even with the "chat in a browser window" way, you can get decent-ish results if you keep things small.

>Plus outside of purely code, since then there's also the absolute spam of completely bogus security reports

On the other hand you also have security reports with really high severity that were found within a day or two of letting a model loose on a codebase. The recent nginx CVEs were all found by LLMs, most of the recent Linux LPEs as well. The way I see it is the same as static analyzers and fuzzers, a useful tool in the hands of someone knowing how to handle it.