It’s probably important to define what sort of code review you are talking about when making broad claims about it.
GitHub style asynchronous pull request review with inline comments is the norm now, but it’s not the only sort of review there is. I’m old enough to remember processes that include in person reviews that were more like a dissertation defense or conference presentation.
The literature around this that shows that code review is a useful quality practice (in fact one of the only useful quality practices) comes mostly from much more structured review processes than we see now.
My personal opinion is that before llms the GitHub style pr review was for making us feel better about our processes (or governance checkbox checking) and the age of llms will sweep them away as the cost/benefit is so much worse now.
> GitHub style asynchronous pull request review with inline comments is the norm now, but it’s not the only sort of review there is. I’m old enough to remember processes that include in person reviews that were more like a dissertation defense or conference presentation.
Synchronous review is still possible today! One of my earliest managers taught me that if a "standard" code review goes back and forth more than once, it's almost always better to just hash it out in person (or on a Zoom call, when at least one person is remote) and then go back and post a comment summarizing what consensus was reached. To use a contorted technical analogy, asynchronous text communication can be lossier in terms of what information it's able to successfully encode than verbal, and the throughput is lower, so sometimes it's worth it to pay the synchronization overhead when you need to exchange a lot of information.
On one of my first jobs, I had printed off change packages which had to be reviewed and signed. There was even a person owning the final copies in filing cabinets. This was more like traditional engineering and everyone had to think of software as more permanent.