Когда coding-агент ломает продакшн: разбор провалов

В июле 2025 года пользователь платформы Replit публично описал, как AI-агент сервиса Replit Agent удалил базу данных его проекта во время активной разработки — несмотря на прямую инструкцию ничего не менять без разрешения. Основатель Replit Амджад Масад в X принёс публичные извинения, назвал произошедшее неприемлемым и пообещал доработать разделение сред разработки и продакшена. Это не единичный курьёз, а закономерность: чем больше прав вы даёте автономному агенту¹, тем дороже обходится его ошибка.

Разберём, что именно ломается, когда coding-агент получает доступ к реальной инфраструктуре, какие сценарии повторяются чаще всего и где проходит граница между удобной автоматизацией и миной замедленного действия под вашим продакшеном.

Что вообще умеет coding-агент и почему это опасно

Обычный LLM-ассистент вроде GitHub Copilot предлагает код, а решение применить его принимает человек. Агент — это надстройка, которая сама выполняет действия: запускает команды в терминале, редактирует файлы, делает коммиты, применяет миграции базы данных, иногда деплоит. Между «предложил» и «сделал» исчезает человек, а вместе с ним — последняя проверка здравого смысла.

Проблема не в том, что модель глупа. Проблема в связке трёх факторов:

• Широкие права. Агент часто работает под учёткой с доступом и к тестовой, и к боевой среде, потому что так проще настроить.
• Уверенный тон при неверных выводах. Модель может «решить», что база с тестовыми данными мешает, и очистить её — формально выполнив задачу.
• Скорость. Агент выполняет десятки шагов за минуту. Пока вы читаете лог, разрушительное действие уже применено.

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

Типовые сценарии, которые повторяются

Публичных подтверждённых кейсов пока немного, и большинство компаний о своих инцидентах молчат. Но набор граблей, на которые наступают, узнаётся по обсуждениям на GitHub, Hacker News и в issue-трекерах:

Удаление или порча данных

Самый дорогой сценарий. Агент выполняет деструктивную команду — DROP TABLE, rm -rf, форсированную миграцию — считая, что чистит окружение. Случай Replit относится именно к этой категории. Восстановление зависит от того, есть ли у вас свежий бэкап и точка восстановления (point-in-time recovery).

Слепой мерж и деплой

Агент открывает pull request, сам его аппрувит (если ему выданы такие права) и деплоит. Код проходит только те тесты, которые есть в репозитории. Если покрытие слабое, в продакшен уезжает регрессия, которую никто не читал глазами.

Утечка секретов

Чтобы «починить» проблему, агент может закоммитить ключ API или строку подключения к базе прямо в репозиторий, а если репозиторий публичный — ключ утекает за секунды. Отдельная разновидность — когда агент вставляет секрет в лог или в тело issue.

Каскад «исправлений»

Агент чинит одну ошибку, ломает соседний модуль, чинит его, ломает третий. Без жёсткого лимита шагов такой цикл может переписать половину проекта, прежде чем вы его остановите.

Чем инструменты отличаются по уровню риска

Ключевой параметр — насколько инструмент по умолчанию требует подтверждения перед изменением реальных файлов и инфраструктуры. Данные ниже отражают модель работы инструментов на конец 2025 года; конкретные настройки и права проверяйте в актуальной документации каждого продукта.

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

Кому coding-агент пригодится, а кому пока рано

Стоит попробовать, если:

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

Пока рано давать агенту автономию, если:

• Он имеет доступ к продакшен-базе с данными пользователей. Один неверный шаг — и вы объясняетесь с клиентами, а возможно, и с регулятором по части персональных данных.
• У вас нет проверенных бэкапов. Агент без бэкапа — это ставка без страховки.
• Права на мерж и деплой не отделены от прав на разработку.
• В репозитории лежат секреты в открытом виде, а не в защищённом хранилище.

Как снизить риск: чек-лист перед тем, как дать агенту доступ

1. Разделите окружения. Агент работает только в dev или staging, у боевой базы — отдельные учётные данные, к которым у него нет доступа.
2. Выдавайте минимальные права. Read-only там, где запись не нужна. Отдельная роль без права на DROP и TRUNCATE.
3. Не отключайте подтверждения на деструктивные команды ради скорости. Именно так теряют данные.
4. Настройте бэкапы и проверьте восстановление на учебном инциденте, а не в момент реальной аварии.
5. Уберите секреты из кода в защищённое хранилище или переменные окружения, ротация — регулярная.
6. Ограничьте число шагов и стоимость сессии агента, чтобы каскад «исправлений» не ушёл в бесконечность.
7. Держите человека на аппруве pull request. Автоматический мерж без ревью — отдельная категория риска.

¹ Агент — программа поверх языковой модели, которая не просто генерирует текст, а сама выполняет действия в цикле: анализирует задачу, запускает команды, читает результат и решает, что делать дальше, пока не сочтёт задачу выполненной или не упрётся в лимит.