Классическое ревью кода, похоже, больше не выглядит священной коровой инженерной культуры. В колонке Ankit Jain для The New Stack автор прямо ставит вопрос о том, как «убить» привычное ревью кода в его нынешнем виде и чем заменить этот ритуал в эпоху генеративной разработки. Для русскоязычных команд сигнал неприятный, но полезный: если код пишет уже не только человек, то и проверять его по старым правилам становится все труднее и дороже.
Материал, как пишет The New Stack, продолжает предыдущую дискуссию автора под заголовком «How long before we stop reading the code?». Логика связки довольно прозрачная: если индустрия движется к модели, в которой люди все реже читают код построчно, то следующим под удар попадает именно ревью кода как основной способ контроля качества. Не в том смысле, что команды завтра отключат pull request и разойдутся по домам, а в том, что сама ценность ручной проверки диффов начинает проседать.
Тезис неудобный, но понятный. Традиционная схема появилась в мире, где код в основном писали люди, объем изменений был ограничен скоростью команды, а senior-разработчик еще мог открыть pull request и действительно понять, что там происходит. При AI-assisted и тем более agentic-разработке количество кода растет быстрее, патчи становятся длиннее, а разработчик-ревьюер все чаще занимается не содержательной экспертизой, а формальной отметкой в интерфейсе. В такой конфигурации ревью легко превращается в дорогое упражнение на внимательность с сомнительной гарантией качества.
Отсюда и главный разворот в обсуждении: фокус смещается с чтения кода на проверку поведения системы. Если раньше вопрос звучал как «посмотрел ли человек на этот diff», то теперь важнее другое: есть ли у изменения надежные тесты, проходит ли оно автоматические проверки, не ломает ли контракты, не меняет ли критичные свойства производительности, безопасности и наблюдаемости. Иными словами, инженерная дисциплина начинает переезжать из комментариев под pull request в пайплайны верификации. Для части команд это уже не теория, а вполне бытовая реальность.
Для разработчиков здесь мало романтики, зато много практики. Ручное ревью кода десятилетиями считалось не только способом поиска багов, но и механизмом обмена знаниями, выравнивания стиля, онбординга и внутренней политики качества. Проблема в том, что один процесс тащил на себе слишком много функций сразу. Если теперь его значение как фильтра ошибок снижается, компаниям придется разносить эти задачи по другим инструментам: знания фиксировать в документации и архитектурных решениях, стиль отдавать линтерам и форматтерам, безопасность и совместимость закрывать автоматическими политиками, а корректность изменений доказывать тестами и телеметрией, а не надеждой на то, что кто-то внимательно дочитает до конца очередной diff на тысячу строк.
Для бизнеса вывод еще жестче. Если команда по привычке измеряет качество количеством обязательных апрувов, она может создавать иллюзию контроля там, где нужен совсем другой контур. Чем активнее разработчики используют AI-инструменты, тем менее устойчивой становится модель, где скорость генерации кода растет, а единственный предохранитель по-прежнему сидит в очереди на review. Это плохая экономика процесса: машина ускоряет выпуск изменений, а человек остается узким горлышком. В результате растет не качество, а latency принятия решений, раздражение команды и соблазн превращать ревью в формальность.
При этом разговор вовсе не сводится к лозунгу «люди больше не нужны». Скорее наоборот: человеческая экспертиза дорожает, и тратить ее предлагают не на механическое чтение всего подряд, а на более дорогие задачи. Например, на архитектурные развилки, рискованные изменения в доменной логике, спорные продуктовые решения, вопросы безопасности и соответствия требованиям. То есть инженер должен меньше искать пропущенную запятую в generated-коде и больше отвечать за то, какие инварианты система обязана сохранять, какие проверки нельзя обходить и где автоматике пока рано доверять без оглядки.
Для российских и русскоязычных команд это особенно актуально, потому что многие находятся в переходной фазе. AI-помощники уже используются в ежедневной разработке, но процессы часто остаются из мира 2018 года: длинные PR, ручные согласования, надежда на внимательного тимлида и культ «обязательного апрува». На короткой дистанции такая модель еще работает. На длинной она начинает конфликтовать с самим темпом AI-разработки. Если компания не пересоберет контроль качества вокруг тестирования, CI/CD, статического анализа, policy-as-code и наблюдаемости, то ревьюеры будут просто тонуть в объеме изменений.
Именно поэтому спор вокруг ревью кода выглядит не как очередная провокация ради трафика, а как вполне рабочий инженерный вопрос. Что в вашей команде на самом деле гарантирует качество: внимательный человек в интерфейсе pull request или система проверок, которая может доказать, что изменение безопасно? Чем быстрее AI входит в продакшн-разработку, тем меньше шансов, что старый ритуал в неизменном виде переживет следующий цикл инструментальной эволюции.