Промпт недели: как ИИ проверяет код, написанный ИИ

В начале мая кто-то в r/ClaudeAI опубликовал вопрос: «Как вы сейчас делаете ревью AI-генерированных pull request?» Ветка набрала 400+ комментариев за сутки. Сам факт вопроса говорит о многом: два года назад такой проблемы просто не существовало.

Когда код пишет ИИ, его ошибки другие. Человек путается в логике, забывает граничные случаи, делает опечатки. ИИ пишет синтаксически чистый код, который при этом делает не то: плодит абстракции там, где нужна простота, уверенно вызывает несуществующие методы, игнорирует контекст системы вокруг. Искать такое нужно с другим прицелом.

Хорошая новость: проверять AI-код через ИИ работает — если есть правильный промпт.

Откуда этот шаблон

Мы собрали несколько подходов из обсуждений в r/ClaudeAI и r/ChatGPT, проверили на реальных задачах и свели в один шаблон. Он тестировался на Python, TypeScript и Go. Работает в Claude и ChatGPT — с небольшими поправками под каждый сервис.

Промпт

Ты — старший инженер с 10+ годами опыта в [язык/стек].
Проведи code review следующего кода.

Ответь строго по этой структуре:

КРИТИЧЕСКИЕ ПРОБЛЕМЫ
Баги, уязвимости, утечки памяти, race conditions.
Если нет — пиши «нет».

АРХИТЕКТУРНЫЕ ЗАМЕЧАНИЯ
Структура, паттерны, читаемость, масштабируемость.

МЕЛКИЕ УЛУЧШЕНИЯ
Именование, стиль, незначительная оптимизация.

ЧТО СДЕЛАНО ХОРОШО
Обязательный раздел. Найди то, что написано правильно.
Если весь код хорош — так и напиши.

ПРИОРИТЕТЫ
До мержа: [список]
После: [список]
Можно проигнорировать: [список]

Правило: если код хорош — не придумывай замечаний ради объёма.
Если код плох — говори прямо, без смягчений.

Контекст: [что делает этот код, для какой системы, насколько критично]

Код:
[вставь сюда]

Что делает каждая часть

Роль с конкретным стеком

Без указания стека ответ получается общим. Когда в промпте стоит «старший инженер в Python» — модель иначе расставляет приоритеты: типизация, mypy, идиоматичность важны для Python, но не универсальны. Роль сужает фокус до того, что реально имеет значение в этом конкретном контексте.

Фиксированная структура ответа

Без неё критический баг и опечатка в комментарии могут стоять рядом в одном абзаце. Структура заставляет модель сначала классифицировать, потом описывать. Приоритеты видны с первого взгляда — не нужно читать всё, чтобы понять, что срочно.

Раздел «Что сделано хорошо» как обязательный

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

«Не придумывай замечаний ради объёма»

ChatGPT особенно склонен генерировать псевдо-критику, чтобы ответ выглядел содержательным. После этой фразы результат заметно чище. В ревью хорошего кода появляется «нет» вместо пяти абзацев о несущественных вещах.

Поле «Контекст»

Ревью без контекста — угадывание. Одни и те же 60 строк могут быть отличным прототипом или ужасным продакшн-кодом. Разница — в требованиях к надёжности, безопасности, производительности. Без контекста модель принимает решения вслепую. С контекстом — понимает, что здесь важно, а что нет.

Пример того, что получается

Мы скормили этот промпт куску Python — парсер CSV на 70 строк, написанный Claude Code для разовой задачи импорта данных. Контекст прописали явно: не продакшн, нужен один раз.

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

Время ответа — 14 секунд. Все три пункта были точными.

Три вариации для разных задач

Для ревью PR целиком добавь перед кодом: «Сначала прочитай весь diff и оцени архитектуру изменений в целом. Потом разбирай файлы по очереди». Без этого модель начинает с первого файла и теряет общую картину.

Для security review замени роль: «Ты — security engineer, специализируешься на [веб/API/данные]». И добавь: «Сфокусируйся на инъекциях, утечках данных, проблемах аутентификации. Архитектурные красоты — вторично». Это меняет угол атаки.

Для сравнения двух реализаций подай оба варианта сразу: «Вот два варианта решения одной задачи. Выбери лучший для продакшн-системы с аргументацией. Не уклоняйся от однозначного ответа». Последняя фраза критична — без неё получишь «оба подхода имеют свои достоинства».

Где работает лучше

Claude лучше держит длинный контекст — важно при ревью больших PR с несколькими файлами. Умеет отслеживать связи между файлами и замечать архитектурные противоречия на уровне всего изменения. ChatGPT с GPT-4o чуть агрессивнее в поиске проблем безопасности. Для кода, который идёт в критичную систему, стоит прогнать через оба: они расставят акценты по-разному, и это полезнее одного ответа.