Код-ревью с ИИ: 20 промптов для безопасности, рефакторинга и PR

Согласно отчёту DORA 2025, команды с ИИ-ревью сократили время проверки кода на 40-60% и выявляют ошибки на 50% эффективнее. Лучше всего нейросети справляются в компаниях со зрелыми практиками, где процессы уже выстроены. Большинство же разработчиков  уже пробует ИИ для программирования, но делает код ревью с ИИ поверхностно, поэтому получаются размытые комментарии, которые проще проигнорировать, чем применить. Рассказываем про 20 эффективных промптов, чтобы повысить точность выдачи и автоматизировать рефакторинг.

Простые промпты не работают

Нейросеть не понимает код в человеческом смысле. ИИ продолжает текст, опираясь на вероятность. Если пишете «проверь код», модель выдаёт усреднённый набор советов, который подойдёт к любому проекту. Чтобы ответы были полезными, нужен нормальный промпт-инжиниринг, промпты для ревью кода составляются по трем правилам.

Первое правило — роль. Скажите нейросети, кем ей быть. Например, «проверь функцию и выступи как senior-разработчик с опытом в высоконагруженных системах». Такой запрос сужает диапазон ответов, и нейросеть подбирает формулировки точнее.

Второе правило — контекст. Модель не видит проект целиком и не знает, зачем написан конкретный фрагмент кода. Объясните, что делает сервис, какой язык используете, где код будет работать.

Третье правило — цель. Когда просите одним запросом найти баги, оценить читаемость и переписать архитектуру, точность ответа снижается. Лучше давать по одной задаче за раз.

Промпты для аудита безопасности кода

ИИ опирается на топ уязвимостей OWASP, замечает типичные ошибки архитектуры и распознаёт опасные паттерны в коде. Разберём пять промптов под основные требования безопасной разработки.

Базовый аудит безопасности

Ты - senior security engineer с опытом аудита production-систем.
Проанализируй [язык]-код на уязвимости безопасности.

В первую очередь проверь наличие:
- SQL-инъекций и NoSQL-инъекций
- XSS (отражённый, хранимый, DOM-based)
- Небезопасной десериализации
- Уязвимостей аутентификации и авторизации
- Утечек чувствительных данных в логах и сообщениях об ошибках

Для каждой найденной проблемы дай таблицу с колонками:
критичность, номер строки, суть уязвимости, пример эксплуатации, исправленный фрагмент кода. Сначала перечисли только Critical и High уязвимсоти, потом остальное.

Если уязвимостей нет - так и напиши.

Код:
[вставить код]

Укажите язык явно, даже если он очевиден из кода. Это влияет на то, какие векторы атак проверяет ИИ во время код ревью.

Проверка аутентификации и авторизации

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

Сфокусируйся на:
- генерации, проверке и сроке жизни JWT (алгоритм, подпись, expiry)
- управлении сессиями (фиксация сессии, отсутствие инвалидации при логауте)
- разграничении доступа (IDOR, проверки на стороне клиента вместо сервера)
- horizontal и vertical privilege escalation

Для каждого вектора опиши сценарий: какой запрос отправит атакующий, что он получит и чего не хватает для защиты.

Код:
[вставить код]

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

Анализ работы с пользовательским вводом

Ты - application security engineer. Проследи путь каждого внешнего ввода в этом коде от точки входа до места использования.

Внешний ввод - это параметры запроса, тело POST, заголовки, загружаемые файлы, данные из внешних API.

Для каждого источника ввода покажи:
- строку, где данные попадают в приложение
- строку, где они используются (запрос к БД, рендеринг, команда ОС, путь к файлу)
- есть ли между этими точками валидация и санитизация
- если защиты нет - конкретный payload, который ломает логику

Не описывай теорию, привязывай каждый вывод к номерам строк в коде.

Код:
[вставить код]

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

Аудит зависимостей и библиотек

Ты - security engineer, отвечающий за supply chain security.

Проанализируй и составь отчёт:
- библиотеки с известными CVE (укажи идентификатор и краткое описание)
- сильно устаревшие версии, для которых давно вышли патчи
- транзитивные зависимости, которые стоит проверить отдельно
- рекомендуемая безопасная версия для каждого проблемного пакета

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

