[Paul-Craft]

I'm curious now: have you ever been in an environment where automated checks have completely or nearly completely replaced code review? Mind sharing a more comprehensive list of what's hiding behind that "etc." in your comment?

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?

[ssrc]

I have no strong feelings about PRs (usually). I was acting as devil's advocate to try to answer supremekurt question in a positive way (others have pointed out the negative ways) and I ended up writing almost exactly what the article says in "Code reviews. Isn't it the past?".

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.