Ограничения пропускной способности code review

У code review есть измеримые ограничения, и они не сдвигаются ни усилиями, ни инструментами. В литературе по ревью регулярно повторяются два вывода (см. reviewing-ai-code, где их приводит Depierre):

• Эффективная скорость ограничена примерно 400 LOC/час. Выше этой планки поиск дефектов резко падает. Реальная скорость зависит от контекста, типа кода и опыта ревьюера, но ~400 LOC/ч - это потолок, при котором ревью ещё надёжно находит дефекты.
• Сессия ревью упирается в убывающую отдачу после ~1 часа. Это ограничение внимания, а не покрытия кода: непрерывное ревью ухудшается спустя час независимо от того, сколько кода осталось, так что ревьюер выдерживает лишь пару эффективных часовых сессий в день, между которыми требуется время на восстановление неизвестной, но ненулевой длительности.

Следствие, важное для разработки с помощью LLM: ревью не распараллеливается внутри одной головы и не ускоряется по требованию. Если на тезис "LLM часто ошибаются" отвечать "проверяйте всё как код стажёра", то пропускная способность генерации упирается в пропускную способность ревью, а она фиксированно мала. Каждые ~400 LOC сгенерированного кода стоят примерно один час senior-разработчика, а таких часов у разработчика наберётся от силы 10-40 в неделю, причём они конкурируют со встречами, проектированием и инцидентами. Реалистичный потолок оказывается ниже ~1k проверенных LOC в день, включая шаблонный код, тесты и конфигурацию. Узкое место смещается с написания кода на ревью, и инструмент генерации не способен его расширить.

Множитель самоуверенности

Приведённые выше ограничения получены в исследованиях того, как люди ревьюят человеческий код. В отношении вывода LLM первые (пока ограниченные) данные выглядят ещё хуже по двум пунктам: ревьюеры кода от LLM находят меньше дефектов, но заявляют о большей уверенности в том, что нашли всё. В итоге пара человек+LLM может выпускать код более низкого качества, чем человек+человек, при том что ревьюер чувствует себя увереннее - потолок пропускной способности не гарантирует даже обещанной корректности. Это измеренная версия проблемы доверия, качественно описанной в credibility-as-slop-test и зафиксированной на личном опыте в know-thine-enemy.

Связь с другими концепциями

• agent-principal-agent-problem - объяснение Crawshaw, почему ревью ломается при работе с агентами (сигнал об усилиях между автором и ревьюером исчезает); эта страница описывает лежащую в основе арифметику пропускной способности.
• code-review-knowledge-transfer - эмпирическое наблюдение о том, что <15% комментариев на ревью касаются багов, поэтому реальная ценность ревью заключается в передаче знаний; обе страницы опираются на одну и ту же литературу, развеивая миф о том, что "ревью вылавливает дефекты".
• stop-using-pull-requests и ship-show-ask - процессные ответы на высокую цену блокирующего ревью.
• skill-atrophy-supervision-paradox и agentic-coding-fatigue - ограничения со стороны человека (деградация навыков проверяющего; дневной потолок принятия решений в 4-5 часов), которые усугубляют предел пропускной способности.
• control-the-ideas-not-the-code - противоположный рецепт: раз построчное ревью не масштабируется, откажитесь от него и контролируйте архитектуру вместо кода.
• cross-model-code-review - машинный ответ: вторая модель в роли ревьюера и выводы исследований о том, какая именно модель должна занимать это место.