Take this with a grain of salt, but a good code review should be an exploratory process. Most of the non-trivial comments should be questions[0], and the review

Take this with a grain of salt, but a good code review should be an exploratory process. Most of the non-trivial comments should be questions[0], and the reviewer should be operating under the assumption they'll have to jump on a call or even fix it themselves. [0] Not just because the reviewer is trying to be nice, but because they don't know what constraints and problems the author discovered in the process of writing the PR. If the reviewer writes "use a map here, instead of scanning an array" without knowing how many items are handled, then they may be making the PR worse by replacing a cheap linear scan over a maximum of 50 items with a bunch of costly yet constant time hashing. Often the solution is an explanatory comment rather than the "obvious" fix.