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

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

Промт, который ищет конкретное

Ты — ревьюер. Проверь код ниже. Ищи ТОЛЬКО перечисленные классы проблем. ЧТО ИСКАТЬ: 1. Обращение к данным, которых может не быть: null, пустая коллекция, отсутствующий ключ, необязательное поле. 2. Границы: пустой вход, один элемент, максимальный размер, отрицательное число, ноль. 3. Ресурсы: незакрытые файлы, соединения, транзакции; утечки при исключении. 4. Конкурентность: общее изменяемое состояние, проверка-и-действие без атомарности. 5. Данные извне: отсутствие валидации, конкатенация в запрос, путь из пользовательского ввода. 6. Обработка ошибок: проглоченные исключения, потеря контекста, откат наполовину. ЧЕГО НЕ ДЕЛАТЬ: - Не предлагать переименования, форматирование и стилистику. - Не переписывать работающий код ради красоты. - Не выдумывать поведение вызываемых функций. Если оно неизвестно — так и пиши. ФОРМАТ ОТВЕТА: Для каждой находки: строка, класс проблемы, конкретный сценарий, при котором она проявится, и минимальная правка. Отдельным блоком: «Не могу проверить без контекста» — что именно нужно увидеть. Если по какому-то классу проблем не нашлось — напиши, что не нашлось. КОД: [вставить]

Последние два требования делают половину работы. Список «не могу проверить» показывает, где ревью неполно, а разрешение сказать «не нашлось» снимает давление, из-за которого модель выдумывает проблемы.

Что дать вместе с кодом

Про уязвимости отдельно

Заголовок статьи обещает поиск уязвимостей за тридцать секунд, и здесь нужна честность: за тридцать секунд находится только очевидное. Инъекции через конкатенацию строк, путь из пользовательского ввода, отключённая проверка сертификата, секрет в коде — это ИИ видит хорошо. Логические дыры в правах доступа, ошибки в бизнес-логике, проблемы, возникающие только в связке нескольких сервисов, он не увидит: у него нет всей системы перед глазами.

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

Как проверять результат ревью

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

Где это встроить

Разумное место — перед тем, как отправлять пул-реквест человеку. Прогоняете свой диф, чините очевидное, и коллега тратит внимание на архитектуру и смысл, а не на забытую проверку на пустой список. Автоматизировать ИИ-ревью в CI и требовать его прохождения не стоит: ложных срабатываний хватит, чтобы команда научилась его игнорировать за неделю.

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

Без схемы происходит предсказуемое: модель придумывает таблицу users с полем created_at, потому что так бывает чаще всего. Запрос выглядит убедительно и не работает.

Как передать схему

Не описывайте словами. Дайте DDL — это самый компактный и точный способ.

Вот структура базы: [вывод SHOW CREATE TABLE для каждой таблицы, или CREATE TABLE из миграций] Дополнительно: - объёмы: [таблица - примерное число строк] - какие поля индексированы: [из DDL видно, но подтверди явно] - СУБД и версия: [PostgreSQL 16 / MySQL 8 / другое] - что означают неочевидные поля: [status = 0 черновик, 1 опубликовано] ЗАДАЧА: [описание нужного результата словами, с примером желаемых строк] ТРЕБОВАНИЯ: - Используй только существующие таблицы и поля. Если чего-то не хватает — скажи, а не придумывай. - Учитывай диалект указанной СУБД. - Объясни выбор типа соединения для каждого JOIN. - Предупреди, если запрос даст дубликаты строк из-за связи «один ко многим».

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

Проверка результата

1. Сначала COUNT. Запустите с COUNT(*) вместо полей и без агрегации. Если строк больше, чем ожидали, — размножение по джойну.
2. Потом LIMIT 20. Глазами посмотрите на данные. Некорректные джойны видны сразу.
3. Потом EXPLAIN. Полное сканирование большой таблицы или вложенный цикл по миллионам строк — повод переписать.
4. Сверьте с известным числом. Возьмите один день или одного клиента, посчитайте отдельным простым запросом, сравните.

Промт для оптимизации

Вот запрос и его план выполнения: ЗАПРОС: [текст] ПЛАН: [вывод EXPLAIN ANALYZE] ОБЪЁМЫ: [строки в задействованных таблицах] СУЩЕСТВУЮЩИЕ ИНДЕКСЫ: [список] Найди узкие места по плану, а не по виду запроса. Для каждого: что именно дорого, почему, и три варианта решения — переписать запрос, добавить индекс, изменить схему. Для предложенного индекса укажи: по каким полям, в каком порядке, почему такой порядок, и чем этот индекс обойдётся при вставках. Не предлагай индексы, которые дублируют существующие по префиксу.

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

