👀 А код-ревью — вообще нужен для качества?

Мне иногда кажется, что вокруг код-ревью построен культ. Тимлиды часами обсуждают, как "оптимально распределять ревьювера", как "улучшить процесс", как это якобы "повышает качество продукта". Но у меня с этим опытом — по-другому.

ИМХО, код-ревью отлично работает, когда речь идёт о:
- переопылении неочевидных знаний о системе,
- менторстве и росте джунов,
- командной синхронизации.

Но как quality gate — это слабый инструмент. Он не гарантирует, что баг не пройдёт. Не страхует от архитектурной кривизны. И откровенно тормозит delivery.

Особенно в сложных фичах: чтобы оценить PR по-настоящему, нужно столько контекста, что проще сесть рядом и в паре закодить.

Если цель — ловить критические ошибки, можно же:
- сделать линтеры и написать автотесты,
- сделать чек-листы и кейсы для тестирования и самопроверки,
- уменьшить зоны неопределённости в коде
А код-ревью пусть остаётся тем, что у него получается лучше всего — развитием команды.
Может не надо натягивать его на задачи, к которым он плохо приспособлен?

Или я чего-то не вижу?
Поговорите со мной в комментах, мне очень кажется, что я что-то упускаю, а для всех это очевидно.