Список зависимостей проекта с версиями:
[вставить содержимое package.json / requirements.txt / pom.xml]

Нейросеть не имеет доступа к актуальным CVE-базам и может ошибаться в номерах уязвимостей. Используйте результат как первичный фильтр. Финальную проверку делайте через npm audit, pip-audit, trivy или OSV.dev.

Проверка секретов и credentials

Ты - security engineer. Найди в этом коде и конфигах секреты, которые не должны храниться в репозитории.

Ищи:
- API-ключи, токены доступа, пароли в открытом виде
- строки подключения к БД с логином и паролем
- приватные ключи и сертификаты
- секреты, замаскированные под обычные переменные или константы
- закомментированные credentials, оставшиеся от отладки

Для каждой находки укажи строку, тип секрета и степень риска.
Предложи, как вынести его в переменные окружения или секрет-менеджер.

Код и конфиги:
[вставить код]

Если нашли секрет в репозитории — смена значения в коде не решит проблему. Считайте его скомпрометированным и отзывайте на стороне сервиса.

Промпты для анализа производительности и оптимизации

Сode review с нейросетью выявляет неэффективные алгоритмы, утечки памяти и места, где приложение тратит ресурсы впустую.

Анализ сложности алгоритмов

Ты senior-алгоритмист. Оцени временную и пространственную 
сложность (Big O) каждой функции в этом коде.

Для каждой функции выдай:
1. Текущую сложность с пояснением, какая строка её определяет
2. Реальный сценарий, когда эта сложность станет проблемой (укажи примерный объём данных)
3. Вариант оптимизации, если он есть
4. Сложность после оптимизации

Не предлагай переписывать то, что и так работает за O(n) на малых данных. Сосредоточься на функциях, где сложность выше линейной или где есть вложенные циклы.

[код]

Модель охотно навешивает Big O там, где это не нужно. Поэтому ограничение в конце промпта важнее подробностей об анализе.

Поиск N+1 проблем в запросах к БД

Проверь этот код на N+1 проблемы и неэффективную работу с БД.

Обрати внимание на:
- запросы внутри циклов
- ленивую загрузку связанных сущностей (lazy loading)
- обращения к свойствам ORM-моделей, которые втихую 
  дёргают базу

Для каждой найденной проблемы:
1. Покажи конкретные строки
2. Посчитай, сколько запросов уйдёт в базу при N записей
3. Перепиши через eager loading или один батч-запрос
4. Покажи, сколько запросов останется после правки

Стек: [укажи ORM — Django ORM, SQLAlchemy, Eloquent и т.д.]

[код]

Указывать ORM обязательно, иначе модель выдаст общие рассуждения вместо конкретики. Например, у Django и SQLAlchemy разные механизмы ленивой загрузки, и совет по одному стеку ломает код на другом.

Анализ утечек памяти

Ты performance-engineer. Найди в этом коде потенциальные 
утечки памяти и места, где ресурсы не освобождаются.

Проверь:
- соединения (БД, файлы, сокеты), которые открываются, но не закрываются явно или через контекстный менеджер
- циклические ссылки между объектами
- замыкания, которые удерживают в памяти крупные объекты или коллекции дольше, чем нужно
- подписки на события и колбэки, с которых никто не отписывается
- глобальные или кэширующие структуры, растущие без ограничения

Для каждой проблемы объясни механизм утечки и предложи исправление с учётом особенностей сборщика мусора в [язык/рантайм].

[код]

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

Оптимизация конкретной функции

Функция вызывается примерно [X] раз в секунду и работает с входными данными размером [опиши: массив на ~N элементов, строка, объект и т.д.].

Оптимизируй её, строго сохранив текущее поведение и сигнатуру. 

Требования:
1. Объясни каждое изменение отдельно: что было, что стало, почему быстрее
2. Если меняешь алгоритм — укажи, как сместилась сложность
3. Отдельно отметь изменения, которые экономят микросекунды, и те, что дают порядок ускорения — чтобы я понимал приоритеты
4. Предупреди, если оптимизация ухудшает читаемость или повышает потребление памяти

[код функции]

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

Промпты для архитектурного ревью

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

Оценка соответствия SOLID

Действуй как software architect с опытом рефакторинга legacy-систем.

