How about that these kinds of bugs are not in a class that can all be solved by a few bug fixes, but represent a very long tail of bugs that need one-off fixes.

How about that these kinds of bugs are not in a class that can all be solved by a few bug fixes, but represent a very long tail of bugs that need one-off fixes. Most software has to deal with a limited input domain, and when mistakes are made, they are tolerable. And even in the case of software in limited domains, critical bugs remain in commercial software that have been around for decades, with new bugs cropping up as the software is maintained. Now look at FSD: What is the input domain? The entire real world and the incredible diversity of variety of it. And what is the repercussions of a bug? Death or injury. So like I said, these FSD systems should be designed with a kind of "kernel" vs "user" space paradigm. The "kernel" has a mission to absolutely prevent "user" space from crashing the system. In my view, that would mean a backup sensor suite and software design whose highest priority is to avoid collision, rather than driving or navigating. All of Tesla's ML systems should be in the "user" space. They view the world, make predictions to navigate, but any control inputs they yield should always be overridden by the "kernel" if a collision is pending.