Прежде чем дать ИИ-агенту доступ к проекту, проверьте эти 10 вещей

Я прочёл обсуждение на Reddit, где пользователь рассказал, что кодинг-агент удалил тысячи файлов вместе с локальной историей Git. Исходный пост уже удалён, независимого подтверждения истории нет. Зато в комментариях разгорелся вполне полезный спор: что именно мы разрешаем программе, когда говорим ей «разберись сама».

Меня зацепила знакомая фраза: «Я же написал, чтобы он ничего не удалял».

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

Я бы проверял следующие вещи до первой задачи.

1. Есть копия, до которой агент не доберётся

Локальный Git помогает откатить изменения, пока сам репозиторий цел. Если удалить папку вместе с .git, история исчезнет вместе с ней.

Нужна отдельная копия: удалённый репозиторий для сохранённого кода и резервная копия для базы, документов, загруженных файлов. Всё, что не попало в коммиты, Git за вас не сохранит.

2. Вы хотя бы раз пробовали восстановление

«У нас настроен бэкап» звучит успокаивающе. Я бы попросил восстановить из него тестовую копию и открыть её.

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

3. Агент работает в отдельной копии проекта

Отдельная ветка удобна для проверки изменений. Но ветка не мешает программе удалить соседние файлы или обратиться к рабочему серверу.

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

4. У тестовой среды свои данные и ключи

Однажды подключённая рабочая база может превратить безобидный тест в настоящий инцидент.

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

5. Вы понимаете, куда ведут ссылки на папки

Символические ссылки и Windows junctions могут вести за пределы каталога, который выглядит изолированным. Скрипт «очистить временную копию» способен затронуть реальные файлы, если неправильно обходит такие ссылки.

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

6. Опасные действия требуют отдельного решения

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

Я бы оставлял подтверждение для таких операций и ограничивал права средствами самой среды. Запись «не удаляй ничего» в файле инструкций полезна, но заменить эти ограничения не сможет.

7. Задача имеет понятный конец

«Приведи проект в порядок» допускает слишком много трактовок.

Лучше: «Исправь проверку телефона в форме заявки. Менять можно эти файлы. Схему базы и зависимости не трогай. Готовность проверяем на этих примерах».

Так проще заметить момент, когда агент начинает решать уже другую задачу. И проще оценить результат.

8. Подключённые сервисы выдают только нужные права

Агент с доступом к CRM может читать карточки, менять сделки, удалять записи или отправлять сообщения. Это совершенно разные полномочия.

Если задача состоит в подготовке отчёта, достаточно чтения. Для записи можно выдать отдельный ограниченный доступ. У каждого подключённого инструмента стоит проверить, что он действительно позволяет сделать.

9. Результат проверяют независимо от отчёта агента

Сообщение «всё работает» приятно читать. После него всё равно стоит открыть список изменений и проверить нужный сценарий.

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

10. Вы знаете, как остановить работу

До запуска полезно понять, где останавливается задача, остаются ли фоновые процессы и как отозвать выданный токен.

Это особенно важно для агентов, которые запускают дополнительные задачи или работают по расписанию. Закрытое окно чата ещё не говорит, что вся работа остановилась.

Для проектов Paladin Engineering я бы включал эти вопросы в обсуждение доступа к автоматизации. Форма, бот или внутренняя система могут выглядеть небольшими, пока не выясняется, что через них доступны клиентские документы и рабочая база.

Мне нравится возможность поручить агенту скучную работу и заняться другим. Но перед этим я хочу знать, что ошибка останется внутри тестовой копии и у меня есть способ вернуть всё назад.

Короткий чек-лист и шаблон задания для агента можно забрать в моём Telegram