Автономный агент чинит прод: где грань доверия

Осенью 2024 года GitHub показал Copilot Workspace, а весной 2025 — Copilot coding agent, который получает задачу из issue, сам создаёт ветку, пишет код и открывает пул-реквест. Anthropic выпустила Claude Code — терминальный агент, который читает репозиторий, запускает тесты и коммитит. У OpenAI появился Codex в виде облачного агента, работающего в изолированной среде. Итог: инструмент, который ещё год назад дописывал строчку за вас, теперь готов взять инцидент и предложить готовое исправление. Вопрос сместился с «умеет ли он» на «пустите ли вы его к боевой ветке в три часа ночи».

Что такое агент в контексте разработки

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

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

Что агент делает хорошо

На типовых, воспроизводимых поломках агенты действительно экономят время. Сценарии, где они показывают себя лучше всего:

• Регрессия с понятным стектрейсом. Есть исключение, есть строка, есть тест, который его ловит. Агент читает трейс, находит место, чинит, гоняет тест.
• Обновление зависимости, ломающее сборку. Переименовали метод в библиотеке — агент проходит по всем вызовам и правит их пачкой.
• Восстановление по failing-тесту. Если у вас есть тест, который падает и точно описывает ожидаемое поведение, агенту есть от чего оттолкнуться.
• Рутинный откат конфига или фиче-флага — там, где изменение локально и обратимо.

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

Где агент ломается

Проблемы начинаются, когда пропадает хотя бы одно из этих условий. Хотфикс редко приходит с готовым падающим тестом — чаще это «упали метрики», «клиент не может оплатить», «нагрузка выросла и всё легло». Здесь агент сталкивается с тем, чего не видит: состоянием боевой базы, поведением под нагрузкой, гонками, которые не воспроизводятся локально.

Агент чинит то, что может проверить. Инцидент в проде часто про то, что проверить локально нельзя — и именно поэтому он и стал инцидентом.

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

Сравнение популярных агентов

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

Разница между ними для хотфикса не столько в «уме», сколько в модели доверия: где агент запускается (ваша машина против чужого облака), спрашивает ли разрешения перед выполнением команд и куда попадает результат — сразу в ветку или в черновик на ревью. Точные названия режимов и лимиты уточняйте в документации каждого продукта, они обновляются часто.

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

Пригодится

• Командам с сильным CI и большим покрытием тестами. Если падение теста надёжно ловит поломку, агент работает в понятных рамках, а не наугад.
• Проектам, где деплой обратим за минуту. Feature flags, быстрый откат релиза, blue-green — цена ошибки агента снижается до цены отката.
• На этапе триажа. Даже если фикс вы катите руками, агент за минуту соберёт контекст: где упало, что менялось последним, какой коммит подозрительный.

Не пригодится

• Там, где нет тестов и нет стейджинга. Агенту не на что опереться, а вы не сможете проверить его работу быстрее, чем сделали бы сами.
• Для необратимых операций: миграции с удалением данных, платёжные транзакции, изменения, которые нельзя откатить одной командой.
• В зонах со строгим комплаенсом, где каждое изменение в проде требует поимённого согласования человека и запись «патч предложил агент» юридически никого не устроит.

Как пустить агента к проду и не сжечь его

Практический минимум ограничителей, если вы всё же хотите включить агента в процесс инцидента:

1. Никакого прямого доступа к боевой ветке. Результат агента — черновик PR, а не коммит в main. Merge делает человек.
2. Агент работает в песочнице, а не на машине с боевыми ключами и доступом к продовой базе.
3. Обязательный failing-тест или воспроизведение перед тем, как агент начнёт чинить. Нет проверки — нет автономного фикса.
4. Человек-ревьюер на инциденте, который читает патч глазами и понимает причину, а не только зелёный CI.
5. Явный список запрещённых действий: миграции, удаление, работа с платежами и секретами — только руками.

Смысл простой: агент ускоряет путь от «что-то сломалось» до «вот кандидат на фикс», но кнопку в бою нажимает человек. На середину 2025 года это разумная граница доверия — не потому что модели глупы, а потому что цена их уверенной ошибки в проде всё ещё выше, чем экономия от полной автономии.

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