I've had a similar problem in the past. The things I've found to be very helpful are: 1) Don't look at the PR diff as a whole, look at individual commits, and

I've had a similar problem in the past. The things I've found to be very helpful are: 1) Don't look at the PR diff as a whole, look at individual commits, and judge each one, then read the PR diff. 2) If the commits are too big to keep in your head, don't make individual sense, etc., ask your coworker to rewrite their history until you can do 1) 2b) If the individual commits make sense, but the PR still is too big to comprehend, this PR should probably be split into multiple smaller PRs which can be reviewed, approved, and released individually (or at least in sequence). 3) If you lack still lack enough context to make a good review, ask your coworker to walk you through the commit, and just explain out loud why they're making the changes they're making. Sometimes, a "rubber-duck code review" is enough. Even if it's not, any programmer can read and understand a single line of code at a time, and you can likely tell if that line of code is complex or elegant. Plus, even if you don't know the full technical context of a proposed change, people are fairly good at picking up whether another person has an explanation that makes sense, or if they seem to be making it up as they go. 4) Spend the time and do the reviews, and become more familiar with that part of the code. It sounds like right now, that part of the code has a bus factor of 1. 5) Track time spent doing code reviews, and track bugs caught during code review. Code review has notable benefits for your team/company, so justify and sell that. You have fewer bugs & a better bus factor. When estimating your next sprint (or other unit of work), know that you'll spend X hours per week doing code review, and integrate that.