Хватит использовать Pull Request'ы

Эссе Andrea Laforgia в Substack за март 2026 года сводит воедино два десятилетия рецензируемых исследований, масштабные отраслевые данные (DORA, Microsoft, ThoughtWorks) и консенсус практиков, чтобы доказать: стандартный процесс с pull request'ами представляет собой "контроль качества постфактум" по Демингу, и более эффективные практики уже существуют. Статья выступает не против ревью как такового, а против использования блокирующих асинхронных PR по умолчанию.

Происхождение категориальной ошибки

Команда git-request-pull (Торвальдс, 2005) и веб-интерфейс PR на GitHub (2008) создавались как механизм привратника для недоверенных контрибьюторов, отправляющих код в репозитории, которыми они не владеют. Для open source это было настоящей инновацией. Категориальная ошибка заключается в том, что команды доверяющих друг другу коллег переносят эту же модель внутрь компании: они получают все трения без несоответствия уровней доверия, ради устранения которого эти трения и вводились.

Формулировка Тьерри де По (Thierry de Pauw): "Pull request'ы созданы для того, чтобы упростить приём правок из внешнего мира, от незнакомых людей, которым мы не доверяем". При переносе на команду, где каждого сотрудника нанимали с расчётом на доверие и компетентность, эта модель закладывает ложное допущение.

Это та же структурная критика, которую i-dont-want-your-prs ведёт со стороны мейнтейнера, только статья Laforgia написана до эпохи активного использования LLM и опирается на классические исследования в области программной инженерии.

Миф о поиске багов

Самое распространённое обоснование код-ревью звучит так: "чтобы находить баги". Рецензируемые научные данные показывают, что это в основном заблуждение:

Microsoft Research 2015 ("Code Reviews Do Not Find Bugs"): лишь малый процент комментариев к ревью относится к багам; большинство касается структуры и стиля.
Bacchelli & Bird 2013 ("Expectations, Outcomes, and Challenges of Modern Code Review"): <15% проблем, обсуждаемых на ревью, напрямую связаны с багами. Основная польза заключается в передаче знаний, осведомлённости команды и поиске альтернативных решений.
Одна неназванная крупная техкомпания после анализа 9 миллионов код-ревью: передача знаний является основным источником окупаемости (ROI). До 75% комментариев влияют на расширяемость и поддерживаемость, а не на функциональность.

Статья точна в формулировках: это не делает код-ревью бесполезным. Она помещает его ценность в code-review-knowledge-transfer - а блокирующая асинхронная очередь является одним из худших механизмов для подобной задачи.

Математика времени ожидания

Если написание изменения занимает 10 минут, а ожидание ревью - 1 час, то код проводит в ожидании 86% своего времени выполнения (lead time). Если ревью занимает один рабочий день, код проводит 99% своего существования в ожидании человека.

Цифра от клиента Фаулера, служащая опорой статьи: 130 000 часов в 2020 году ушло на ожидание 7000 PR, не получивших вообще ни одного комментария (91% всех их PR). Подавляющее большинство было одобрено без реальной вычитки (rubber-stamped), но всё равно привело к задержке.

Ущерб усугубляется переключением контекста: разработчики ждут в среднем 4 дня; 86% PR обрабатываются в условиях смены контекста; PR, требующие переключения контекста, закрываются на 223% медленнее, чем те, где контекст не менялся. Восстановление ментального контекста после открытия PR занимает от 30 до 60 минут, если вообще происходит.

Взгляд Рейнертсена (Principles of Product Development Flow): PR создают ложную мотивацию к увеличению размера партий (batch size). Поскольку транзакционные издержки на получение ревью высоки, разработчики упаковывают больше изменений в каждый PR, чтобы их амортизировать. Большие PR хуже поддаются ревью. Цикл замыкается.

Наблюдение Драгана Степановича (Dragan Stepanovic) по более чем 30 репозиториям: команды с небольшими асинхронными PR иногда имеют меньшую пропускную способность, чем команды с крупными PR, так как ожидание -> высокий уровень незавершённой работы (WIP) -> меньше доступности для ревью -> больше передач задач между людьми -> больше ожидания. Команда превращается в "N команд из одного человека".

Данные DORA

Книга Accelerate (Forsgren, Humble, Kim, 2018) и последующие отчёты DORA, охватывающие более 36 000 специалистов:

Trunk-based development коррелирует с более высокой эффективностью поставки по всем метрикам.
Элитные команды, достигающие целевых показателей надёжности, в 2,3 раза чаще используют trunk-based-development.
Модель компетенций DORA прямо называет "тяжеловесные процессы код-ревью" препятствием.
Одно лишь ускорение код-ревью повышает производительность поставки ПО на 50% (отчёт 2023 года). Проблема заключается именно в скорости, а не в самом факте проверки.

Оговорка, которую автор честно приводит: данные DORA показывают корреляцию, а не причинно-следственную связь. Высокоэффективные команды, внедряющие TBD, могут иметь лучшее финансирование или более зрелую культуру. Однако стабильность результатов на протяжении многих лет и десятков тысяч респондентов делает их сильнейшим доступным отраслевым доказательством.

Альтернатива T*D

Laforgia вводит термин T*D как объединение трёх практик с одинаковыми инициалами и общей философией сдвига влево (shift-left):

