Or, we would have long ago found better ways to adopt design and development strategies that more generally lend themselves to rigorous and easily repeatable testing.
I don't know what that means, but I'm going to upvote you and go find out what interesting reading material I have missed!
Edit: As a rails dev, I know that there is no silver bullet, but I also know that some strategies are objectively better than others, and some strategies produce software that is easier to verify than others.
You can write heaping mounds of Javascript that you pile on top of each other, and pile more and more tests on top of each other and run them within a CI framework between each change (or don't), to build confidence that you don't break things that you previously guaranteed from one commit/release to the next...
Or you can write tiny functions with an obvious and wholly singular purpose, and build them into micro-services that deliver one small fraction of the whole service, and test at each layer, and build composable units of the final service that you intended to guarantee.
One strategy is easily verifiable if you keep it up without ceasing (and the other is not, but the two strategies are usually easy to tell apart.) Unfortunately it's probably true, for example, that neither strategy can ever be said to (obviate essential complexity! Fred Brooks) – to totally guarantee that the tail does not hit the ground on either takeoff or landing, which is a complex problem that probably can't actually be solved in units.