In all seriousness, wasn’t that always the case? Writing bad code is relatively cheap.

Ensuring code isn’t bad is the expensive part.

For now, maybe, yes? But the most important targets of this kind of work aren't AI outputs; it's legacy code, particularly (but not exclusively) old memory-unsafe code. In those situations the figure of merit isn't the token cost of recreating the target code; it's the cost of finding the same bugs with humans or preexisting tools.

Those costs can be extremely high.

There's a parallel between looking for bugs and mining. As models get smarter, they'll find "deeper bugs".

I expect at some point formal verification will become more economical than red teaming. Writing it correctly is more expensive, but it may be cheaper than trying to secure incorrect software.

(Or rather, as hacking incorrect software becomes vastly cheaper, the amount of software worth writing properly will increase.)

I've been thinking, by Dijkstra's standards we have already been vibe coding for almost a century :)

Not if the original code is secure...

Are AI firms going to charge us to write code, and then charge us even more to secure it?!

Given the slop that's made its way to Github we can see that this is a great profit model. Ship slop and then "fix" slop. What an efficient use of our planet!

It's weird because why can't they train the AI to simply output secure code?

The basic security flaws with regards to input validation and overflows should never ever be output by an AI. For "security flaws due to bad design" I'll cut them slack until AGI is achieved.