Привычному pull request в его нынешней форме около 20 лет, и для инженерных команд это уже не просто ритуал, а архитектурное наследство. The New Stack пишет, что ревью кода пора переносить выше по цепочке: не после коммита, а до того, как разработчик вообще сел писать код. Для русскоязычной IT-аудитории это звучит не как красивая теория, а как вполне приземлённый вопрос о скорости релизов, цене ошибок и роли ИИ в инженерном процессе.
Суть идеи проста и от этого немного неприятна: pull request слишком поздно ловит проблемы, которые возникают не в строках кода, а раньше — в постановке задачи, интерфейсах, допущениях и неоговорённых ограничениях. Если спор о подходе начинается уже в PR, команда почти гарантированно тратит лишнее время. Разработчик написал код, прогнал тесты, собрал контекст, а затем получает замечания не о синтаксисе, а о том, что задача понята иначе, API выбран не тот, а саму логику лучше было бы строить по-другому. Такое ревью кода превращается в дорогую форму позднего согласования.
Авторы материала, Ankit Jain и Vanitha Kumar, атакуют именно эту привычную точку входа. Их тезис не в том, что PR нужно отменить, а в том, что его больше недостаточно считать главным механизмом качества. За последние годы сам процесс разработки успел радикально ускориться: команды чаще выкатывают изменения небольшими порциями, CI/CD сжимает цикл обратной связи, а генеративные инструменты снижают порог на производство кода. Когда код становится дешевле и появляется быстрее, бутылочное горлышко смещается. Им оказывается уже не написание функций и не оформление коммитов, а проверка того, что команда вообще движется в правильную сторону.
Отсюда и логика «сдвига вверх по потоку»: обсуждать надо не только код, но и намерение. До начала работы команде полезнее проверить контракт между сервисами, ожидаемое поведение, границы ответственности, риски безопасности, влияние на поддержку и наблюдаемость. Для разработчиков это означает более жёсткую дисциплину вокруг RFC, design docs, коротких архитектурных заметок и формализованных критериев приёмки. Для тимлидов и продактов — необходимость приходить в разработку не с абстрактным «сделайте удобно», а с набором решений, которые можно критиковать до появления первой строчки. В этой точке ИИ тоже меняет игру: если агент или ассистент умеет быстро генерировать код, то ценность человека сдвигается от механического review к проверке рамки, в которой этот код будет создан.
Для бизнеса в этом подходе нет романтики, зато есть экономика. Поздняя правка в PR почти всегда дороже раннего разворота на уровне замысла. Она съедает время разработчика, рецензента, QA, а иногда ещё и смежных команд, которые уже начали интеграцию. Плюс возникает хорошо знакомый эффект ложного прогресса: в трекере задача выглядит почти готовой, ветка живёт, тесты проходят, а по факту команда всё ещё спорит о базовой реализации. Если перенести часть проверки до кодинга, уменьшается число косметических итераций и снижается риск, что в мастер попадёт «технически рабочее, но концептуально спорное» решение. Для IT-директоров это особенно актуально там, где разработка упирается не в недостаток рук, а в перегруженные согласования и бесконечные циклы замечаний.
Есть и неприятная сторона. Идея «ревью до кода» легко превращается в бюрократию, если команда начнёт требовать многостраничные документы на каждую кнопку и каждую миграцию. Поэтому вопрос не в том, чтобы заменить один обряд другим, а в том, что именно выносить наверх. Если изменение маленькое и обратимое, тяжёлое предварительное согласование только замедлит работу. Но чем дороже ошибка, чем больше зависимостей и чем выше вероятность, что ИИ или инженер быстро произведут большой объём изменений, тем полезнее ранний фильтр. Иначе компании рискуют автоматизировать не качество, а скорость доставки спорных решений в репозиторий.
Для российской и русскоязычной индустрии здесь особенно интересен не сам спор о pull request, а изменение статуса review как такового. Долгое время считалось, что зрелая инженерная культура начинается там, где никто не пушит без проверки коллегой. Теперь планка смещается: зрелой будет выглядеть команда, которая умеет проверять не только код, но и намерение до кода. На практике это может означать обязательные мини-RFC для рискованных задач, шаблоны вопросов перед стартом разработки, автоматическую проверку требований к безопасности и наблюдаемости, а также более тесную связку между product discovery и инженерным дизайном. И да, это может быть менее героично, чем ночной разбор 400 строк в PR, но заметно полезнее для тех, кто отвечает за сроки и стабильность.
Главный вопрос теперь не в том, исчезнет ли pull request, а в том, какую долю инженерного решения команда готова проверять ещё до коммита. Чем быстрее ИИ и автоматизация удешевляют производство кода, тем слабее выглядит модель, в которой ревью кода начинается только после его появления. Похоже, следующая битва за качество пойдёт не в интерфейсе Git-хостинга, а на один шаг раньше.
