It’s interesting how AI may both raise and lower the quality of software. It’s very easy to send an AI agent on an open-ended bug hunt, and if it wastes a bunch of time and effort and finds nothing, no big deal. Time is much more important for a human developer with a salary.
No one can keep up with the volume of code AI produces.
We wont stop using AI.
We will use AI to check AI.
Of course this is crazy, but it will also unlock pretty insane scaling and productivity and ultimately we will manage it on either end via requirements and tests.
You're suggesting that LLMs get better at fixing bugs/vulnerabilities, but at the same time stop getting better at finding them? What if this difference is inherent and essential?
The missing part of this is that verifying the bug with LLMs is also easy, and so is adversarially reviewing the proposed fix with LLMs.
The only thing left for you to do should be directional decisions. The LLMs should pause and rope you in if the fix involves directional/invariant changes.
I don't care if you call it an over-engineered looping machine or what, there are concrete benefits to using LLMs for this. They work faster than developing your own looping algorithm and more often produce useful results than not.
I dislike AI, but if AI finds real bugs then this is in my opinion objectively a positive thing. Of course the question is what constitutes a real bug.
No doubt fuzzers (vibecoded or otherwise) can be powerful, but can't you just mark all "/" as potential divide by zero errors?
I guess sometimes developers think they "know" some variable won't be zero, but unless it checked explicitly or by the compiler, that shouldn't be trusted.
> but can't you just mark all "/" as potential divide by zero errors?
If you’re accepting large false positives rates: yes.
If you want users to take your warnings serious: no.
(Nitpick: you certainly don’t want to flag _all_ of them. Divisions by non-zero constants definitely should be excluded, for example (integer division by -1 can lead to overflow, but that would be a different warning))
I mean there could be a guard clause? But yeah, seems like this could be statically evaluated like how some IDEs see a null check and don’t complain about nullability within the same scope.
The open ended bug hunt is the best use case for these agents. Finding nothing costs a few dollars, finding a division by zero in ffmpeg pays for itself.
Unrelated to the submitted link -- just checked your comment history and all of your comments are AI-generated like this one. What's the motivation for this?
The fruits of using LLMs to code.
You'll waste far more time finding what it quietly and subtly wrecked than you would have if you just coded it yourself.
It’s obviously Claude 69 with time travel functionality, that’s too dangerous to release to public. They’re working on space-time limiting sandbox to prevent these issues.
We wont stop using AI.
We will use AI to check AI.
Of course this is crazy, but it will also unlock pretty insane scaling and productivity and ultimately we will manage it on either end via requirements and tests.
The only thing left for you to do should be directional decisions. The LLMs should pause and rope you in if the fix involves directional/invariant changes.
They find bugs but whether they save time is nowhere near as clear as you try to insinuate here.
No big deal? It’s not like it’s free… tokens cost money.
I guess sometimes developers think they "know" some variable won't be zero, but unless it checked explicitly or by the compiler, that shouldn't be trusted.
If you’re accepting large false positives rates: yes.
If you want users to take your warnings serious: no.
(Nitpick: you certainly don’t want to flag _all_ of them. Divisions by non-zero constants definitely should be excluded, for example (integer division by -1 can lead to overflow, but that would be a different warning))
Generating correct input to get deep into the call stack and then finding something is the hard part.
They only suggested a basic guard, chich can be useless if this case never happens
https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/8eda3c7f91e1a5b...