Not sure how much experience you have, but I'm 25+ years at this point.

Just make sure the project is well structured and things are put in the right place so you can at least get the gist of a chunk of code's purpose. Then drill down as needed adding fidelity to your understanding. There is no secret sauce here other than practicing reading lots of code.

For very large change sets (because your coworker is a lazy fuck), mentally pick out the automated shit like variable/function/class renames, function/interface abstraction, basically whatever your IDE can do and discard them. That is just noise. For the rest, start with their commit message that should describe the change in sufficient detail and look specifically to validate its claim. It can help to ignore the diff and instead just checkout their branch and read through the finished code with all the nice things your IDE provides to follow calls, look up definitions, etc. and mentally/actually run the code to see evidence of the expected change.

The other thing you can/should do is tell him to break up his commits and direct the agent in smaller steps. I've legit done this in the before days to prolific peeps I've worked with. Believe it or not, the introduction of agile/sprints and all that nonsense helped to keep commits smaller simply because you don't have time to keep a long lived branch. It was (and still is) good kata to layer your changes in commit-by-commit such that the mutation is a smooth, deployable gradient of incremental changes.

TL;DR: Tell him to quit being fuckin lazy.