Well, as someone who had a decade of experience with the codebase I absolutely submitted PRs which were largely unreviewable because nobody else had that level

Well, as someone who had a decade of experience with the codebase I absolutely submitted PRs which were largely unreviewable because nobody else had that level of experience. My safety net wasn't code review it was writing tests, and actually firing up the product and determining that it worked (which a large amount of people actually never bother doing, and I'd prefer that over code review any day). In those cases we'd do some knowledge transfer, but I can't turn someone into a veteran with decades of experience in an hour or two of code review. I'd actually be happy to do a week of knowledge transfer on the issue and treat it like a PhD dissertation defense (which is about what they were sometimes), but nobody else would want to commit that kind of time, and no manager would want to commit the team to that kind of time. And for knowledge transfer what usually works better is having more junior members of the team doing work on subsystems and guiding them through it. Even if it isn't peer review or pair programming, the iterative process of them hitting walls and asking questions is generally the best learning. That works better because they go off and commit the time to struggling with the problem, and then guidance has that platform to build on top of. And you don't understand unknown-unknows... You can't address that by code review or knowledge transfer or peer enforcement, because it is all the absolute unknowns. A healthy skepticism can help prevent risky changes, but at some point the bugs that get through are often completely out of left field that literally nobody could have foreseen. There is no perfect process that can prevent those kinds of defects.