Проанализируй приложенный код по каждому из пяти принципов SOLID. Для каждого принципа дай:
1. Вердикт: соблюдён / нарушен / соблюдён частично
2. Конкретный пример из кода с указанием класса и метода
3. Чем грозит нарушение при дальнейшем развитии проекта
4. Минимальный рефакторинг, который исправит проблему

Если принцип неприменим к этому участку кода — так и напиши.

Код:
[вставить классы и их зависимости]

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

Поиск антипаттернов

Проверь код на антипаттерны:
- God Object (класс, который знает и делает слишком много)
- Spaghetti Code (запутанный поток управления)
- Magic Numbers (числовые литералы без объяснения)
- Copy-Paste Programming (дублирование логики)
- Feature Envy (метод, который лезет в данные чужого класса)

Для каждой находки укажи:
- файл и номер строки
- почему это проблема именно здесь, а не в теории
- степень критичности: блокер / стоит починить / косметика

Отсортируй результат от самого опасного к незначительному.

Степень критичности модель оценивает приблизительно, так что выводы подвергайте сомнению.

Ревью API-контракта

Сравни спецификацию API и её реализацию.

Спецификация (OpenAPI/описание):
[вставить контракт]

Реализация:
[вставить код хендлеров]

Проверь:
1. Соответствие реализации заявленным эндпоинтам, методам и схемам ответов
2. Именование: единый стиль путей и полей, отсутствие сокращений-загадок
3. Обработку ошибок: какие коды возвращаются, есть ли утечка внутренних деталей
4. Версионирование: что сломается у клиентов при изменении контракта
5. Расхождения между документацией и фактическим поведением

Для каждого расхождения покажи строку из спеки и строку из кода рядом.

Подавайте контракт и реализацию в одном промпте, иначе сравнивать будет не с чем. После код-ревью с ChatGPT внимательно проверяйте обработку ошибок. Утечка внутренних деталей в ответе — частая дыра, которую забывают при написании хендлеров.

Оценка тестируемости кода

Оцени, насколько легко покрыть этот код юнит-тестами.

Найди всё, что мешает тестированию:
- жёсткие зависимости вместо инъекции
- обращения к времени, рандому, сети, файлам и БД внутри логики
- статические методы и синглтоны
- отсутствие интерфейсов там, где нужна подмена

Для каждой проблемы:
1. Покажи проблемный фрагмент
2. Объясни, почему его сложно протестировать
3. Предложи изменение, после которого появится точка для мока

В конце дай примерную оценку: что покроется тестами сразу, что потребует рефакторинга перед написанием тестов.

Код:
[вставить модуль]

Не ждите от модели готовых тестов в этом промпте. Его задача — показать, где код придётся развязать перед тем, как мокать зависимости.

Промпты для рефакторинга и улучшения читаемости

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

Полный рефакторинг с запретом сокращений

Отрефактори код ниже. Цель — улучшить читаемость, не меняя поведение программы.

Жёсткое правило вывода:NEVER truncate, abbreviate, or use comments like "... rest of the code". Always output the COMPLETE implementation.

Что нужно от тебя:
1. Полный текст файла после изменений, целиком, без пропусков.
2. Под кодом — список правок, где по каждой ты объясняешь, что именно изменилось и зачем.
3. Если сомневаешься, меняет ли правка поведение, — не вноси её, а вынеси в отдельный список под названием "Спорные изменения".

[вставить код]

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

Именование переменных и функций

Выступи в роли технического писателя и senior-разработчика.

Пройди по коду и найди все неинформативные имена — data, temp, result, arr, val, obj, foo и подобные.

Для каждого такого имени:
- покажи строку, где оно объявлено;
- предложи 1–2 конкретных варианта замены, опираясь на то, что эта переменная реально хранит в данном контексте;
- если из кода непонятно, что внутри, — так и напиши.

Не переименовывай ничего сам, только предложи. 
Итоговый код выводи целиком, без сокращений.

[вставить код]

Промпт для ревью кода устанавливает запрет на изменения. Он оставляет решение за вами и не ломает внешние зависимости.

Разбивка длинных функций

Найди в коде функции длиннее 20 строк. Для каждой такой функции:

