AI code review: что он стабильно пропускает

Три месяца назад я начал прогонять все pull request через code review с помощью AI прежде, чем смотреть самому.

Не потому что доверяю. Чтобы понять, чему доверять.

Я вёл список: что он поймал, что пропустил, что я нашёл после него. Список получился интереснее, чем я ожидал. Не «AI не понимает контекст» — это банальность. Интереснее другое: он слеп именно к вещам, которые выглядят как просто технический код, но архитектурно что-то значат.

Как выглядит процесс — без романтики

Я использую Claude Code и прошу делать review перед тем, как открываю diff сам. Стандартный промпт: посмотри на изменения, отметь потенциальные проблемы — синтаксические, логические, безопасность.

Это не заменяет мой review. Это первый проход, который отфильтровывает очевидное.

Работает на PHP/Bitrix-проектах и Next.js-фронте. Три месяца, десятки PR, реальные задачи от мелких правок до рефакторинга компонентов.

Что AI review ловит хорошо

Честный список:

Незакрытые null-checks — стабильно, почти без пропусков
Очевидные опечатки в условиях: if ($a = $b) вместо if ($a == $b)
Отсутствие обработки исключений там, где она явно нужна
Нарушение явного codestyle (если дать ему контекст)
Использование deprecated-методов, когда это прямо видно из кода

Это полезно. Это освобождает меня от первого механического прохода. Но это и весь список. Дальше начинаются слепые зоны.

Слепая зона №1 — локально верно, системно неправильно

Самая коварная категория ошибок.

Разработчик правит метод кэширования в Bitrix. Логика изменения выглядит корректной: был BXClearCache, стал более точный тег. AI проверяет — всё нормально. Синтаксис чистый, логика без явных дыр.

Через три дня после деплоя начинаются жалобы на то, что цены на сайте «зависли» после изменения в каталоге. Причина: Bitrix composite cache работает на уровне всей страницы, и точечная инвалидация тега не трогает composite-кэш. Страница продолжает отдаваться из составного кэша с устаревшими данными.

AI не видит этого. Не потому что плохой. Потому что у него нет контекста о том, как Bitrix composite cache связан с конкретным iblock. Он видит метод. Он не видит инфраструктуру, в которую этот метод встроен.

Code review с помощью AI здесь дал ложную уверенность. Это опаснее, чем вообще без ревью: появляется ощущение, что кто-то проверил.

Правило для этой зоны простое: любая правка, касающаяся кэша, инвалидации или очереди — это human-only territory. AI сюда не допускается.

Слепая зона №2 — бизнес-логика, упакованная в технический diff

Изменение выглядит как рефакторинг. Переименовали переменную, вынесли условие в отдельный метод, упростили цепочку. Технически чисто. AI одобряет.

На деле внутри этого рефакторинга спрятано изменение поведения: условие чуть поменялось, и теперь оно срабатывает для случая, который раньше обрабатывался иначе. Конкретно: заказы с нулевой ценой (подарки, тестовые) попадали в один статус, после рефакторинга начали попадать в другой. AI на это не смотрит, потому что технически метод стал чище.

Это не ошибка AI. Это архитектурная слепота: инструмент проверяет, правильно ли написано. Он не проверяет, правильно ли поведение.

Здесь помогает только один приём: при ревью таких PR явно спрашивать «изменилось ли поведение этой ветки хоть для одного edge case?» Это вопрос, который нужно задавать самому, а не делегировать.

Слепая зона №3 — технический долг второго порядка

Код работает. Тесты проходят. AI не видит проблем.

Но в коде появился паттерн, который через год убьёт команду на масштабировании. Hard-coded ID окружения в конфиге, который сейчас кажется локальным решением. Дублирование логики между двумя модулями, каждый из которых «отвечает за своё». Зависимость от порядка инициализации модулей, которую никто не задокументировал.

AI не знает roadmap. Он не знает, что через полгода этот модуль будет переиспользован в другом контексте. Он видит конкретный код в конкретный момент и не может оценить его в динамике.

Долг второго порядка — это долг, который не виден в текущем diff'е. Видеть его можно только зная, куда движется система. Это исключительно человеческая работа.

Я ловлю такие паттерны, задавая себе вопрос: «если через год кто-то будет развивать этот код, что его убьёт?» AI этот вопрос не задаёт.

Правило, которое я вывел за три месяца

AI делает первый проход по тому, что видит: синтаксис, паттерны, очевидные ошибки.

Я делаю второй проход по тому, что это изменение делает с системой.

Первый вопрос — «правильно ли написано?» Второй — «правильно ли ведёт себя в той системе, которую я строю?» Это разные вопросы, и AI отвечает только на первый.

Конкретно: если AI code review ничего не нашёл — это не значит, что PR чистый. Это значит, что технических очевидностей нет. Мой review начинается именно здесь.

Три категории, куда я смотрю сразу после AI-прохода:

Всё, что касается кэша, очередей, composite — смотрю сам без исключений.
Любой рефакторинг с изменением условий — проверяю edge cases руками.
Любая новая dependency или hard-coded значение — задаю вопрос «почему здесь, а не в конфиге?»

Инструмент полезен. Ровно настолько, насколько понятно, что он не видит.

Я писал раньше про то, почему Claude пишет тесты, но не выбирает архитектуру — это то же разграничение, но для ревью. И для тех, кому интересно посмотреть с другой стороны: баг, который написал Claude и не поймал на review.