For each claimed benefit there's another practice that is better suited, usually automatic, and should have been already implemented. For example, for catching regressions, a reasonably complete test suite. For formatting issues, IDEs and autoformat on commit. For latent errors, static analyzers, linters, run-time instrumentation, etc.
Things that cannot be automated, like understanding of the problem, design tradeoffs, etc. should have been discussed with the team before the PR, with or without pair programming.
Now, going back to reality, if all of the above is working, the PR should be a breeze and there wouldn't be much debate about them.
They also ensure that the conceptual integrity of the codebase remains intact.
Moreover, they allow a developer who is less familiar with the codebase to propose a solution, even if they might not fully grasp the entire context of the project or codebase. This is a significant advantage.
However, unfortunately, code reviews can devolve into hazing or become a means to establish power dynamics that shouldn't exist.
We should never assume the reviewer knows everything. A productive code review is more of a collaboration rather than a teacher-student relationship.
How can we automate issues like using a task UUID as a device UUID within the code? Or addressing an n + 1 problem when another API with batch functionality is available?
We can't automate those(yet)
So with any decent system, the weakest link is the people using it. If you have adversarial people on your team, and in my experience, you probably do, sometimes the system surrounding code review is far more important. IE reviewers share the blame(better yet there is no blame shit just gets fixed), and hard rules around being an asshole need to be enforced.
I realize you are describing a healthy work environment. Unfortunately, I've yet to find one. I almost made one once, but a wave of clandestine hires destroyed it and it was time to move on. Pissed off the wrong narcissist...
One reason for my curiosity is that the author isn't claiming humans can do any of those things you talk about automated tools doing better than the automated tooling does. They're talking about it as a learning opportunity to see how other parts of the codebase work, and as an exercise in communication and teaching, all of which I can see the value in. In other words, your claims and the concerns backing them seem to be orthogonal to what the author has actually written.
What do you think about that?
But yes, I've been in environments where automated checks and communication during the previous steps nearly completely replaced the need for PRs. The "learning opportunities" happened, but almost always outside a formal code review. 3 devs + PO, competent, limited scope, same room, whiteboards.
Nothing magical behind that "etc.". Formatter, linter, unit tests, integration tests and code coverage in CI to keep you honest. Load tests launched manually to detect performance regressions, memory leaks and race conditions. Specific tools vary by language and product. You can do much more but for most products it's probably over-killing.
This is the problematic step because management wants high "velocity" and "impact", I'd say it is not possible for all team members to have understanding of the problem, much less design tradeoffs.
And then there is churn. You have to explain every time there is a new team member that no, the fact that we use var in our Google analytics mess is not a good reason for you to avoid let and const in your code.
A lot of the feedback provided during code reviews can be provided by coding tools.
Thats why fuzzers are important for testing, they brute force stupidity so the users dont have to.
The only (minor) advantage I see for paired programming is when the coder is out of ideas for some code at the first stage.
Some languages are self documenting which eliminates the non coding time.
Me personally, I just hate going around in circles (loops), its not elegant code, but it has to be done.
Happens more than you would've thought, but maybe still not enough to justify the abandonment of the practice... So, in sum, I don't think it's ever worth it to skip the review process.
Also as a senior I often have to get managers or green newbies to approve, neither which can add any useful feedback.
Similar to how 'security theater' addresses perceived threats rather than real vulnerabilities.
It takes two parties atleast for productive code review
You should try asking for this permission. If you can’t get it, then you have a problem.
"How can we create an unmaintainable codebase riddled with bugs?"
Then we'd have a good reason not to conduct code reviews
Asking because I could interpret your answer both ways, and both are reasonable.