Что модель делает плохо

• Путает диалекты. Синтаксис оконных функций, работа с датами, конкатенация, upsert — везде различия. Указывайте СУБД и версию явно.
• Оценивает производительность на глаз. Утверждения «этот вариант быстрее» без плана считайте гипотезой.
• Игнорирует NULL. Классическая ловушка: NOT IN с NULL внутри подзапроса возвращает пустоту. Попросите отдельно проверить поведение при NULL в каждом сравнении.
• Не знает о блокировках. Запрос, который на тестовой базе летает, на боевой может встать в очередь.

Про ER-диаграмму

Если схема большая, полезно попросить обратное — не запрос из схемы, а схему из запросов: «по этим двадцати запросам восстанови связи между таблицами и нарисуй их в текстовом виде». Так находятся неявные связи, о которых знали только авторы, и места, где внешние ключи существуют в головах, но не в базе. Это, пожалуй, самый недооценённый способ применить ИИ к чужой базе данных.

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

Но по умолчанию модель выдаёт учебный пример: один эндпоинт, словарь вместо базы, никакой обработки ошибок. Чтобы получить работающий код, каркас надо задать в промте.

Промт для ресурса целиком

Ты — backend-разработчик. Напиши CRUD для ресурса [название] на FastAPI. КОНТЕКСТ: Python [версия], FastAPI, SQLAlchemy [версия], PostgreSQL. Аутентификация уже есть, зависимость get_current_user возвращает объект User с полями [перечислить]. МОДЕЛЬ: [поля, типы, обязательность, ограничения] ТРЕБОВАНИЯ: 1. Отдельные схемы Pydantic: Create, Update, Response. В Response не отдавать внутренние поля [перечислить]. 2. Валидация на границе: длины строк, диапазоны чисел, форматы. Ошибка валидации — 422 с указанием поля. 3. Коды ответов явно: 201 на создание, 204 на удаление, 404 если нет, 409 на конфликт уникальности, 403 если чужой объект. 4. Список — с пагинацией через limit/offset, максимум limit = 100, и с общим количеством в ответе. 5. Частичное обновление через PATCH, не подменяя незаданные поля на None. 6. Никаких блокирующих вызовов в async-функциях. Работа с БД — через сессию, переданную зависимостью. 7. Каждый эндпоинт с описанием и примером в docstring — они попадут в OpenAPI. ЧЕГО НЕ ДЕЛАТЬ: - не изобретать структуру проекта, использовать: routers/, schemas/, models/, services/; - не писать бизнес-логику в обработчике маршрута, выносить в сервис; - не ловить голый Exception.

Пункт пятый ловит частую ошибку: наивная реализация PATCH затирает поля, которые клиент не присылал. В Pydantic это решается через exclude_unset, и об этом надо попросить прямо.

Что попросить следом

Документация

OpenAPI FastAPI собирает сам, но по умолчанию она бедная. Отдельный промт:

Дополни эндпоинты метаданными для OpenAPI: summary и description для каждого маршрута, description для каждого поля схем, примеры запроса и ответа через Field(examples=...), описание всех возможных кодов ответа через responses=, теги для группировки маршрутов. Тексты пиши так, чтобы их читал сторонний разработчик, не знакомый с нашей предметной областью.

Последняя фраза важна. Без неё описания получаются в стиле «Создаёт объект» — то есть повторяют название метода и не добавляют ничего.

Что проверять руками

• N+1 в списке. Модель почти всегда забывает про selectinload для связанных объектов.
• Права на чужой объект. Проверка владельца часто оказывается только в GET и отсутствует в PATCH и DELETE.
• Транзакции. Где начинается и заканчивается — модель об этом обычно не думает.
• Версии библиотек. Синтаксис Pydantic и SQLAlchemy заметно менялся между мажорными версиями; несоответствие даёт код, который не запустится.

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

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

Лечится сменой источника. Тесты пишутся не по коду, а по ожидаемому поведению. Значит, и в промт надо давать не реализацию, а контракт.

Промт по контракту, а не по коду

