Bruh
Bruh
The myth that we've been shipping perfect code for years, but you can't trust LLMs, is just subjective blindness. People can't see the issues that they can't see, definitionally.
You can absolutely use the exact techniques we used to use in "the old days" to produce reliable code with LLMs generating most of it. The issue is, it's really not a lot less conceptual and intellectual effort than in "the old days", at root. You speed up the programming part, but the rest is still a hard slog, so nobody is out here doing really thorough testing in ways we used to dream of.
I’m still in the process of revisiting and refining the many hand-coded dependencies that I’ve created, over the years.
Most of the issues found, were corner cases, that would likely never be encountered, but they are issues, nonetheless.
When I started, I had to review every line, and frequently found bugs, but lately, I’ve been impressed with the quality of the code. I don’t think that I’ve had to make any code-level adjustments, in a while.
I'm sorry to be the bearer of bad news: human coding has not improved a lick since then.
This can be seen more clearly with self-driving cars as an example. A self-driving car may be safer than a human driver, but when the self-driving car plows into the side of a semi truck in broad daylight… that’s generally not a mistake a human would make. Humans and AI have different failure modes, so when AI fails where we generally wouldn’t, it really stands out and gets judged harshly.
There are two steps to writing the program: building a model in your head to map understanding to algorithms, and then implementing the algorithm in code (and of course this can get recursive if the algorithm relies on other high-level mechanisms, like data structures).
I have found that most of the time, the kind of bugs that unit tests find are typos, i.e. mistakes in the second step; but the errors that actually cost time to resolve are errors in understanding, i.e. the first step.
They can't be found with testing or verification because what it means for code to be correct depends on the specification, and the error is that the specification itself is incorrect. Asking an LLM to check this one specific part of the software is thus useless, and whole-program analysis is not cheap enough to employ at this point.
So what about avoidance? When I say hand-written code is 100% correct (or at least approaches that number), I mean that with experience, I learn more about which models tend to be correct, and thus avoid bugs of the latter kind by construction. Of course typos still exist, which is why I write unit tests, and I expect LLMs to be able to find them as well; but I believe the only way to avoid incorrect models is to learn stuff by doing, failing and failing again, figuring out nitty-gritty low-level details, until at some point you become an expert in that area and know what to use.