Unless you work in a very complex technical domain with high profit margins. A bug in production can literally cost us billions (apart from potential reputation damage), the system is highly complex, so having 2 reviewers isn't a luxury for us but a necessity.

You could make the same argument about automation not manual process.

e.g. "A bug in production can literally cost us billions (apart from potential reputation damage), the system is highly complex, so having robust test suites, automated monitoring and rollback isn't a luxury for us but a necessity."

IMHO, automation wins every time. That is, while there is value in "stop the pipeline versions of code review", we value the automation more.

That is a perfectly acceptable alternative, but to me it feels it would put a lot of trust in automation and lower affinity with the code as it's not continuously inspected. It depends on the size and duration of the project I guess.

> code as is not continuously inspected.

That's not what I said, and is not my experience.

It depends on what is required from the reviewers.

If you have a pair with 1 person with good knowdledge of the code digging deep into what the PR/MR does, and another dev just checking for anything surprising, or even just validating that what you're doing makes sense at the surface, that will probably cover most bases.