It might just mean the opposite. Unergonomic and/or slow memory safe languages might not be needed anymore at some point, because LLM can check for reasonable programming patterns and can do some amount of vulnerability checking upfront. But seriously the first point -- as long as you keep to a known set of reasonable patterns (much larger set than the sets accepted by restrictive and cumbersome type systems), memory unsafe languages are actually pretty safe, and the code remains easy to understand, easy to maintain, and performant.
Already today, in my experience, widespread models like Claude 4.6 or 4.8 can quite reliably find some concurrency bugs that are easily missed by humans.
> can reliably find some
Some.
In software & in security, 99% is a failing grade.
So is 99.99%, so is 99.999%, and any other amount less than 100%. It’s not enough to point 5 LLMs at it and it’s not enough to point 500 LLMs at it.
The field needs to seek deterministic & comprehensive solutions to whole problem classes.
Okay, so the whole world is failing and success doesn't exist.
Maybe now you need a better criteria than your previous failure / success_100%_infiniteCost to observe and understand the the world
This logic enables and encourages corruption in all spheres of life. "Things are messed up as they are, so why try so hard to do the right thing?" "Let's be realistic."
The logic allows that to continue because "good" and "better" isn't good enough, only "perfect" is allowed, so instead "nothing" is done
It's not as black and white as you claim. 99% is obviously much better than 0%, and 99.999% would be an exceptional, unheard-of improvement. In most software projects, this would find ALL bugs.
And most "memory safe" languages are not all that memory safe. Or they need escape hooks.
EDIT: To be clear it's not AT ALL black and white. You have drunken too much of the type safety kool-aid.