Hacker News

points by aeonik 19 hours ago | 0 comments

Hmm very vague. "Some of us".

Do the massive amount of vulnerabilities not make you think twice?

At this point, I trust human code less than llm code. Design and architecture of the code still greatly benefit from a good human touch, but I'm not sure how long that will remain true.

https://www.phoronix.com/news/OpenAI-948-Linux-LPE-Bugs

[–] nsbdhciebsbdhc 16 hours ago

So validate with an llm and humans. People committing code they haven't read - which will inevitability happen - is dangerous and hard to remotely verify.

[–] zdragnar 4 hours ago

People using LLMs put up much larger changes, and much faster. Depending on the LLM used the quality is often much lower.

A lot of projects just stopped accepting any outside contributions rather than deal with the tidal wave of slop they were getting. Choosing to not accept LLM code is IMHO a better compromise.

[–] rowanG077 13 hours ago

In the end there is always a separate reviewer. Even if the producer is adversial and not even looking at the code then this process exists to catch it. This is not at all different from people attempting to get backdoors into Linux.

[–] codedokode 9 hours ago

LLMs will introduce new vulnerabilities. What Linux should have done is stop using non-standard C, or better, stop using C completely in favor of Rust, support code analysers.

[–] palata 8 hours ago

And humans can introduce new vulnerabilities, too. Linux maintainers accept patches from random people over the internet. They already have to just the patch on its technical merit, not on who submitted it. For them I don't think it makes a difference (technically) if the patch was written with the help of an AI.

I believe that there may be valid reasons to refuse anything that was touched by an AI, but that's not about security. It's more about the non-technical problems coming from AI (centralising power, increasing inequalities, carbon footprint, ...).