Код от ассистента выглядит аккуратно, и это главная ловушка: глаз доверяет ровному форматированию и уверенным комментариям. Правило простое: за код отвечает тот, кто его коммитит, а не модель. Проверяем так же строго, как код незнакомого коллеги, а иногда строже.
Порядок проверки
- Прочитать дифф целиком. Не только новую функцию, но и что ещё тронуто: импорты, конфиги, удалённые строки.
- Понять каждую строку. Если не можете объяснить, зачем строка, не коммитьте её.
- Запустить. Сборка, линтер, типы, тесты. Код, который не запускался, не проверен.
- Проверить краевые случаи. Пустой ввод, null, очень большие значения, повторный вызов, конкурентный доступ.
- Пройтись по безопасности. Ввод пользователя, SQL, пути к файлам, права, секреты.
Типовые ошибки ИИ
Выдуманные API. Метод или опция, которых нет в библиотеке. Типы и компилятор ловят часть, в динамических языках ошибка всплывёт только при запуске нужной ветки.
Выдуманные пакеты. Ассистент может предложить установить пакет с правдоподобным именем, которого не существует. Злоумышленники регистрируют такие имена в публичных реестрах заранее и кладут туда вредоносный код. Перед установкой проверяйте, что пакет реально существует, популярен и это именно тот, что нужен.
Устаревшие версии. Код по API старой мажорной версии, устаревшие функции, давно исправленные уязвимые зависимости. Сверяйтесь с документацией той версии, что стоит в проекте.
Пропущенные краевые случаи. Счастливый путь написан хорошо, а пустой массив, деление на ноль, часовые пояса и отмена запроса забыты.
Тихое проглатывание ошибок. catch с пустым телом или return null вместо понятной ошибки. Код «работает», пока не сломается незаметно.
Уязвимости. Конкатенация SQL, eval, отключённая проверка TLS «для простоты», секрет прямо в коде, отсутствие проверки прав, путь к файлу из ввода без нормализации.
Лишнее. Новая зависимость ради одной функции, дублирование существующего хелпера, изменения в файлах, которые не просили трогать.
Инструменты помогают
- Типы и компилятор ловят выдуманные методы и несовпадение сигнатур.
- Линтеры находят неиспользуемое, опасные конструкции, пустые catch.
- Статический анализ безопасности (SAST) и проверка зависимостей находят известные уязвимые паттерны и пакеты.
- Сканеры секретов в pre-commit и CI не пропускают ключи в репозиторий.
- Тесты проверяют поведение, а не вид кода.
Инструменты не заменяют чтение: логическую ошибку в бизнес-правиле линтер не увидит.
Ревью маленькими порциями
Большой дифф проверяется плохо: внимание падает, и ошибки проскакивают. Просите ассистента делать изменения шагами, коммитьте каждый проверенный шаг. Так легче откатиться и легче понять, где сломалось.
Не просите модель проверить саму себя вместо вас
Попросить ассистента поискать ошибки в его же коде полезно: он иногда находит забытый краевой случай. Но это дополнение, а не проверка. Модель может так же уверенно подтвердить неверное решение. Финальное слово за запуском, тестами и вашим пониманием.
Лицензии и происхождение кода
Иногда ассистент воспроизводит крупный фрагмент чужого кода почти дословно. Если исходник под копилефт-лицензией, у компании могут появиться обязательства. Крупные подозрительно «знакомые» куски лучше заменить своим решением или официально подключить библиотеку. Многие инструменты умеют фильтровать совпадения с публичным кодом, эту настройку стоит включать.
Чек-лист перед коммитом
[ ] Прочитал весь дифф и могу объяснить каждую строку
[ ] Сборка, типы, линтер, тесты зелёные
[ ] Краевые случаи: пусто, null, граница, ошибка сети
[ ] Нет новых пакетов без проверки, нет секретов
[ ] Ввод пользователя валидируется, SQL параметризован
[ ] Ошибки не проглатываются молча
Как это звучит на собесе
«Сгенерированный код для меня как PR от нового коллеги: читаю весь дифф, запускаю тесты, проверяю краевые случаи и безопасность. Особенно слежу за выдуманными методами и пакетами и за версиями библиотек».