I agree about what to expect from a code review - but for me, certain ways of working need to be in place for this to function properly. A code review is the "

I agree about what to expect from a code review - but for me, certain ways of working need to be in place for this to function properly. A code review is the "last line of defense" (well, disregarding CI), but in the teams I've worked in, that meant that the general idea of what the PR is introducing has been discussed by multiple people at that point. (This could be either a pairing session, an in-depth explanation, or just a coffee chat, depending on the complexity) This way the PR isn't about reviewing the general strategy (splitting off a new module, introducing a huge dependency, reworking the API surface), but just about reviewing the tactics used to implement that strategy. Without the communication beforehand, doing only sanity checks on parts of the code in isolation does run the risk of fracturing code ownership. ("What's that module doing?" "Beats me, ask bob") That all notwithstanding, I like the author's idea of what a diff view should look like, regardless of the "mode" of reviewing.