I studied a few papers about improving code review in big orgs, and they all seem to say the same thing: it's work.

You need to make time for it, and you need to train people to do it.

Of course it is work. You need to at all times have an understanding of what is happening in the codebase you are working on. That doesn't mean knowing every nitty gritty, but it does mean being able to jump in and maintain that code if needed.

Some organizations treat code review as your personal guarantee that the code is "good" and it is your neck on the line if something goes wrong. That is absolutely the wrong way to handle changes in the codebase. It promotes delay, overthinking, kneecapping behaviors, etc. Instead, my preferred criterion for things that do not involve life & death level changes is "can the reviewer feel comfortable enough maintaining the code as written?". There will always be bugs that only pop up in prod ... If you feel comfortable enough diving into the code to fix whatever shows up, ship it.

Focusing on maintainability tends to steer conversations in the direction of "do we have good tests for this?", "is there a way to simplify this?" etc