У меня на айфоне два календаря: корпоративный, который загружается через отдельный защищённый профиль, и личный Google-календарь. Корпоративный закрыт от прямого доступа, и это создаёт неудобство: когда кто-то смотрит мою доступность, он видит только личный, но не видит рабочие встречи, и наоборот.

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

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

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

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

Важная деталь в этой истории: Cursor по умолчанию прописывает дебаг-режим в код, если его явно попросить об этом, и каждый следующий скрипт уже приходит с этой защитой. LLM следуют командам, которые им дают. Если команда такова: сделать дебаг-режим, прописать явное подтверждение перед деструктивными операциями, не трогать боевые данные без явного разрешения — они это сделают. Проблема в том, что многие об этом не просят.

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

Агент в этом смысле ведёт себя как джуниор в команде. Ему дают задачу, он выполняет её так, как понял. Иногда понял правильно, иногда нет, иногда перемудрил и додумал лишнее. Именно для этого существует code review перед merge в master, именно поэтому джуниор не должен иметь прямого доступа к продакшн-базе. Те же самые соображения применимы к агенту, который пишет и запускает код от вашего имени.

В классической разработке есть понятие сред: dev, staging, production. Код проходит через них последовательно. Никто в здравом уме не отлаживает новый функционал напрямую в продакшне, потому что там живые данные и реальные пользователи. С агентами эту практику почему-то откладывают, хотя агент сам по себе не отличает тестовое окружение от боевого, если ему это явно не объяснить.

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

Я думаю, что количество историй про "агент дропнул базу" будет расти, потому что всё больше людей без технического бэкграунда начинают использовать агентные инструменты. Им не объяснили про практику разделения сред, не рассказали про dry-run. Они просто дают агенту доступ и просят сделать, и агент делает именно то, что ему разрешено, без встроенного инстинкта осторожности.