This shouldn’t really matter, software can also be written by very bad coders.
If you care about safety, you care about the whole process—coding, sure, but also: code review, testing, what the design specs were, and what the failure-path is for when a bug (inevitably) makes it through.
Big companies produce lots of safety critical code, and it is inevitable that some incompetent people will sneak into the gaps, there. So, it is necessary to design a process that accounts for commits written by incompetent people.
However, part of designing and upholding a safety-critical software development process is looking for places to reduce or eliminate the introduction of bugs in the first place.
Strong type systems, for example, eliminate entire classes of errors, so mandating that code is written in X language is a pro-active process decision to reduce the introduction of certain types of bugs.
Restricting the use of AI tools could very much be viewed the same way.
> This shouldn’t really matter, software can also be written by very bad coders.
The issue is that there is a non-zero likelihood that a vibe coder pushes code he doesn’t even understand how it actually works. At least a bad coder had to have written the thing themselves in the first place.
For something safety critical, individual programmers shouldn’t be able to push code directly anyway. However, a vibe-coder spamming the process with bad code could cause it to jam up, and prevent forward progress (assuming the project has a well designed safe process).
I guess I did assume, though, that by “in any safety-critical place” they meant a place with a well-defined and rigorous process (surely there’s some safety-critical code out there written by seat-of-the-pants cowboys, but that is just a catastrophe waiting to happen).
I think it's even more likely at a lot of big companies, especially when a lot of upper managers feel like a developer is an interchangeable cog and there isn't any variance in terms of value beyond output.
If you care about safety, you care about the whole process—coding, sure, but also: code review, testing, what the design specs were, and what the failure-path is for when a bug (inevitably) makes it through.
Big companies produce lots of safety critical code, and it is inevitable that some incompetent people will sneak into the gaps, there. So, it is necessary to design a process that accounts for commits written by incompetent people.