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

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

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

Масштабируйте проверку под риск

Не каждое изменение требует одинакового внимания.

Шаг 1: посмотрите, что изменилось

Прежде чем судить о коде, получите список изменений:

• Если проект в Git, посмотрите diff: файлы и строки, которые изменились с последнего коммита. См. как пользоваться Git с приложением, созданным ИИ.
• Или спросите ИИ напрямую:

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

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

Шаг 2: сначала протестируйте поведение

Чтение кода говорит, что он должен делать; тестирование показывает, что он делает на самом деле. Прежде чем читать:

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

Если тест провалился, вы сэкономили время на чтении — честно сообщите о проблеме и дайте ИИ её исправить. См. как написать хороший баг-репорт.

Шаг 3: проверьте права на сервере

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

Для каждого маршрута или функции, которые читают или меняют данные, спросите:

• Проверяется ли, что пользователь вошёл в систему?
• Проверяется ли, что этому пользователю разрешён доступ к этой записи?
• Эта проверка выполняется на сервере, а не только на странице?

Для каждого API-маршрута, который ты добавил или изменил, скажи, какую проверку прав он делает на сервере, с цитатой строки. Отметь любой маршрут без такой проверки.

Затем протестируйте: войдите как пользователь A, запишите ID записи, войдите как пользователь B и запросите её. Полный тест есть в чек-листе безопасности для приложений, созданных ИИ.

Шаг 4: поищите утёкшие секреты

• Поищите в изменённых файлах всё, что похоже на ключ или пароль.
• Проверьте, что секретные ключи читаются из переменных окружения и используются только в серверном коде.
• Следите за публичными префиксами, такими как VITE_ или NEXT_PUBLIC_, у секретных переменных — они вшиваются в код, который исполняется в браузере.

См. как хранить ключи API в безопасности.

Шаг 5: проверьте входные данные и ошибки

• Проверка на сервере. Проверки в браузере можно обойти. Обязательные поля, длина, форматы и допустимые значения должны проверяться и сервером.
• Запросы к базе используют параметры, а не текст, собранный из пользовательского ввода.
• Ошибки не проглатываются. Блок try/catch, который ничего не делает, скрывает сбои. Ошибки должны записываться в лог, а пользователь видеть понятное сообщение.
• Внутренние детали не показываются пользователям — трассировки стека и ошибки базы данных относятся к логам.

Шаг 6: убедитесь, что это настоящее

Модели ИИ иногда пишут код, который выглядит правильно, но ссылается на несуществующие вещи.

• Пакеты: каждая новая зависимость должна быть настоящим, поддерживаемым пакетом с этим точным именем. Насторожитесь, если название похоже на опечатку популярного пакета.
• Функции и опции API: если код вызывает функцию библиотеки или опцию внешнего API, которых вы не видели, проверьте официальную документацию.
• Заглушки: ищите TODO, mock, fake, зашитые тестовые данные и функции, которые возвращают фиксированное значение.

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

Шаг 7: проверьте, что это вписывается

Код может работать и всё же усложнять приложение для будущих изменений:

• Дублирование. Одна и та же логика, скопированная в несколько мест, со временем расходится.
• Согласованность. Код должен следовать шаблонам, которые использует остальное приложение.
• Объём. Запрос в 20 строк, который породил 600 строк, заслуживает вопроса.
• Мёртвый код. Старые версии, оставленные рядом с новыми.

Есть ли в проекте код, который теперь не используется из-за этого изменения, или логика, которая дублируется в другом месте? Ничего не меняй, просто перечисли.

Частые ошибки

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

Чек-лист

• Я знаю, какие файлы изменились и зачем, и ничего не связанного не поменялось.
• Изменение работает на компьютере и телефоне, с плохими данными, без входа и под другим пользователем.
• Каждый маршрут с данными проверяет вход и принадлежность на сервере.
• Нет секретов в коде и в сборках для браузера.
• Входные данные проверяются на сервере; запросы используют параметры.
• Ошибки записываются в лог, а не проглатываются, и не показываются пользователям в подробностях.
• Новые пакеты настоящие и нужные; не осталось выдуманных функций и заглушек.
• Рискованные изменения были внимательно прочитаны и, где нужно, проверены вторым человеком.

Проверка кода в Mythex

• Режим Ask отвечает на вопросы о коде, не редактируя его, — идеально подходит для запросов «объясни каждое изменение» и «какие маршруты без проверки прав». См. Chat.
• Просмотр кода показывает дерево файлов, редактор и терминал на каждом тарифе (только чтение на Free, редактирование на Pro), чтобы вы могли сами прочитать, что изменилось. См. Code editor.
• /test заставляет агента пройти предпросмотр как пользователь и сообщить о сломанных сценариях.
• Checkpoints позволяют откатить изменение, которое не прошло проверку.

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

Вопросы