Actually, where the consequences of bad code are known to be drastic, a lot more time
is spent on code quality. I worked on factory software at AMD for a while in the late 90s and early 2000s. The adage around there was that if the fab was down, it cost us a million dollars an hour. So we had a ton of testing, red tape, bureaucracy, and so on as part of change management. We did major upgrades and such on the 4th of July or during Christmas week, because those were the only times when the fab was down for more than an hour at a time (the hour was once a week at the weekly shift meeting for fab workers, IIRC). In preparation for those upgrades, we had a system set up as a duplicate of the (very expensive) production hardware and we actually rounded up the whole team and did dress rehearsals of the upgrade process, with go/no-go decision times built into the schedule based on timing how long it would take us to roll back the whole massive database from backup in time to ensure there would be no unscheduled downtime.
We also had some folks who had come to the company from Lockheed. They helped upgrade our procedures, because as you might imagine, defense contractors are even more hardcore about all this than factory control systems. If you make a mistake in the embedded code inside a missile or airplane, things blow up (the wrong things!) and people die.
This is more or less the opposite of a typical startup, where velocity is normally far more important than creating sufficient failsafes against any possible error.