Возможно, нам не стоит ревьюить весь этот код

Рейчел Лейкок, коллега Мартина Фаулера по Thoughtworks, написала эту заметку для своей колонки "Rachel's ramblings" на martinfowler.com в ответ Брайану Хауку из DX. Они разошлись во мнениях на панели конференции Code Remix, организованной Moderne, после чего Хаук опубликовал статью с заголовком "What are code reviews even for?". Её подзаголовок чётко формулирует позицию: возможно, ИИ вовсе не сломал code review, а команды всё это время решали с помощью ревью не те проблемы.

В чём они сходятся

Проблема объёма кода - их общая точка зрения. Цифры Хаука, которые она приводит: в Meta количество строк кода на один diff, влитый человеком, за год выросло на 106%, а собственные данные DX показывают рост медианного размера pull request'а на 64%. Оба также согласны с тем, что ревью нужно не только для поиска багов. Команды используют его для передачи знаний, обучения джуниоров, формирования коллективной ответственности и распространения архитектурного контекста, а автоматизация ревью грозит потерей всего этого. Расходятся они на её вопросе: зачем ждать этапа ревью, чтобы делать хоть что-то из этого?

Сдвинуть оценку влево

Принцип, который она переняла из ранней практики Thoughtworks, - сокращать петли обратной связи: сохранять ценный фидбек, но приближать его к моменту принятия решения. Она разбирает задачи ревью по очереди. Поиск альтернатив должен происходить до реализации одной из них. Передача знаний работает лучше, когда вы работаете в паре с человеком в процессе его рассуждений, а не читаете его готовое решение. Джуниоры учатся мышлению опытных инженеров, работая с ними бок о бок - в парах или на дизайн-сессиях у доски ещё до того, как кто-то напишет код или даст инструкцию агенту. Коллективная ответственность рождается из совместной разработки и эксплуатации софта, а не из PR с анонсом того, что кто-то уже написал. Согласованность архитектуры возникает из совместного проектирования с последующей фиксацией важных ограничений в виде fitness functions. Форматирование, линтинг, известные проблемы безопасности и всё, что тестируется детерминированно, должно быть автоматизировано; никто не должен спорить о пробелах в 2026 году. Агенты могут участвовать в этих ранних циклах, подвергая сомнению архитектурные решения и проверяя гипотезы, но настоящее мышление она оставляет за опытными людьми.

Ревью как исключение

Она оставляет ревью человеком для тех случаев, где экспертная оценка окупается: фундаментальное архитектурное изменение (возможно, проверяемое всей командой, которая его проектировала), изменение, затрагивающее чувствительный контур безопасности, огромный радиус поражения (blast radius), незнакомая часть критической системы или просто ситуация, когда команда не уверена в результате. Что она отвергает, так это требование, чтобы человек просматривал каждое изменение только потому, что команды привыкли использовать эту церемонию для создания уверенности. Агент, генерирующий в десять раз больше кода, который встаёт в очередь к старшему инженеру, даёт бэклог и новое бутылочное горлышко, а не организацию, работающую в десять раз быстрее.

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

Единственное опасение, которое она разделяет с Хауком, - это когнитивный долг и долг намерений (intent debt): софт разрастается, а его владельцы всё хуже понимают, почему он работает именно так. Она признаёт эту проблему, но сомневается, что обязательные PR способны от неё защитить, указывая взамен на совместное проектирование, парную работу, чёткие границы, исполняемую архитектуру и общую ответственность за эксплуатацию. Её итоговый вывод: инженеры должны понимать системы, а не diff'ы. Ревью, пишет она, было перегружено задачами контроля качества, проверки безопасности, архитектурного надзора, менторства, передачи знаний и модели владения, и это работало лишь до тех пор, пока люди писали код медленно.

Контекст идеи

Этот аргумент приходит к тем же выводам, к которым с исследовательской стороны приходят code-review-knowledge-transfer и stop-using-pull-requests, а её список исключений близок к категории "Ask" в ship-show-ask. Предлагаемые ею механизмы доставки - это pair-programming и trunk-based-development. Она согласна с reviewing-ai-code и code-review-throughput-limits в том, что вычитка каждой строчки агентского кода не масштабируется, но, в отличие от Депьера, видит в этом повод перенести ревью на другой этап, а не потолок для применения агентов. Беспокойство по поводу intent debt - это тот же компромисс, который описывает cognitive-debt.

Её неприятие ИИ в роли ревьюера резче всего контрастирует с cross-model-code-review, где проверка одной модели другой лежит в основе всей схемы. Исследования там замеряют, находит ли такой ревьюер ошибки; Лейкок же задаётся вопросом, нужен ли вообще этот барьер для большинства изменений. Практики, которых цитирует cacm-code-review-ai-coding, в основном придерживаются противоположной точки зрения: ревью становится только важнее, когда код пишут агенты.

Ссылки

• agent-principal-agent-problem - почему сигнал о затраченных усилиях при ревью сломался, когда diff'ы стали писать агенты
• control-the-ideas-not-the-code - параллельный переход antirez от вычитки строк к удержанию дизайна
• cacm-code-review-ai-coding - противоположная позиция практиков из материалов CACM, сентябрь 2026 года