Ты пишешь тесты. Вот описание функции — реализацию я намеренно не показываю. СИГНАТУРА: [имя, параметры с типами, возвращаемое значение] ЧТО ДЕЛАЕТ: [в двух-трёх фразах, на языке предметной области] ПРЕДУСЛОВИЯ: [что гарантирует вызывающий] ПОСТУСЛОВИЯ: [что гарантирует функция] ОШИБКИ: [какие исключения и когда] Напиши тесты на [pytest / unittest], покрывающие: 1. Обычный случай — 2 теста с разными данными. 2. Границы: пустое, один элемент, максимум, ноль, отрицательное. 3. Некорректный вход: каждый описанный класс ошибок отдельным тестом. 4. Инварианты: что должно оставаться верным при любых входных данных. ПРАВИЛА: - Одна проверка на тест. Имя теста описывает сценарий, а не функцию. - Никаких моков там, где можно обойтись реальными объектами. - Не подстраивай ожидаемые значения под удобство — считай их по описанию. - Отдельно перечисли случаи, которые ты не смог протестировать, и почему.

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

Проверка самих тестов

Тест бесполезен, если проходит и на сломанном коде. Проверяется это просто: сломайте код нарочно.

Вот функция и тесты к ней. Предложи 7 мелких изменений в функции, которые её ломают: сдвиг границы на единицу, замена < на <=, перестановка аргументов, пропуск проверки, возврат вместо исключения, неверный порядок операций, отсутствие обработки пустого входа. Для каждого скажи, упадёт ли хоть один тест. Изменения, которые тесты не заметят, — это дыры. Перечисли их отдельно.

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

Что стоит и не стоит тестировать

Отдельный приём: тест из бага

Каждый найденный баг — готовое техзадание на тест. Промт короткий и окупается быстрее всех остальных:

Вот описание бага: [что сделали, что ожидали, что получилось]. Вот исправление: [диф]. Напиши тест, который падал бы до исправления и проходит после. Тест должен проверять поведение, а не конкретные строки исправления — чтобы он остался осмысленным после рефакторинга.

Чего не надо ждать

• Интеграционных сценариев. Модель не знает, как ваши части соединяются в реальности.
• Реалистичных данных. Она сгенерирует «test@example.com» и «Иван Иванов», а падает всё обычно на данных с пробелами, эмодзи и апострофами в фамилии.
• Понимания, что важно. Она распределит внимание равномерно по всем функциям, включая те, что никогда не ломались.
• Правильных ожидаемых значений в сложных расчётах. Их считайте сами: если модель ошиблась в ожидании, тест закрепит ошибку.

Разумный режим работы

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

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

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

Шаг 1. Понять, что код делает

Вот функция из легаси-проекта. Не предлагай улучшений. Объясни: 1. Что она делает — по шагам, на языке предметной области, а не на языке кода. 2. Какие у неё входы, включая неявные: глобальные переменные, состояние объекта, файлы, окружение, время. 3. Какие побочные эффекты: что она пишет, отправляет, меняет. 4. Какие ветки выглядят как обработка редких, но реальных случаев. 5. Что выглядит мёртвым кодом, и по какому признаку это можно проверить. КОД: [вставить]

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

Шаг 2. Характеризующие тесты

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

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

Шаг 3. Разбор на части

Теперь предложи разбить функцию на части. Условия: - каждый шаг — отдельное, самостоятельно работающее изменение; - после каждого шага код компилируется и тесты проходят; - шаги упорядочены от самого безопасного к самому рискованному; - ни один шаг не меняет поведение. Для каждого шага: что делаем, почему это безопасно, какой тест это подтвердит. Начни с выделения чистых вычислений — без ввода-вывода и без состояния. Отдельно назови изменения, которые нельзя сделать безопасно, и что нужно сделать до них.

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

Порядок, который работает

1. Зафиксировать поведение тестами.
2. Вынести чистые вычисления в отдельные функции.
3. Сделать неявные зависимости явными — передавать параметрами.
4. Разделить чтение данных, вычисление и запись.
5. Дать осмысленные имена — теперь их видно.
6. И только теперь обсуждать архитектуру.

Пункты 2 и 3 дают больше всего пользы за единицу риска. Часто после них необходимость в «чистой архитектуре» отпадает: код становится читаемым и без неё.

Ограничения модели на легаси

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

Когда не рефакторить

Если код работает, никто его не трогает и менять там ничего не планируется — оставьте. Рефакторинг оправдан там, где вы собираетесь вносить изменения: он окупается будущими правками. Приводить в порядок код, к которому не вернутся, — трата времени с ненулевым риском что-нибудь сломать.