Not unlike legacy code, where the original developers are long gone and no one knows when that system breaking bug is about to wake up.
Even in the best of cases tho, fully human written and reviewed code will still fail eventually.
So I would say we are not normalizing failures (yet) but rather normalizing legacy.
Compilers actually actively try to stay deterministic in their output.
Say that with confidence now. You'll say with shock and incredulity later, "It can be fix? Right?!?!" (Cue some meme). Reproducing bugs is often hard for well designed systems. For randomly designed systems, it's a nightmare.
Fixing software is hard and fixing bad software is harder and fixing software where you didn't even think at the time how to make it maintainable is hardest.
Legacy systems are usually systems that were well designed at the time. That's why it's worth fixing them now.
--> And none of this is saying AI designed systems are bad. But if the only criteria is "code is deterministic by default, it works and we can fix problems later" then AI seems likely a terribleness accelerator.
Code written with AI can be fixed, if well designed, they are not mutually exclusive.
Also legacy systems were absolutely not always well designed, I've picked up a fair share of systems that were absolutely not well thought out, usually due to time pressure, or any other context specific reasons.
I do believe we are creating legacy systems faster now, and it's because teams are unable to keep up with the speed of changes, not because their system is not meant to be maintainable.
My point remains tho, using AI doesn't have to mean normalizing failures.
Nice way of putting it.
I know because I've spent the better part of a year having them do exactly this as a precursor to rewrites in more perfomant tech stacks. Once this research is done, it's a fairly safe and mechanical translation job.