Test-Driven Development - исследования Microsoft/IBM: снижение дефектов на 40-90% при росте времени разработки на 15-35%. Каждая строка удовлетворяет тесту ещё до того, как попадёт к кому-либо; для проверки "работает ли это" человек-привратник не нужен.
Trunk-Based Development - ежедневная интеграция в основную ветку, ветки живут меньше суток, для незавершённой работы используются feature flags. См. trunk-based-development.
Team-focused Development (pair-programming, ансамблевое/моб-программирование) - проверка происходит в процессе создания, а не после.

Важнейшее эмпирическое утверждение принадлежит Мюллеру и Тихи (Muller & Tichy, 2005): парное программирование и одиночная разработка с последующим peer review дают одинаковые затраты при равном качестве. Фаза ревью при одиночной работе добавляет ровно столько накладных расходов, сколько требует парная работа. Таким образом, парная работа не увеличивает расходы, а переносит контроль качества с этапа после разработки на этап её выполнения.

Laforgia открыто говорит о пробеле: ни одно рецензируемое исследование напрямую не доказало, что команды могут безопасно отказаться от ревью постфактум при использовании парного программирования. Полное утверждение держится на консенсусе практиков, развивающем вывод об эквивалентности затрат.

Пять этапов перехода

В статье с редкой осторожностью рассматриваются команды, которые не готовы сразу отказаться от PR:

Оптимизация PR - маленькие (<200 строк), SLA 4 часа, автоматический стиль/lint, один обязательный аппрувер.
ship-show-ask (Вилсенах) - категоризация изменений: ship (слияние без ревью для рутины), show (немедленное слияние, ревью постфактум), ask (открытие PR и ожидание для сложных/неоднозначных задач).
Парное программирование + TBD - парная работа над production-кодом, слияния в trunk несколько раз в день, ревью после коммита для непарной работы.
Ансамблевое программирование + TBD - совместная работа всей команды, непрерывное ревью, прямые коммиты в trunk, feature flags.
Полный T*D - все три практики вместе, быстрый автоматизированный пайплайн.

Концепция Тьерри де По "non-blocking continuous code review" находится между 2 и 3 этапами: ревью происходит в основной ветке после слияния, на уровне отдельных функций, без иерархических требований (джуниоры проверяют сеньоров и наоборот), непроверенный код может попасть в production, если автоматические тесты прошли. Внутренние аудиторы одной из организаций признали такой подход более надёжным, чем традиционное соблюдение требований "по чекбоксу".

Градиент доверия

Laforgia отвергает бинарную трактовку, к которой, казалось бы, склоняет его аргументация. Доверие - это градиент:

Небольшая команда в одном офисе, ежедневно работающая в парах -> аргументы против асинхронных PR наиболее сильны.
Крупная организация со множеством команд -> межкомандные изменения всё ещё могут оправдывать легковесные PR с быстрыми SLA.
Inner-source / платформенные команды, принимающие полувнешние правки -> определённая роль привратника остаётся оправданной.
Распределённые команды с пересечением часовых поясов -> работа в парах во время пересечения, неблокирующее ревью вне его.
Распределённые команды с минимальным пересечением -> асинхронные PR могут быть наименьшим злом, но их всё равно следует агрессивно оптимизировать.

Диагноз антипаттерна сильнее всего применим к работе внутри одной команды и в одном контексте, где асинхронные блокирующие PR заменяют доверие, которое уже должно существовать.

Связи в базе знаний

i-dont-want-your-prs - Ченжаркевич атакует PR в open source со стороны мейнтейнера через призму пост-LLM эпохи; Laforgia критикует PR во внутренних командах через призму классических исследований по разработке ПО. Разные посылки, одна цель.
agent-principal-agent-problem - Кроушоу о том, как агенты разрушают сигнал о затраченных усилиях, делавший схему "ревью перед коммитом" рабочей; статья Laforgia этого не касается, но оба тезиса отлично дополняют друг друга (агенты убивают ревью как сигнал об усилиях, но этот сигнал и так был слаб согласно Bacchelli & Bird).
stacked-prs / billjings-git-not-fine - Джингс утверждает, что в git отсутствуют нужные для PR примитивы; Laforgia считает ошибочным сам рабочий процесс. Оба приходят к выводу, что "церемония вокруг PR создаёт накладные расходы".
no-silver-bullet-llms - статья Беннетта, отдельно рассматривающая недавнюю инверсию метрик DORA в условиях написания кода с помощью LLM.
cult-of-vibe-coding, clean-code-coding-agents - смежные темы о том, для чего нужно ревью в мире после появления LLM.
laycock-review-by-exception - Лейкок (2026) приводит аналогичный аргумент о переносе ревью для эпохи агентов и добавляет критерии того, какие изменения всё ещё требуют проверки человеком.

Новизна и уже известное

Сами аргументы не новы - Фаулер, Фарли, Керр, де По, Степанович, Хаммант и инициатива Minimum CD писали об этом годами. Ценность работы Laforgia в том, что это единый документ, который:

Ссылается на реальные рецензируемые исследования (а не на цепочку постов в блогах практиков).
Конкретно формулирует миф о поиске багов (<15%, 1,5 млн комментариев, 9 млн ревью).
Даёт количественную оценку стоимости ожидания (цифра в 130 000 часов).
Предлагает честный пятиэтапный переход, не делая вид, что доверие бывает только абсолютным или нулевым.
Признаёт наличие пробелов в доказательной базе (отсутствие прямых исследований, доказывающих безопасность замены PR на парную работу).

Статья служит хорошей ссылкой для ответа на вопрос "почему PR вредны для внутренней команды?", когда собеседник не готов читать четыре статьи в блогах и отчёт DORA.