ИИ в код-ревью: что ловил и что пропускал ревьюер GoRunWithAI

Серия «Разработка с ИИ: полный цикл», часть 4. Платформа GoRunWithAI.

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

Принцип: машина отвечает за полноту, человек — за смысл

Что проверял ИИ-ревьюер	Что проверял я
Типовые баги: null/пустые коллекции, незакрытые ресурсы	Соответствие бизнес-цели задачи
Секреты в коде, небезопасная обработка ввода	Архитектурная уместность решения
Соответствие правилам проекта	Компромиссы и их цена
Покрытие изменений тестами	Простота: можно ли решить проще

Реальные находки ИИ-ревьюера в проекте

Находка 1. Молчаливое глотание исключений. В коде импорта контента ревьюер указал на except Exception: continue — конструкцию, из-за которой обновления статей проваливались без единого сообщения. В проде это аукнулось инцидентом из статьи 3. Вывод ревьюера стал правилом проекта: «тихие except'ы — только с явным обоснованием и логированием».

Находка 2. Env-зависимые тесты. Два теста кросспостинга падали без токена Telegram в окружении. Ревьюер пометил: «тест зависит от окружения, а не от кода». Исправление — явная установка токена в тестах, а не молчаливое ожидание .env.

Находка 3. Конфиг CI не того формата. Файл .gitverse-ci.yml был написан в GitLab-синтаксисе, хотя GitVerse исполняет только .gitverse/workflows/*.yaml в синтаксисе Actions. Ревьюер сопоставил конфиг с документацией платформы — то, что человек при беглом взгляде принял бы «на веру».

Находка 4. Ленивая загрузка в async-контексте. Обновление тегов в импорте падало с MissingGreenlet при ленивой загрузке связи. Ревьюер предложил selectinload — и тест, который это зафиксировал. Классический баг, который без теста «жил» бы до первого редеплоя.

Что ИИ-ревьюер пропускал систематически

Честно о слепых зонах — они у модели стабильные:

Инфраструктурные эффекты. Ни один ревьюер не увидел, что macOS-архиватор добавит AppleDouble-файлы в перенос и сломает миграции. Модель ревьюит код, а не среду доставки.
Сетевую реальность. Что Telegram окажется недоступен с IP сервера, а «казахстанский» прокси выйдет в сеть с московского адреса — ревьюер кода в принципе не мог знать (это кейс статьи 6).
Смысловые компромиссы. «Правильно ли мы вообще решаем эту задачу» — осталось за человеком. И это нормально: так задумано.

Как выглядел контур качества в проекте

Уровень 1. Локально, до коммита. Агент перед сдачей задачи сам прогонял свои изменения через проверку по правилам проекта и чинил найденное.

Уровень 2. Автоматическое ревью диффа. Отдельный прогон ревью по каждому коммиту: баги, секреты, нарушения соглашений, отсутствующие тесты. Находки — в список, с разбором «правда/шум».

Уровень 3. Человек. Я ревьюил дифф как код толкового джуна: логика — вся, стиль — выборочно. ИИ-слой снимал рутину, человеческий — принимал решения.

Уровень 4. Тесты в CI. 84 теста с порогом покрытия 70% — финальная сетка (подробно в статье 5).

Правило зрелой команды прижилось и в одиночку: каждый повторяющийся тип замечания уезжает из человека в правила ИИ-ревьюера или в линтер. Люди не должны делать машинную работу — даже когда человек один.

Ложные срабатывания: как не утонуть в шуме

Главная причина, по которой ревьюеров отключают, — шум. В проекте он управлялся так:

Калибровка. Первые находки размечались «полезно/неполезно»; правила ревью правились по обратной связи.
Пороги. Блокирующими были только критические находки (секреты, потеря данных, сломанные тесты). Стилистика — рекомендациями.
Бюджет. Больше 5–7 замечаний за прогон не читаются — ограничивал топ-N по важности.

Качество как система, а не этап

ИИ позволил собрать то, о чём давно говорит DevOps, но теперь дёшево:

соглашения как код — правила проекта исполняются ревьюером и линтерами, а не хранятся в вики, которую никто не открывает;
документация из диффа — агент обновлял описания и планы в том же коммите, где менялось поведение;
гигиена репозитория — периодический прогон «найди мёртвый код, рассинхрон документации» по расписанию.

Метрики этапа

Число дефектов, дошедших до прода — в проекте: два инфраструктурных инцидента (статьи 3 и 6) и ноль багов бизнес-логики в проде на момент запуска.
Precision ревьюера — доля находок, признанных полезными: субъективно выше 60% после калибровки.
Время ревью диффа — минуты, а не «отложу на завтра»: в одиночной разработке это и есть главный выигрыш.

Практический минимум для старта

Введите правило: перед сдачей задачи автор (человек или агент) прогоняет дифф через ИИ-проверку сам.
Размечайте находки «полезно/шум» первые две недели и правьте правила ревью.
Заведите чек-лист ревью ИИ-кода: краевые случаи, обработка ошибок, секреты, новые зависимости, соответствие критериям приёмки.
Каждый повторяющийся комментарий превращайте в правило.

💬 Обсудим? Пробовали ИИ-ревьюера: на каком этапе отключили — или наоборот, не представляете без него работу? Что он у вас пропускает систематически? Пишите в комментариях или в [Telegram-канале GoRunWithAI]. Наш ИИ-ревьюер обозревает каждый коммит платформы — и его находки попадают в открытый дашборд.

Следующая статья: «Часть 5. Тестирование: 84 теста, поймавшие реальные баги».