Further, the fact that bugs are so easy to find by LLMs means there is strong incentives to find ways to minimize creating bugs in the first place. That could be new or better languages, less 3rd party dependencies, more vetted code, better linters, better fuzzers, whatever. The point the new reality of bugs being easy to find will, actually must, lead to less bugs eventually because the world can't function with easy to find bugs.
Especially if you use AI, let's say you have it implement a feature and then change your mind. In my experience AI makes as many if not more bugs than a human.
I think we're at the point that the best LLMs can indeed write software that's far more secure than your average programmer. Partly because the average is so terrible.
I find that often bugs will be created when using an LLM, like others have said. Saying that this can then be fixed by identifying all the bugs created by an LLM with an LLM doesnt guarantee another bug is not introduced when the LLM is addressing the initial problem.
Also, what if the LLM has a blind spot. They certainly also could be incapable of finding or fixing a bug. They dont pass any benchmark at 100% right now. Also also, guaranteeing there are no bugs in your code is like saying you have 100% test coverage, all of the tests pass, and they are written perfectly. Saying that you can simply identify and fix the bugs also assumes there is enough time and energy to find all of the bugs that exist within a project and then to address them. Even LLMs use time and energy. In a sufficiently complex system that is certainly wishful thinking.
Considering the size and complexity of a lot of modern software (like web browsers, 3d modelling software, game engines, etc.) software is just too complex to not have bugs even when created and managed by LLMs.
There will continue to be bugs in code and we will simply have to live with the fact that LLMs make it easier to exploit computer systems. I mean consider a hardware bug like Spectre [0]. If bugs like this become easier to find does that mean our existing hardware will just become obsolete more quickly? that type of problem can be addressed, but at quite a high cost.
Not sure what all of this means for the future.
0. https://en.wikipedia.org/wiki/Spectre_%28security_vulnerabil...
Read what wrote, I didn't say your program will be bug free. I said, if the LLM can trivally find the bug it will. If it can't then we're at worst, back to the state of before LLMs could find bugs, but likely much better since we fixed so many of them
So, the fact that LLMs can trivially find bugs is enough to get the bugs fixed.
You, and several others, seemed to think I was saying LLMs would fix all the bugs. I never said that. I said they'd help. Finding them is help. Writing a possible fix is often help. Writing a possible fix and seeing if they can detect a bug after the fix is applied is also help. Automating the entire things and letting LLMs fix them without review is likely not help.
This gets worse if you factor in different harnesses built for the task, and future model updates
Sure, things will get calmer than they are now, but shipping without bugs someone else considers trivial will still require more effort than most are willing to invest
I agree that LLMs make finding bugs take far less time and energy. I also agree that this should mean in the long run there are less trivial to find bugs IF everyone adopts the usage of LLMs while writing and reviewing code.
It does also seem possible that LLMs are better at finding bugs than fixing them.
Then a year or two later they'd repeat the operation and they'd find about the same amount of same types of bugs. In many occasions in code that had been in place in the previous round and had remained essentially untouched.
Paraphrasing what the Gruqg has quipped - a large piece of software has infinity bugs. Infinity minus N is still infinity.
0: Discovery rate with regards to the time spent looking for bugs. LLM-powered bug hunting has amped up the speed with which code bases can be investigated.
Many of the bugs we are finding in projects like curl are 20 years old - once they are fixed they are fixed and so hopefully we get all those 1-20 year old problems fixed and future scans only find new problems which is itself a big improvement in the rate. I agree that we will never reach a point where there are no bugs introduced, but we should strive to fix them faster.
my brother in christ, I hope you're actually trying to be funny here.
99 little bugs
take one down, patch it around
105 little bugs in the code...
But the last couple of decades have shown us that huge numbers of developers aren't even following basic and free secure development practices, let alone pouring money into expensive scanning tools.
I mean, we've had tooling like fuzzers available for a very long time, and most devs haven't run one against their software ever, let alone before each release.
It's the human factor I think will keep this a problem essentially-forever.
If all LLM reports were accurate, they'd be of any value. However, that's not what is happening. If you have even mentioned something about a bug bounty anywhere, waves of slop peddlers will flood you with fake reports marking every minor bug as a critical problem, hoping to catch a handful of dollars in the process.
These models do find some problems and may even provide decent suggestions to fix them (though they really want to add code above anything else, quickly leading to spaghetti if you accept it all). That's not the issue at the moment, and as long as people try to incentivize people to report bugs, the issue will remain.
I do expect this to be temporary, though. Not because LLMs will fix all the bugs, but because the flood of slop will shut down most public bug bounties.
Are you making a counterpoint that the reports are so good and must all be addresses, but the problem is "llm finding all the bugs" so fast us poor slow humana cannot keep up?
because if so, i suggest you write a new article.
