That was going to be my comment on the title. If your code reviews are &quot;...just for catching bugs&quot;, you&#x27;re doing it wrong. I put another comment in this thread describing a crappy line of code. It works (I wrote the test for it), but my...$DEITY could it have been easier to read, and made more maintainable. But it apparently sailed right through code review.<p>Like you, I&#x27;d say that code review isn&#x27;t for catching bugs at all. Is it readable? Can some Shmoe off the street who is hired to maintain make sense of it? How&#x27;s the complexity? Do I need to maintain eight different states in my head to grok it? Et. al. Now, a team can help <i>prevent</i> potential bugs (either outright as the code stands, or bugs introduced later when someone tries to maintain it and it&#x27;s a pasta derivative) with code reviews. I mean, didn&#x27;t we run the unit tests we wrote before we submitted it for code review? Why are we finding bugs just by looking at the code?