Ревью ИИ-кода

Аргумент Томаса Депьера (thomas-depierre-blog) против LLM-ассистентов для написания кода, полностью построенный на эмпирической литературе по код-ревью. Он скептически относится к ИИ, но принципиально не по привычным причинам (интеллектуальная собственность, экология, "всё это чушь") - его возражение в том, что с учётом имеющихся данных совершенно непонятно, как эти инструменты помогают писать код лучше или быстрее, а сторонники технологии никогда не обращаются к доказательной базе. Написано примерно за год до публикации (он использует актуальный на тот момент термин "Coding Assistants").

Возражение со стажёром и почему оно не работает

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

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

Посчитайте сами: каждые 400 LOC от LLM требуют примерно один час работы senior-разработчика, а таких часов у инженера наберётся от силы 10-40 в неделю - и эти слоты предельной концентрации конкурируют со встречами, проектированием и инцидентами. В лучшем случае разработчик успевает написать, проверить и закоммитить несколько тысяч LOC в день; в реальности - меньше 1k LOC в день, включая шаблонный код, тесты, миграции и конфигурацию. Один только файл с юнит-тестами может превышать 400 LOC. Так что совет "просто проверяйте" задаёт жёсткий потолок возможной производительности при разработке с ИИ - узким местом оказывается ревью, а не генерация. Это и есть code-review-throughput-limits.

Дальше - хуже: ревью кода ИИ может быть сложнее

Поверх этого потолка накладываются ещё две проблемы:

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

Он аккуратно очерчивает границы тезиса: речь идёт исключительно о затратах на ревью ради поиска дефектов, а не о стоимости их исправления, и качество самой модели тут роли не играет. Даже очень хорошая модель упрётся в тот же самый потолок ревью.

Что могло бы изменить его позицию

Он формулирует условия фальсифицируемости своей позиции, ради чего текст и написан:

Эмпирические исследования того, как люди находят дефекты в сгенерированном LLM коде - насколько качественно, быстро и в каком объёме в день, воспроизведённые в масштабе и в разных контекстах. (Текущие данные склоняются к тому, что люди справляются с этим плохо, что согласуется с тем, как модели обучают выглядеть правдоподобно.)
Доказательство того, что ревью кода от LLM качественно отличается от ревью человеческого кода, из-за чего накопленные данные к нему неприменимы. (Предварительные данные показывают, что оно действительно отличается, но в сторону большей сложности, что лишь усиливает его аргумент, а не ослабляет.)

Место в общей картине

Это один из наиболее сильных материалов в инженерно-ремесленном блоке карты anti-llm-discourse, поскольку он опирается на факты и фальсифицируем, а не просто риторичен. Это количественный фундамент для нескольких соседних страниц: agent-principal-agent-problem (Крошоу о разрушении сигнала о трудозатратах при ревью), code-review-knowledge-transfer (эмпирический вывод о том, что ценность ревью заключается не столько в отлове багов), stop-using-pull-requests (критика ревью на основе данных от Лафорджиа) и no-silver-bullet-llms (данные Беннетта о нестабильности в масштабах метрик DORA).

Материал также напрямую полемизирует с control-the-ideas-not-the-code: antirez делает прямо противоположный вывод - перестать построчно вычитывать код от LLM - исходя из того же исходного наблюдения, что построчное ревью не масштабируется. Ответ Депьера не высказан прямо, но очевиден: если ревью - единственный предлагаемый ответ на вопрос о корректности кода LLM, а ревью не масштабируется, то отказ от него не решает проблему, а просто отбрасывает её. Оба согласны, что построчное ревью несостоятельно, но расходятся в том, может ли что-то прийти ему на смену.

short-leash-ai-method - это четвёртый угол дискуссии, который просто отвергает исходную предпосылку: нужно читать каждый предлагаемый diff до применения, на уровне подтверждения отдельных действий инструмента, а не на этапе PR, и без колебаний отклонять правки. Этот подход не пытается угнаться за масштабом и принимает замедление как неизбежную плату. В контексте Депьера это позиция, согласно которой ревью необходимо сохранить, поскольку других вариантов нет; в сравнении с control-the-ideas-not-the-code это прямо противоположный вывод из тех же данных.

Базовым ориентиром для всех четырёх позиций служит google-code-review-looking-for - регламент Google о том, на что обращает внимание ревьюер. Его полезно читать параллельно, так как большая часть чек-листа (архитектура, сложность, именование, комментарии, единообразие) вообще не связана с охотой за багами - к такому же выводу со стороны исследований приходит code-review-knowledge-transfer.

Дэн Луу предлагает третью точку зрения (testing-heavy-no-review-workflow, из danluu-ai-coding-testing): замена ревью существует - это масштабное рандомизированное тестирование и фаззинг, и именно они должны гарантировать надёжность. Он согласен, что ревью упирается в потолок ~400 LOC/час и не способно фильтровать вывод агентов, но если Депьер видит в этом барьер для написания кода с помощью LLM, то Луу - доказательство того, что ревью изначально не подходило для этой задачи. Ловушка, которую признаёт и сам Луу (и на которую наверняка указал бы Депьер), заключается в предварительном условии: этот метод работает только при наличии методологии тестирования, заслуживающей полного доверия, чего большинство организаций так и не выстроило.

how-do-we-stop-vibe-coding принимает вывод о лимитах пропускной способности как данность и ставит вопрос иначе. Если ревью не масштабируется, а отказ от него ставит крест на корректности, Клос задаётся вопросом: что потребуется для аудита изменений, внесённых агентом в кодовую базу, без чтения самого кода? Речь идёт о структурированной модели системы, относительно которой изменения выглядят как diff, и детерминированном слое, сообщающем о расхождениях между кодом и моделью. Другой ответ - перепоручить ревью другой модели; в cross-model-code-review собраны результаты научных замеров на этот счёт, а swr-bench-code-review оценивает качество однопроходного LLM-ревью реальных PR'ов примерно в 20% F1.

В cacm-code-review-ai-coding описано, как практики переосмысливают ревью ИИ-кода: вместо финального барьера оно превращается в непрерывный контроль рисков, нацеленный на проверку допущений, границ доверия и доказательств корректности.

Возмущение автора

В финале тон сменяется с аналитического на раздражённый: автора задевает, когда люди, даже не попытавшиеся вникнуть в суть вопроса, называют его сумасшедшим. Он уже видел, как в индустрии личные байки побеждали доказательный подход - с TDD, системами типов, разделением команд разработки и тестирования, CI/CD, DevOps, - и призывает перевести дискуссию в плоскость эргономики и эмпирических фактов вместо аргументов "у меня всё работает". "Хотелось бы, чтобы наша индустрия перестала заниматься кровопусканием".