Как проверять код, сгенерированный ИИ

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

Надёжный подход — считать такой код черновиком pull request, а не готовым фрагментом для вставки. Ниже не «десять красных флагов», а порядок приёмки, который можно повторять для скрипта, API-обработчика и небольшой функции. Для критических систем к нему всё равно добавляются правила вашей команды и обычное ревью.

1. Начните с задачи и ожидаемого поведения

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

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

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

2. Принимайте маленький diff

Не объединяйте большой сгенерированный блок с несколькими идеями. Внесите изменение отдельной веткой, посмотрите diff и проверьте каждую строку, которая меняет поведение. Малый diff проще откатить, проще покрыть тестом и проще показать коллеге.

Особенно внимательно смотрите на участки, где код:

• ловит исключения и «молча» продолжает работу;
• меняет преобразование дат, денег или кодировок;
• добавляет any, отключает линтер или убирает тест;
• меняет права доступа, обработку сессии или CORS;
• вызывает командную строку, сеть, файловую систему;
• подставляет значение по умолчанию вместо явной ошибки.

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

3. Запустите код в среде, близкой к реальной

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

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

Если модель предлагает команду, которую вы не понимаете, не запускайте её с административными правами и не копируйте в production. Разберите аргументы, найдите её место в документации проекта или спросите более опытного коллегу.

4. Проверьте зависимости и выдуманные детали

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

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

Инструмент для кода можно выбирать по удобству работы с репозиторием, но не по обещанию «пишет без ошибок». В карточке Claude Code есть ориентиры для оценки ассистента в рабочем цикле; перед подключением к проекту всё равно проверьте доступ к файлам, условия хранения контекста и список команд, которые он способен вызвать.

5. Сделайте короткую проверку безопасности

Не нужно превращать каждую правку в полный аудит, но нужен обязательный минимум. Проследите путь пользовательского ввода до базы, шаблона, файловой системы и командной строки. Убедитесь, что данные валидируются по ожидаемому типу и не становятся частью SQL, shell-команды или HTML без безопасной обработки.

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

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

6. Проведите человеческое ревью и сохраните решение

Перед merge покажите diff человеку, который знает соответствующую часть проекта. В описании PR укажите цель, тестовые сценарии, новую зависимость (если есть) и известные ограничения. Не прячьте участие ИИ из стыда или привычки: для ревью важнее понимать происхождение решения и места, где его нужно проверить внимательнее.

Если после релиза возникает ошибка, сохраните короткую заметку: какой контекст дали модели, что пропустили в проверке и какой тест добавили. Это не поиск виноватого, а способ улучшить процесс. Через несколько таких заметок команда увидит повторяющиеся слабые места: например, асинхронные ошибки, обработку null или неправильные права.

«Vibe coding» может быть отличным способом быстро проверить идею, но для рабочего кода нужен переход к обычной инженерной дисциплине. Об этом разграничении подробнее — в разборе vibe coding.

Чек-лист перед merge

1. Задача и границы изменения сформулированы до генерации.
2. Diff мал, понятен и не содержит лишних переписываний.
3. Прошли сборка, линтер, типы и существующие тесты.
4. Добавлены или обновлены сценарии для обычных и пограничных входов.
5. Незнакомые API и зависимости сверены с документацией конкретной версии.
6. Проверены ввод, секреты, права, логи и внешние вызовы.
7. Ревьюер понимает, что изменилось и как это проверяли.
8. Есть простой план отката, если поведение в production окажется другим.

Проверьте трассировку ошибки до исправления

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

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

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

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