AI-код нельзя копировать вслепую: 3-шаговый чек-лист приёмки

AI-ассистенты для программирования заметно ускоряют работу, но их вывод нельзя просто скопировать и отправить в продакшен. Статья на w3cschool.cn предлагает практический чек-лист приёмки из трёх шагов, который превращает недоверенный сгенерированный код в пригодный к слиянию. Главная мысль проста: модели умеют уверенно выдумывать несуществующие функции, пропускать обработку ошибок и даже порождать разрушительные команды. Поэтому приёмка — это не недоверие к AI, а обязательная инженерная проверка. Автор советует проходить эти три шага даже ради изменения одной функции: три минуты проверки дешевле, чем ночная отладка после релиза. Первый шаг — сначала пойми, потом доверяй. Прежде чем запускать код, попросите модель объяснить его: что делает каждый фрагмент, какие внешние библиотеки или системные команды он использует. Если модель не может внятно объяснить логику или ссылается на незнакомые интерфейсы, это повод насторожиться. Стоит проверить три вещи: нет ли неопределённых символов (модель часто принимает воображаемый API за настоящий), нет ли побочных эффектов вроде записи файлов, отправки запросов или изменения окружения, и полна ли обработка ошибок — код, работающий только по «счастливому пути», ломается при первом же сбое. Второй шаг — локальный запуск в изоляции. Не экспериментируйте в рабочем каталоге: создайте временный проект или виртуальное окружение, чтобы случайно не изменить существующий код. Проверьте основную логику на минимальных типичных данных, а затем прогоните граничные случаи — пустые значения, очень большие числа, аномальные входные данные. В статье приведены команды для создания окружения и запуска тестов, например pytest, в том числе для отдельного затронутого файла. Полученный результат стоит сравнить с ожидаемым. Отдельно выделена безопасность: модель может сгенерировать «голый» eval, пароли в открытом виде или деструктивные операторы с rm, drop и delete. Для агентов, которые сами выполняют действия и вызывают инструменты, риски выше, поэтому нужны минимальные права и песочница. Третий шаг — ревизия различий. Даже успешно запущенный код не готов к слиянию: посмотрите git diff построчно и убедитесь, что объём изменений совпадает с ожидаемым. Проверьте, не затронуты ли посторонние файлы, не остались ли отладочные print, не появились ли новые сторонние зависимости. В конце прогоните линтер и форматирование, чтобы стиль совпадал с остальным репозиторием. Автор разбирает типичные ошибки новичков: слияние кода только потому, что он «вроде работает», тестирование прямо в продакшене и доверие зависимостям без проверки их источника. В разделе вопросов отмечено, что для мелких правок вроде текста или константы достаточно беглого взгляда на diff, но изменения логики, интерфейсов или зависимостей требуют полного прохождения шагов. Если тестов нет, стоит написать хотя бы минимальный тест на основной сценарий. А уверения модели, что «всё в порядке», не заменяют реальный запуск. Для команды автор советует вынести три шага в шаблон pull request и подключить тесты и линтер к CI.