1. Опиши, сколько разных задач она сейчас решает (часто их 2–4, и они склеены в одну простыню).
2. Предложи разбивку на подфункции. По каждой новой подфункции укажи: её имя, зону ответственности и почему граница проходит именно здесь.
3. Покажи, как будет выглядеть исходная функция после выноса частей — она должна стать коротким оркестратором вызовов.

Выведи полный переписанный код, без "..." и без пропуска неизменённых участков.

[вставить код]

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

Промпты для code review PR и написания комментариев

Во время ревью кода можно скатиться либо в придирки по мелочам, либо в формальное одобрение. Языковая модель не заменит вас как ревьюера, но снимет часть рутины.

Ревью диффа PR

Ты — опытный ревьюер. Я дам тебе git diff. Проанализируй изменения и сосредоточься на трёх вещах:

1. Обратная совместимость. Изменились ли сигнатуры публичных функций, формат API, структура данных? Если да — что сломается у тех, кто уже использует этот код?

2. Edge cases. Какие граничные ситуации новый код не обрабатывает? Пустые коллекции, null, отрицательные значения, конкурентный доступ, таймауты — перечисли то, что относится к этому диффу.

3. Возможные регрессии. Есть ли места, где изменение могло задеть поведение, которое раньше работало? Особенно обрати внимание на общие утилиты и код, который вызывается из нескольких мест.

Для каждой найденной проблемы укажи конкретную строку или фрагмент. Если серьёзных рисков нет — так и напиши.

Вот дифф:
[вставить git diff]

Дифф удобен тем, что модель видит только изменения и не отвлекается на остальной код. По регрессиям нейросеть показывает направление, а не доказательство. Так что подозрительные места перепроверяйте самостоятельно.

Написание конструктивных комментариев к чужому коду

Выступи в роли ментора, который ревьюит код младшего коллеги. Твоя задача — не раскритиковать, а помочь автору вырасти.

Я дам фрагмент кода и опишу проблему, которую заметил. Сформулируй комментарий к PR по такой структуре:
— что именно вызывает вопрос (без оценочных слов вроде «плохо» или «неправильно»);
— почему это может стать проблемой в будущем;
— как можно переписать;
— короткий пример исправленного варианта.

Тон — уважительный и спокойный, как у коллеги, а не у проверяющего. Где уместно, формулируй замечание как вопрос или предложение, а не как приказ. Если у автора был разумный повод сделать именно так, допусти эту возможность вслух.

Код:
[вставить фрагмент]

Что меня смущает:
[описать своими словами]

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

Проверка описания PR

Проверь описание моего пул-реквеста глазами человека, который будет его ревьюить, но не был в контексте задачи. Вот заголовок и текст:

Заголовок: [вставить]
Описание: [вставить]

Ответь на вопросы:
1. Понятно ли из описания, что именно изменилось и зачем? Если приходится догадываться — укажи, чего не хватает.
2. Есть ли контекст: какую проблему решает PR, почему выбран такой подход, что осталось за кадром?
3. Указаны ли риски и побочные эффекты — что стоит проверить ревьюеру с особым вниманием?
4. Понятно ли, как проверить изменения вручную, если это нужно?

В конце предложи улучшенный вариант описания, сохранив мой смысл и не добавляя того, чего я не писал.

Модель хорошо ловит моменты, где приходится догадываться, потому что у неё и правда нет вашего контекста. Следите, чтобы в улучшенном варианте нейросеть не дописала деталей от себя.

Мастер-промпт для комплексного ревью

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

Ты - senior-разработчик со специализацией в [укажи стек: например, Python/Django, бэкенд].

Проведи code review кода ниже. Анализируй по четырём направлениям, именно в этом порядке приоритета:

1. БЕЗОПАСНОСТЬ — инъекции, утечки данных, небезопасная работа с вводом, проблемы с авторизацией.
2. ПРОИЗВОДИТЕЛЬНОСТЬ — лишние обходы коллекций, запросы к БД в циклах, неоптимальная сложность алгоритмов.
3. ЧИТАЕМОСТЬ — невнятные имена, дублирование, перегруженные функции, комментарии, объясняющие «что» вместо «почему».
4. АРХИТЕКТУРА — нарушения SOLID, скрытые зависимости, известные антипаттерны.

