TL;DR
AI-инструменты (Claude Code, Codex, Cursor) всё активнее пишут реальный код и отправляют его в настоящие проекты. Проблема не в том, что такой код отклоняют — его принимают охотно. Проблема в том, что происходит после приёмки.
AI-код выглядит чистым снаружи и оказывается ненадёжным внутри. Форматирование правильное, стиль соблюдён, линтер не ругается — но логические ошибки и уязвимости прячутся глубже. В итоге такой код требует на 46% больше исправлений и на 45% больше фикса багов, чем человеческий. Разработчики описывают ситуацию точно: "генерировать дёшево, убирать за AI — дорого."
Главный предиктор проблем — отсутствие ревью. Каждые 10 процентных пунктов роста доли кода без проверки = примерно +6% к нагрузке на исправления. Простой вывод: AI-код нужно проверять строже, не мягче. И просить AI проверить самого себя — это не паранойя, а здравый смысл, подкреплённый данными.
Схема метода
Это не один промпт, а принцип работы с AI-кодом в два прохода:
PASS 1: Генерация
AI пишет код → получаешь "работающий" результат
PASS 2: Верификация (отдельный запрос)
AI проверяет тот же код → ищет баги, уязвимости, зависимости
Оба прохода — в обычном чате, без инструментов.
Ключевой инсайт: без второго прохода ты принимаешь код который выглядит правильно, но статистически скорее всего потребует исправлений позже.
Пример применения
Задача: Ты запустил небольшой магазин на Tilda и попросил Claude написать Python-скрипт — автоматически выгружать заказы из Google Sheets и отправлять уведомления покупателям в Telegram. Скрипт "заработал" — и ты поставил его на сервер.
Промпт — Pass 1 (генерация):
Напиши Python-скрипт: читает новые строки из Google Sheets
(через gspread), отправляет уведомление в Telegram покупателю
через бота. Токен бота и ID таблицы — через переменные окружения.
Промпт — Pass 2 (верификация — отдельное сообщение):
Теперь переключись в роль старшего разработчика с паранойей
по безопасности. Проверь этот код по трём направлениям:
1. БАГИ: Что может сломаться при реальном использовании?
Где не обработаны исключения? Что будет при пустой таблице,
недоступном API, дублях строк?
2. БЕЗОПАСНОСТЬ: Где код уязвим? Как хранятся токены и
ключи? Есть ли риск утечки данных покупателей?
3. ЗАВИСИМОСТИ: Какие библиотеки используются? Есть ли
известные проблемы с этими версиями? Что нужно закрепить
в requirements.txt?
По каждому пункту — конкретные строки кода и исправления.
Результат: Во втором запросе модель найдёт то, что пропустила в первом: необработанные исключения при сбое сети, отсутствие дедупликации (одно уведомление улетит дважды), токен бота в логах, незакреплённые версии библиотек. Ты получишь конкретный список правок до того, как скрипт ошибётся на реальных заказах.
Почему это работает
AI оптимизирует под "работает сейчас". Когда модель генерирует код, она строит текст по паттернам: синтаксически верно, стилистически чисто, задачу выполняет. Но "работает на примере" и "выдержит реальную нагрузку с краевыми случаями" — разные задачи. Первая оптимизируется хорошо. Вторая требует другого запроса.
Код без ревью — это и есть главная проблема. Исследование показало: сильнейший предиктор роста числа исправлений — доля кода, который приняли без проверки. AI прошёл автоматические тесты → зеленый статус → слияние → баг в продакшне. Механика одна и та же и в GitHub-репозитории, и в твоём скрипте на сервере.
Второй проход меняет задачу модели. В первом запросе контекст — создать решение. Во втором — найти проблемы в готовом. Это разные режимы генерации с разными паттернами. Модель, которая только что написала код, в режиме критики замечает то, что пропустила в режиме создания — не потому что "думает лучше", а потому что другая формулировка запускает другую цепочку генерации.
Рычаги управления:
| Элемент | Что менять | Эффект |
|---|---|---|
| Три направления проверки | Убери зависимости, добавь производительность | Фокус на нужном |
| "Старший разработчик с паранойей" | Замени на "DevSecOps-инженер" | Острее на безопасности |
| Отдельный запрос | Сделай частью исходного промпта | Проще, но чуть поверхностнее |
| Конкретные строки и исправления | Убери это требование | Получишь общие рекомендации |
Шаблон промпта
Pass 2 — универсальный шаблон верификации:
Переключись в роль старшего разработчика с паранойей по
безопасности. Проверь этот код по трём направлениям:
1. БАГИ: Что сломается при реальном использовании?
Где не обработаны исключения? Краевые случаи: {краевые_случаи}
2. БЕЗОПАСНОСТЬ: Где код уязвим? Как хранятся {чувствительные_данные}?
3. ЗАВИСИМОСТИ: Какие библиотеки используются?
Есть ли риски с их версиями?
По каждому пункту — конкретные строки и исправления.
Код для проверки:
{код}
Плейсхолдеры:
- {краевые_случаи} — что может пойти не так: пустые данные, сбой сети, дубли
- {чувствительные_данные} — токены, пароли, данные пользователей, API-ключи
- {код} — вставь сгенерированный код
🚀 Быстрый старт — вставь в чат:
Вот шаблон для верификации AI-кода. Адаптируй под мою задачу:
{опиши что делает твой код}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит что за код, какие данные он обрабатывает, какие сценарии использования — потому что без этого невозможно понять что именно искать в разделах "Баги" и "Безопасность".
Ограничения
⚠️ Только для кода: Исследование целиком про программный код. Для текстов, таблиц, расчётов — принцип "второго прохода" полезен, но статистика из этой работы там не применима.
⚠️ AI не видит рантайм: Второй проход находит статические проблемы — то, что видно в тексте кода. Ошибки, которые возникают только при реальном запуске с живыми данными, без запуска не обнаружить.
⚠️ Глубина зависит от модели: Верификация работает хорошо для типовых уязвимостей. Нестандартная бизнес-логика или архитектурные решения — требуют человека.
⚠️ Контекст исследования — открытый опенсорс: 182 публичных репозитория с активным использованием AI-агентов. Закрытые проекты и случайные скрипты в чате могут вести себя иначе.
Как исследовали
Исследователи из Университета Иллинойса и Университета Джорджа Вашингтона решили проследить жизнь AI-кода после того, как его приняли в проект — чего почти никто раньше не делал. Все предыдущие исследования смотрели на стадию до слияния: приняли PR или нет, сколько комментариев оставили ревьюеры.
Команда взяла 182 публичных GitHub-репозитория с устойчивым потоком AI-коммитов и отслеживала их год — с мая 2025 по май 2026. Каждую строку кода из каждого коммита пометили как "человеческую" или "от AI" (Claude Code, Codex, Cursor, Devin и другие) и следили: выжила эта строка или была изменена/удалена, и кем и зачем. Параллельно прогоняли Semgrep (поиск уязвимостей в коде) и OSV-Scanner (уязвимости в зависимостях) после каждого коммита.
Неожиданный результат: суммарная частота изменений у AI и людей — одинаковая. Казалось бы, всё нормально. Но когда разбили по типам, картина перевернулась: AI-код почти не трогают ради рефакторинга или стиля (он уже отформатирован) — зато баги в нём исправляют значительно чаще. Разница не в количестве изменений, а в их причинах. Это и есть скрытый долг: снаружи метрики одинаковые, внутри — качественно разное.
Ещё один любопытный эффект: долг накапливается. Чем больше AI-кода принято в этом месяце — тем больше исправлений (в том числе от людей) в следующем. Проблемы не распределены равномерно, а нарастают как снежный ком.
Адаптации и экстраполяции
🔧 Адаптация: "Дьявольский адвокат" вместо "старшего разработчика"
Если задача не код, а бизнес-решение, стратегия, договор — тот же принцип двух проходов работает:
Ты — дьявольский адвокат. Твоя задача: найти всё, что может
пойти не так в этом {тип документа}.
Три угла атаки:
1. ЧТО УПУЩЕНО: какие сценарии не рассмотрены?
2. ГДЕ ЛОГИКА ЛОМАЕТСЯ: внутренние противоречия, слабые допущения
3. КАК ЭТО ИСПОЛЬЗУЮТ ПРОТИВ ТЕБЯ: кто и как может это оспорить?
По каждому пункту — конкретный абзац и предложение по исправлению.
{документ}
Работает для договоров, питч-деков, маркетинговых стратегий, ТЗ — везде, где первый генерированный вариант оптимизирован под "выглядит убедительно", а не под "выдержит реальную проверку".
Ресурсы
Do These Violent Delights Have Violent Ends? Measuring the Post-Merge Fate of Agentic Code
Chunqiu Steven Xia — University of Illinois Urbana-Champaign
Courtney Miller — George Washington University
Инструменты из исследования: Agents in the Wild dataset, Semgrep, OSV-Scanner, SonarQube