my technique to get a similar benefit is to write a quality PR description.

a good PR description should be compact and helpful. describing something complex in a compact and approachable way requires understanding.

the process of writing the description often leads me to understand hidden decisions the LLM made and occasionally uncovers bugs.

my PR descriptions separately answer the following questions:

Why is this change being made? a sentence or two about the problem, objective, etc, and a link to more detail (tickets, docs, etc) if available

What does this change accomplish? typically describes observable changes, requirements, etc. crucially this section avoids describing how the change is implemented. the act of separating what from how isn't new, but it's crucial in the LLM era

How does this change accomplish its goal? the answer to this question is "read the code", but the job of a PR description is to provide a quick hand drawn map before dumping the reviewer into the jungle. drawing a good "how" map requires understanding the jungle and the new path through it.

the risk with LLMs (or any outsource) doing the work is the loss of understanding. this exercise encourages understanding.