Каждую проблему оформляй строго по шаблону:
— Категория: [безопасность / производительность / читаемость / архитектура]
— Где: [номер строки или короткий фрагмент кода]
— В чём проблема: [что не так и чем это грозит]
— Как исправить: [конкретное решение, по возможности с фрагментом кода]
— Серьёзность: [критично / важно / на будущее]

Сначала выводи критичные проблемы, потом остальные по убыванию.

Если в каком-то блоке проблем нет — напиши это явно и объясни, почему ты считаешь блок чистым. Не пропускай находки молча и не пиши «всё хорошо» без аргументации.

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

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

Инструменты для автоматизации

CodeRabbit и PR-Agent цепляются к GitHub или GitLab и сами комментируют пулреквесты после их создания. Инструменты указывают на потенциальные баги, предлагают переименовать переменные, замечают дубли. Разработчику остаётся прочитать замечания и решить, что исправлять.

Ещё внимания заслуживает многоагентный подход, который Anthropic показала в Claude Code Review. В многоагентном ревью можно вынести повторяющиеся проверки в AI-скиллы: один навык отвечает за безопасность, второй — за архитектуру, третий — за стиль и читаемость. За счёт такого разделения замечания получаются более точными. Минус в том, что настройка требует времени и понимания, какие именно проверки вам нужны.

Команды покрупнее выбирают SonarQube, где к статическому анализу прикрутили LLM. Теперь инструмент помечает проблемный участок и объясняет, как исправить код. Хорошо подходит там, где важна история проверок и интеграция с уже выстроенным пайплайном.

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

Частые вопросы о код-ревью с ИИ

Какой ИИ лучше для код-ревью — ChatGPT или Claude?

Claude держит контекст больших файлов лучше и реже выдумывает несуществующие методы. ChatGPT быстрее и удобнее, когда нужно прогнать много мелких сниппетов подряд.

Можно ли доверять ИИ-ревью без проверки человеком?

Нет, ИИ ловит типовые проблемы вроде дублирования, непонятных имён и пропущенной обработки ошибок, но не знает контекста проекта и предлагает правки, которые ломают бизнес-логику.

Сколько токенов нужно на ревью одного файла?

Если ревьюите большие файлы через Claude Code, следите за контекстом и расходом токенов: один файл на 200 строк может легко превратиться в 6–8 тысяч токенов с ответом и пояснениями. Если просите развёрнутые объяснения по каждому замечанию, расход вырастает в 2-3 раза. Для оценки бюджета держите в голове цифру около 6-8 тысяч токенов на средний файл.

Как сделать так, чтобы ИИ не сокращал вывод?

Явно пропишите в промте, что нужен полный разбор без пропусков. Помогает разбивка задачи: вместо одного запроса на весь файл отправляйте его частями. Если код ревью с ИИ всё равно обрывается, добавьте в конце инструкцию продолжить с того места, где остановился.

Работают ли эти промты в Cursor и GitHub Copilot?

В Cursor есть полноценный чат с доступом к файлам проекта, так что промты переносятся почти без изменений. Copilot заточен под автодополнение прямо в редакторе, и развёрнутые инструкции туда вписываются хуже, хотя в режиме Copilot Chat большинство примеров тоже сработает.

---

Качество ревью зависит от точности запроса. Рекомендуется задавать роль, ограничивать фокус одной задачей и явно прописывать формат вывода. Так работает код-ревью с ИИ на практике, и 20 промптов выше дают готовую основу под основные сценарии — от аудита безопасности до разбора пулреквеста.

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

Советуем дополнительно почитать по теме:

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

Куда расти бэкенд-разработчику в 2026–2027 — карьерные направления для backend-разработчика: архитектура, DevOps, AI-инженерия, MLOps и системное мышление.

12 AI GitHub-репозиториев 2026: Ollama, n8n, Claude Code и OpenHands — подборка AI-инструментов для локальных моделей, автоматизации, агентной разработки и работы с кодом.

15 скиллов для AI-агентов: установка и как работает в 2026 — как подключать готовые навыки к агентам и превращать повторяющиеся промпты в системные сценарии.

Динамическое программирование: что это такое и зачем нужно — полезное продолжение к разделу про сложность алгоритмов: как думать о подзадачах, памяти и ускорении вычислений.