Вы доверяете ИИ проверять ваш код? Зря
За последние полгода я накопил достаточно данных, чтобы утверждать: автоматический code review на базе LLM — это фасад, за которым прячутся критические уязвимости. Мы привыкли думать, что нейросеть, которая написала код, сможет его и проверить. Но это глубокое заблуждение. ИИ не просто ошибается — он систематически пропускает целые классы багов, создавая иллюзию безопасности.
По данным внутреннего бенчмарка METR (июнь 2026 года), даже самые продвинутые модели — Claude 4 Opus, GPT-5 — пропускают до 38% критических уязвимостей в коде на Python и 52% в C++. Цифры, от которых у любого тимлида должны зачесаться руки.
Слепые пятна: что ИИ гарантированно не видит
Первое и самое страшное — архитектурные ошибки. Нейросеть оценивает код как локальный текст, не понимая контекста большой системы. Она не заметит, что ваш модуль нарушает принципы SOLID, создаёт циклические зависимости или дублирует логику в пяти местах. Второе — логические ошибки в многопоточности: состояния гонки, deadlocks, неявные предположения о порядке выполнения. ИИ не способен смоделировать все возможные interleaving потоков. Третье — бизнес-логика. Модель не знает вашего домена: она не поймёт, что поле «дата рождения» вдруг стало обязательным, а старая проверка на возраст осталась.
Проблема усугубляется тем, что ИИ создаёт ложное чувство безопасности — явление, описанное в статье «Неосознанный вайб-кодинг: когда слепая вера в ИИ-генерацию кода работает (и когда нет)». Разработчик перестаёт перепроверять, полагаясь на «умного» ассистента, и в результате уязвимости проходят в прод.
Особенно ярко это проявилось в экспериментах с железом: «ИИ не справляется с железом: как SystemVerilog разбил в пух и прах самые продвинутые модели». Если нейросеть не может корректно проверить Verilog-код для FPGA, почему вы думаете, что она справится с вашим микросервисом на Go?
Корень зла: самопроверка как антипаттерн
Идея «нейросеть сгенерировала — нейросеть проверила» — методологически неверна. LLM не обладают истинным пониманием семантики. Они предсказывают токены, опираясь на статистические паттерны. В 2024–2025 годах это приводило к катастрофам: ИИ генерировал код, который проходил все юнит-тесты, но содержал логические ошибки, выявляемые только нагрузочным тестированием. В 2026 году ситуация улучшилась, но фундаментальная проблема осталась. Как показано в статье «AI coding в 2026: 6 правил, которые спасут ваш код от ИИ-хаоса», доверять ИИ финальную проверку — правило номер один, которое нарушают чаще всего.
METR (Machine Learning Efficiency & Reliability) — открытый бенчмарк, запущенный в 2025 году фондом AI Safety. Он измеряет способность ИИ-агентов выполнять реалистичные задачи, включая поиск и исправление уязвимостей в коде. Результаты июня 2026 года показывают, что даже лучшие модели не дотягивают до уровня junior-разработчика с двумя годами опыта.
Двухконтурная схема: как убить иллюзию
Решение есть, и оно называется двухконтурная архитектура проверки.
- Первый контур — формальная верификация. Статический анализ (CodeQL, Infer, Semgrep), линтеры, закреплённые правила безопасности. Никакой вероятности — только детерминированные проверки по заданным паттернам. Этот контур отсекает 80% типовых уязвимостей: SQL-инъекции, XSS, переполнения буфера.
- Второй контур — ИИ-ассистент. Нейросеть (например, Claude или GPT-5) получает код и результат первого контура и предлагает гипотезы: «Здесь может быть гонка данных», «Проверь, не нарушена ли инвариантность транзакции». Но финальное решение всегда за человеком.
Такая схема не даёт ИИ «выдать добро» на опасный код. Она превращает его в инструмент подсветки рисков, а не финального судью. В статье «Как ИИ увеличивает поток ошибок: антипаттерны разработки и контроль качества при работе с нейросетями» подробно разобрано, почему без первого контура второй превращается в генератор шума.
Как это выглядит на практике
Возьмём типичный Python-микросервис. Первый контур: запускаем mypy (строгий режим), prospector с кастомными правилами безопасности, bandit на поиск опасных вызовов. Всё это даёт конкретные ошибки с указанием строк. Второй контур: отправляем код, результаты линтеров и описание архитектуры в GPT-5 с промптом «найди логические несоответствия». Модель может указать на потенциальную проблему с кэшированием, которую статический анализ не поймал. Разработчик проверяет вручную и принимает решение.
А что с «зелёным CI»?
Знакомая картина: CI горит зелёным, все тесты проходят, ИИ написал «всё ок», а через неделю прод падает из-за утечки памяти. Это классический зелёный CI и пустая архитектура, подробно описанный в статье «Зелёный CI и пустая архитектура: как ИИ-кодинг создаёт технический долг, которого вы не видите». Когда мы загоняем проверку только в CI, мы теряем контекст бизнес-требований. Двухконтурная схема решает и эту проблему — первый контур автоматизирует то, что можно автоматизировать, второй — подключает человека к смысловому анализу.
Почему METR стал индустриальным стандартом?
Потому что он честно показывает: ИИ не готов к самостоятельному code review. Один из тестов бенчмарка — найти и исправить уязвимость в коде, который написал сам ИИ. Результат: в 40% случаев модель «исправляет» ошибку, но вносит новую, ещё более опасную. Это напоминает эксперимент с чипами, когда нейросеть спроектировала процессор с логической ошибкой — «Провал ИИ в генерации кода: как нейросеть спроектировала чип размером с участок».
Резюме для тех, кто хочет спать спокойно
Не доверяйте ИИ проверку кода в одиночку. Никогда. Даже если это «самая умная» модель на рынке. Строите систему защиты — используйте двухконтурную архитектуру: детерминированный статический анализ как первый барьер, ИИ как помощник для человека — второй. И обязательно оставляйте финальное слово за живым разработчиком, который понимает бизнес-контекст.
В ближайшие два года рынок code review ждет расслоение: дешевые AI-решения без гарантий и дорогие гибридные системы с двухконтурной защитой. Выбор за вами. Но если ваш продакшн упадет из-за пропущенной ИИ ошибки, не говорите, что вас не предупреждали.
P.S. Уже сейчас можно внедрить первый контур бесплатно: CodeQL для GitHub, Infer от Facebook, Semgrep — open source. Начните сегодня. И не дайте иллюзии безопасности съесть ваш продакшн.
