Не позволяй Claude проверять свой код: почему ревью чужой моделью надёжнее самопроверки

Кросс-провайдерное ревью кода ИИ спасло инженера от досадной ошибки. Он запустил несколько параллельных агентов Claude, получил папку из 10 аккуратно перелинкованных документов и едва не одобрил pull request, в котором 30 из 95 относительных ссылок вели на несуществующие файлы. Промах поймал не человек, а автоматический ревьюер на другой модели. Об этом рассказывает Рубен Брукс в статье «Не позволяй Claude проверять собственную домашку», вышедшей 15 июля 2026 года в Towards Data Science. Вывод у него простой и неприятный: модель не годится в судьи собственной работы, спасает связка из двух разных лабораторий.

Что именно произошло

Несколько сессий Claude сгенерировали Бруксу стратегию сайд-проекта: десяток документов, перекрёстные ссылки между ними, всё «читается хорошо». По виду готовый к слиянию PR, который человек одобрил бы не глядя. Но настроенный автоматический ревьюер прогнал каждую ссылку на проверку существования и нашёл то, что глаз пропускает.

Ссылки вели на файлы, которых нет. Вместо market-analysis.md в тексте стояло ./market.md, вместо business-model.md стояло ./monetization.md. Часть файлов модель выдумала целиком. Итоговый аудит: 30 из 95 относительных ссылок битые. Claude, к своей чести, признал промах прямо по ходу сессии.

«Автоматическое ревью поймало настоящий баг: авторы документов использовали угаданные имена файлов для перекрёстных ссылок. Валидная находка, исправлю».

Главный приём ревьюера в том, что он резолвил каждую ссылку, а не оценивал на глазок, звучит ли имя файла правдоподобно. Разница принципиальная: имя ./market.md выглядит нормально. Оно и есть проблема.

Почему галлюцинация всегда выглядит убедительно

Брукс формулирует это одной фразой: «Уверенно и неправильно читается ровно так же, как уверенно и правильно». Модель генерирует самое правдоподобное продолжение, и её собственная выдумка по определению максимально правдоподобна для неё самой. Битая ссылка не выделяется на фоне рабочих, ведь её сгенерировала та же логика, что и корректные.

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

Это не догадка автора. Исследование Panickssery и соавторов (NeurIPS 2024) показало, что LLM-оценщики узнают собственные генерации и систематически ставят им более высокие оценки: чем лучше модель распознаёт свой вывод, тем щедрее его судит. Последующие работы связывают этот self-preference bias с «привычностью». ИИ-судья выше оценивает текст, который читается предсказуемо, а нет ничего предсказуемее текста, который модель только что написала сама.

Сломался не код: сломался ревью

Отдельный тезис Брукса важнее, чем кажется. Галлюцинации остаются величиной постоянной. Изменился объём. Один инженер держит несколько агентных сессий одновременно, и каждая выдаёт диф в тысячу строк «за время, пока наливаешь кофе». Писать код стало быстро и почти бесплатно. Узким местом стал честный ревью.

По мере приближения дедлайна команды колеблются между двумя провальными режимами. Можно одобрять всё, что выдал агент, не читая, и тогда в прод уезжают битые ссылки, фантомные параметры и тонкие ошибки в граничных случаях. Это халатность. А можно вычитывать вручную каждую строку, но быстрые агенты успевают наработать больше, чем человек физически способен прочитать. Это расточительство.

Логика напрашивается: если узкое место конвейера в проверке, автоматизировать нужно именно её. А раз самопроверка не работает, ревьюер должен быть из другой лаборатории.

Кросс-провайдерное ревью кода ИИ: Codex ревьюит Claude

Сетап Брукса: агент Codex от OpenAI запущен в GitHub Actions и ревьюит каждый PR до того, как код увидит человек. Автор пишет на Claude от Anthropic, а проверяет чужая модель. В этом весь смысл кросс-провайдерного подхода.

Разные провайдеры обучаются на разных данных, по разным рецептам и с разными петлями обратной связи. Поэтому у них разные слепые зоны. Ни одна модель не устраняет ошибки полностью, но характер ошибки восходит к тому, как модель обучали. То, что для Claude «естественное продолжение», для Codex выглядит подозрительным. Второе мнение работает потому, что оно от чужой головы.

С чего начать настройку ревьюера в GitHub Actions

Общая схема пайплайна для тех, кто хочет повторить подход:

1. Триггер на pull request. Workflow запускается автоматически при открытии и обновлении PR, до ручного ревью.
2. Модель-ревьюер из другой лаборатории. Если код пишет один провайдер, для проверки берите другого. Это ядро всего подхода.
3. Детерминированные проверки поверх ИИ. Не полагайтесь только на «мнение» модели. Резолв ссылок, проверка существования параметров и функций, линтеры и тесты дают якорь реальности, который ловит убедительно звучащую, но несуществующую выдумку.
4. Комментарии-ревью прямо в PR. Находки остаются в интерфейсе, где их видит человек, с указанием конкретных строк.
5. Память и подотчётность в цикле. Ревьюер не должен между итерациями забывать контекст и одобрять то, что раньше сам же зарубил.

Роль человека при этом не исчезает, а смещается на важное. Резолв ссылок и проверку параметров забирает автоматика, инженер концентрируется на архитектуре, безопасности и соответствии кода исходной задаче.

Приватность диффов: о чём стоит подумать заранее

Есть нюанс, который в вопросах безопасности пропускать нельзя. Кросс-провайдерное ревью означает, что ваш код и диффы уходят стороннему ИИ-провайдеру. Для приватных репозиториев с секретами, ключами и внутренней логикой это фактор риска: разберитесь, что именно уезжает наружу, и при необходимости используйте self-hosted runner'ы, чтобы держать чувствительные данные под контролем. Если ваша команда работает из России или СНГ и вопрос стабильного и приватного доступа к ИИ-инструментам стоит остро, Sigma помогает с безопасным подключением.

Сколько это стоит и зачем

Экономика тут очевидная. Автоматический прогон ревьюера на PR дешевле цены одного бага в проде и несопоставимо дешевле часов инженера, потраченных на ручную вычитку тысячестрочных дифов, которые агенты плодят быстрее, чем человек читает. Автоматизируя узкое место, вы возвращаете скорость, которую дала генерация кода, но которую съедала проверка.

Частые вопросы

Почему нельзя просто попросить Claude перепроверить свой код?

Та же модель в той же сессии прогонит текст через те же веса и те же слепые зоны. Галлюцинация, попавшая в диф, для неё выглядит правдоподобной, ведь она сама её сгенерировала. Плюс подтверждённый self-preference bias: модели выше оценивают собственный вывод.

Обязательно ли брать именно Codex и Claude?

Нет. Принцип кросс-провайдерного ревью в том, что автор и ревьюер из разных лабораторий с разными данными обучения и разными слепыми зонами. Конкретная пара моделей может быть любой.

Достаточно ли одного ИИ-ревьюера, чтобы вообще не читать код?

Нет. Ревьюер снимает рутину: резолв ссылок, проверку параметров и граничных случаев. Архитектуру, безопасность и соответствие задаче по-прежнему держит человек.

Что важнее, мнение модели или автоматические проверки?

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

Источники

Towards Data Science, Ruben Broekx о кросс-провайдерном ревью кода ИИ и битых ссылках в генерациях Claude