For the record, I did not downvote anyone.

>[Inspecting assembly and caring about its output]

I agree that it does not make sense for everyone to inspect generated assembly code, but for some jobs, like compiler developers, it is normal to do so, and for some other jobs it can make sense to do so occassionally. But, inspecting assembly was not my main point. My main point was that a lot of people, probably many more than those that inspect assembly code, care about the generated code. If a C compiler does not conform to the C ISO specification, a C programmer that does not inspect assembly can still decide to file a bug report, due to caring about conformance of the compiler.

The scenario you describe, as I understand it at least, of codebases where they are so complex and quality requirements are so low that inspecting code (not assembly, but the output from LLMs) is unnecessary, or mitigation strategies are sufficient, is not consistent with a lot of existing codebases, or parts of codebases. And even for very large and messy codebases, there are still often abstractions and layers. Yes, there can be abstraction leakage in systems, and fault tolerance against not just software bugs but unchecked code, can be a valuable approach. But I am not certain it would make sense to have even most code be unchecked (in the sense of having been reviewed by a programmer).

I also doubt a natural language would replace a programming language, at least if verification or AGI is not included. English and Mandarin are ambiguous. C and assembly code is (meant to be) unambiguous, and it is generally considered a significant error if a programming language is ambiguous. Without verification of some kind, or an expert (human or AGI), how could one in general cases use that code safely and usefully? There could be cases where one could do other kinds of mitigation, but there are at least a large proportion of cases where I am skeptical that sole mitigation strategies would be sufficient.