the intent is to reduce the number of bugs The intent covers much more than that.
Code reviews help to share knowledge within the team, making people more aware of what changes
Code reviews help junior to ramp up: feedback given during a code review is not just to spot mistakes, but also ask questions, and it’s a fantastic opportunity for 'juniors' to ask more senior devs why they did this or that, what are the benefit of this design (versus another idea they have), ...
Code review help more experienced developers review their assumptions, and verify their design and implementation are clear. Working code is not enough. We need to aim for maintainable and debuggable code. Only an external reader car judge if the code is obvious or not, and we need those extra eyes to raise questions and verify the stuff we write is obvious enough so that when we come back later to change it, debug it, improve it, we’ll find it obvious and we’ll be able to work on this.
Finally, from my point of view, code review is not about spotting other people mistakes, but more about sharing the blame ;-) Once you manage to make this shift of perception in people minds, then people want to be reviewed. If a bug is later found, all the reviewers own the bug, the responsibility is shared. Nobody wants to be the guy who introduced the issue. When there’s no longer one single person who introduced a bug, people do not fear the review, they ask for it.
All this only works if people are doing it seriously, with empathy. We need to foster a culture of blameless troubleshooting, and to share the knowledge and help teammates to ramp up and make progress. It’s not a competition, it’s team work!