For the most part, I think "you can't bolt on quality after the fact" is true. Code reviews and CI/CD automated-tests are helpful, but can never be thorough enough to catch every mistake that a low performing developer might make.
If that developer causes enough problems over time, that is absolutely something that their manager can and should address.
I'd think about actioning the individual only if it was exactly the same issue every time (how did the same issues manage pass time and time again, didn't we learn anything as a team?). Otherwise I'm more in the mentality that breakages are a great way to improve internal flows against (inevitable) failures.
I think the real problem would be when a developer cannot manage to get any code into production (e.g. Code stuck in PR for weeks) but once the rest of the team and our systems approve it then they have proven their worth.
Also, if developer X's code keeps passing code reviews, CI/CD, QA and UAT, and it's not the fault of the systems in place, I would ask myself what kind cutting edge stuff are they working on?
For the most part, I think "you can't bolt on quality after the fact" is true. Code reviews and CI/CD automated-tests are helpful, but can never be thorough enough to catch every mistake that a low performing developer might make.
If that developer causes enough problems over time, that is absolutely something that their manager can and should address.