AI-агент написал код: как понять, что он не сломал проект
AI-агент написал код: как понять, что он не сломал проект
AI-агент может закончить задачу за минуты, но это ещё не значит, что проект работает правильно. Разбираемся, как проверить изменения, найти скрытые ошибки и не пропустить опасный код.
Задача выполнена. Но можно ли верить агенту?
AI-агент меняет несколько файлов, запускает тесты и уверенно сообщает: « Задача выполнена ». Выглядит убедительно. Особенно когда в отчёте написано, что код стал чище, производительность выросла, а все проверки успешно пройдены.
Проблема в том, что агент оценивает результат по доступному ему контексту. Если в проекте нет теста на нужный сценарий, он не узнает, что этот сценарий сломался. Если команда запуска проверок настроена неправильно, зелёная галочка тоже ничего не доказывает.
Фраза «агент закончил работу» означает только то, что он перестал менять файлы. Принимать эти изменения всё равно должен разработчик.
Начните не с отчёта, а с изменений
После завершения задачи хочется прочитать красивое резюме агента и сразу открыть приложение. Я бы не спешил. Сначала нужно увидеть реальный масштаб изменений.
Для этого достаточно нескольких команд:
git status git diff —stat git diff
git status покажет новые и изменённые файлы, git diff —stat — общий объём работы, а обычный git diff позволит пройтись по каждой строке.
Если для небольшой правки агент переписал половину проекта, это уже повод остановиться. Возможно, он действительно провёл полезный рефакторинг. Но чаще лишние изменения лишь увеличивают область, в которой может скрываться ошибка.
Отдельно проверите, не появились ли случайные файлы: временные логи, собранный проект, локальные настройки, ключи или новый файл .env. Агент может создать их для выполнения задачи и не понять, что добавлять такое в репозиторий нельзя.
Diff важнее объяснения
Отчёт агента — пересказ его собственных действий. Это полезная подсказка, но не доказательство правильности кода. Истина находится в diff.
При просмотре изменений стоит задавать простые вопросы. Зачем изменена эта функция? Почему удалена проверка? Не поменялся ли формат ответа API? Что произойдёт, если значение окажется пустым? Если на какой-то вопрос нет понятного ответа, участок лучше проверить отдельно.
Особенно внимательно я отношусь к коду, который выглядит слишком аккуратно. Агент может сократить десять строк до трёх, одновременно убрав обработку редкого, но важного случая. Визуально решение стало красивее, а фактически — менее надёжным.
Запускайте проверки самостоятельно
Агент мог написать, что тесты пройдены. Всё равно запустите их ещё раз в своём терминале. Так вы увидите настоящую команду, полный вывод и предупреждения, которые могли не попасть в итоговый отчёт.
npm run lint npm run typecheck npm test npm run build
Названия команд зависят от проекта, но смысл один: отдельно проверить стиль кода, типы, тесты и production-сборку. Успешный запуск приложения в режиме разработки не гарантирует, что оно соберётся для публикации.
Нельзя забывать и о старых тестах. Агент нередко добавляет новый тест под собственную реализацию, но случайно ломает существующий функционал в соседнем модуле. Поэтому запускать нужно весь доступный набор проверок, а не только созданный им файл.
Тест должен проверять поведение, а не код агента
Сгенерированный тест иногда повторяет внутреннюю логику функции. Такой тест проходит, но почти ничего не защищает: ошибка может находиться одновременно и в реализации, и в проверке.
Хороший тест начинается с ожидаемого поведения. Пользователь отправил пустую форму — увидел сообщение об ошибке. Товар закончился — оформить заказ нельзя. API вернул 401 — приложение запросило повторный вход, а не показало бесконечную загрузку.
Полезно вручную изменить условие или вернуть заведомо неправильное значение. Если тест после этого остаётся зелёным, он проверяет не то, что нужно. Подобная короткая проверка часто говорит о качестве тестов больше, чем их количество.
Проверьте обычный сценарий руками
Автоматические тесты не видят всего. После них стоит запустить проект и пройти путь, ради которого вносились изменения.
Если агент переделывал форму регистрации, нужно действительно создать пользователя. Если исправлял корзину — добавить товар, изменить количество и оформить заказ. Если работал с адаптивной вёрсткой — открыть страницу хотя бы на нескольких размерах экрана.
Здесь легко обнаруживаются мелочи, которые не попали в техническое задание: кнопка уехала, индикатор загрузки не исчезает, сообщение об ошибке непонятно человеку, а после обновления страницы состояние теряется. Формально функция существует. Пользоваться ею неудобно.
Зависимости, настройки и база данных
Некоторые изменения выглядят безобидно, пока проект не попадает на другой компьютер или сервер. Агент мог подключить новую библиотеку, рассчитывать на локальную переменную окружения либо изменить структуру базы данных.
Если поменялся файл зависимостей, проверьте, действительно ли новый пакет нужен. Небольшая функция не всегда оправдывает библиотеку с десятками вложенных зависимостей. Заодно посмотрите на её поддержку, лицензию и известные уязвимости.
Миграции базы данных требуют ещё больше внимания. Важно понимать, можно ли применить их к таблице с реальными данными и существует ли безопасный путь отката. Команда вроде DROP COLUMN должна привлекать внимание сразу, даже если агент называет её «небольшим обновлением схемы».
Проверьте и конфигурацию. Новые переменные окружения должны быть описаны в документации или в файле-примере, но их реальные значения не должны попадать в Git.
Безопасность агент проверяет не всегда
Код может работать правильно и при этом оставаться опасным. Чаще всего проблемы появляются рядом с авторизацией, загрузкой файлов, SQL-запросами, обработкой HTML и доступом к чужим данным.
Например, недостаточно проверить, что пользователь вошёл в систему. Нужно убедиться, что он имеет право редактировать конкретную запись. Проверка только на frontend тоже не считается защитой: запрос легко отправить напрямую.
Насторожить должны отключённая валидация, ручная склейка SQL-запросов, вставка пользовательского текста через innerHTML, слишком широкие правила CORS и вывод секретных данных в лог. Всё это может пройти тесты и никак не мешать демонстрации проекта.
Не просите того же агента поставить себе оценку
Можно отправить агенту команду «проверь свой код на ошибки», но рассчитывать только на такую проверку рискованно. Модель уже выбрала определённое решение и часто продолжает защищать ту же логику.
Гораздо полезнее дать ей конкретную роль: найти способы сломать функцию, проверить граничные значения, поискать проблемы безопасности или сравнить реализацию с исходными требованиями. Ещё лучше — провести отдельную проверку в новом контексте, где нет длинной истории разработки.
Но и такой review остаётся дополнительным фильтром. Ответственность нельзя передать следующему запросу к нейросети.
Когда работу можно принимать?
Изменения можно считать готовыми, когда вы понимаете, зачем изменён каждый важный файл, проект собирается без новых ошибок, тесты проверяют реальное поведение, а основной пользовательский сценарий пройден вручную.
При этом в репозитории не должно быть секретов и случайных файлов. Новые зависимости должны иметь понятную причину, миграции — безопасный сценарий применения, а изменения API — не ломать старых клиентов.
Если проверить всё за разумное время невозможно, лучше уменьшить задачу. Небольшие изменения проще читать, тестировать и откатывать. Огромный коммит на несколько тысяч строк, созданный за пять минут, не становится безопасным только потому, что был создан быстро.
Курс изучения Python
Можете пройти наш бесплатный курс по изучению Python
Агент ускоряет написание кода, но не отменяет разработчика
AI-агенты хорошо снимают рутинную работу: находят нужные файлы, создают заготовки, обновляют тесты и проводят однотипный рефакторинг. На таких задачах экономия времени действительно заметна.
Но скорость генерации кода и качество готового продукта — разные вещи. Чем быстрее появляется код, тем важнее становится умение читать изменения, замечать побочные эффекты и задавать неудобные вопросы.
Поэтому главный навык при работе с агентами звучит довольно приземлённо: не верить отчёту, пока не проверен результат. Это не недоверие к технологии. Это обычная инженерная работа.
Оцените материал:
