If the answer were as simple as “finding defects,” then a fully automated review starts to sound inevitable (and appealing).
But if code review was also how teams shared knowledge, built collective ownership, spread architectural understanding, and taught junior engineers how experienced developers think, then the answer becomes much less obvious.
That’s the mistake I think many organizations are about to make, and the reason we need to rethink what code review is actually for.
Why can’t it be for finding defects AND the rest of the shit you listed?
It doesn’t seem like anyone anywhere needs to rethink what they are for. They’ve proven themselves over and over to be useful for all the reasons you listed.
When interviewing and companies wave away code reviews i consider it a sign of a less mature org (or maybe very small, or maybe a more R&D place).
I don’t know about this one. people at companies are pretty quick to talk about code ownership when it comes to on call schedules, but i’ve never seen them give you the code when you leave.
I also think this is not really true unless the codebase is really small. In bigger code bases broad overviews really help.