It very much depends on how you generate it, from prompting to test suites, but most importantly, your attitude. The extra security costs you time and money.

There are still folks, many of them, who think that time to market is everything, and anything beside it should be ignored. "It compiles? Ship it!" is a phrase from 1990s; LLMs just make this approach much easier. We will have plenty of machine-generated software with the security posture of a colander hit by a buckshot.

Its not entirely a prompt issue, but also what it was trained on.

Nowadays, the frontier is pretty decent all around, but it used to be generated php/javascript was questionable, ts was a bit better, and Rust was consistently decent.

Even just setting the max width of your README to 80 chars vs using full markdown could get you very different C code.

My take is that its pretty easy to write _much_ more secure code; use fewer dependencies and the ones you have should only do what you need them to do with no superfluous unused code compiled in. Configuring that used to be too much work, now its a single prompt.

Most software is written without giving a thought to security. Because security is a source of cost. That was the case before LLMs, I don't think it will change with LLMs.

Now I wonder: given that the LLMs are steered by the companies who own them, doesn't it mean that they can somehow make security better? It cuts both ways obviously: that a company can read and generate a large part of the code in the world is a risk.

As an open source maintainer, I can most definitely tell you that the quality of the average PR is now better. The problem I am facing is more that some people tend to "flood" and misuse AI in different ways. But their AI writes better code than they do.

I think that even worse is that AI might choose just to write something, and skip using a library that is well maintained

it costs time until the new Opus7 is trained on hardened code.