I'm not really talking about bugs. Bugs do go out in code that's been peer reviewed but peers also catch many, many issues. The catch rate becomes higher as an organization has more distinct individuals working across a larger codebase. There will be many experts and mentors who will likely be reviewing changes for those who are less experienced in the given code. These reviewers catch valuable issues before they hit production in the code review process. But again, I'm not really talking about bugs.

What I am talking about is poor or otherwise sub-optimal design. Turns out that once you commit a change you are far less likely to fix it given feedback than if addressing the feedback is necessary to commit the code in the first place. Ergo, with more subtle issues like sub-optimal design, the simple inertia of committing the code can be enough to stop both potential feedback givers and code fixers, who will subsequently live forever with the sub-optimal design. What's truly fascinating is that long-term each individual will have their efficacy dictated by how efficiently they can work with the existing codebase. Code review helps make sure everyone can work with the codebase effectively and efficiently by helping keep the design quality high.