Remix.run Logo
▲ CER10TY 7 hours ago

It's been shown to be bad at secure coding _unless_ you specifically prompt models to watch out for common vulnerabilities, at which point they're actually quite good at containing the issues, though the studies here are somewhat older (eg https://arxiv.org/abs/2211.03622).

The issue then is that most people aren't actually good at keeping an eye out for security issues in code proactively, so things slip through the cracks (whether human-written or not), just at a much accelerated pace.

▲thomashabets2 7 hours ago | parent | next [-]

That study is from 2022, with at most a last update 2023? (if I read it right)

I'm not at all saying that "oh 3 weeks ago, discard", but three years ago absolutely has a "before and after".

Three years ago AI generated code could basically not be used at all, and I had to rewrite just about every line. Today I have to watch out for generated code making steps in the wrong strategic and architectural direction, and over engineering, no longer hallucinating nonexisting APIs and forgetting to check the auth token.

I still look for those kinds of mistakes, but I think citing a 2022 paper for "can AI do X" is not useful.

▲spockz 7 hours ago | parent | prev | next [-]

It just means that the safeguard we put in place over decades of software engineering with humans also need to remain in place when engineering with agents.

Having properly validated libs with separate concerns and a lot of eyeballs (and agent sensors) on the code so that it can be integrated cleanly in other products. Static code analysis for our apps. System prompts that require output to be secure, etc.

All of these practices that have been touted to be obsolete because agents can now just generate tailor made code just when and where you need, are anything but obsolete. On the contrary, they are paramount to the future of software engineering.

▲ 7 hours ago | parent | prev | next [-]
[deleted]
▲silveraxe93 7 hours ago | parent | prev | next [-]

from your paper:

> Overall, we find that participants who had access to an AI assistant based on OpenAI's codex-davinci-002 model wrote significantly less secure code than those without access.

That model came out in March 2022, it's GPT-3.5 !!!

I'm sorry but it's absurd to use that as evidence for anything related to AI coding today.

You can't just hedge by saying "it's somewhat older". It's like discussing dunno a new train connection between cities and citing a paper measure steam locomotives.

▲CER10TY 7 hours ago | parent | next [-]

Hence why I said the studies here are quite old, and I'd like to see something more recent, though I guess it'll be some time before that's done.

I think most people writing code with AI nowadays will find it's still lacking in some areas. Not because the model isn't good (definitely miles ahead than what we had access to in 2022-2023), just because it wasn't actively mentioned and so the model skipped over it. The same will apply to security.

▲silveraxe93 7 hours ago | parent [-]

I'd also love to see recent studies. It's frustrating how even new studies end up using models which are behind the frontier at the time of publishing.

AI is advancing faster than academia can keep up. Which in general shouldn't matter. But you have this pattern where a paper comes out with a conclusion that just doesn't hold anymore by the time it's read, but people use it to form/support opinions.

▲tytho 7 hours ago | parent | prev [-]

I agree that we can’t compare older models to newer ones, but how much code was generated during those months/years when the models weren’t good at secure code? How much is still running publicly today? It’s still worth considering the impact to the overall ecosystem.

▲thomashabets2 7 hours ago | parent [-]

Luckily we have newer models going back and fixing these things.

In terms of the set of all bugs, the AIs from 2022-2023 pale in comparison with the amount of bugs written by hand in previous half century, even if 2022 AIs were worse than the average programmer.

▲ 7 hours ago | parent | prev [-]
[deleted]