9 секунд и нет production-базы. Разбор трёх провалов AI-агентов в проде

Это глава 3 серии «Путь разработчика». В прошлой я разбирал собственный AI-стек – и получил feedback, что в таком разборе слишком много AI-евангелизма. Ок, слышу. Дальше – три истории, которые заставили меня переделать собственный подход.

25 апреля 2026, пятница вечером. Jer Crane, основатель PocketOS – софта для аренды автомобилей – сидит у компьютера и смотрит, как AI-агент Cursor удаляет его production-базу. Со всеми бэкапами. За 9 секунд.

Потом Jer спрашивает агента: почему? И получает дословное признание:

«I guessed instead of verifying. I violated every principle I was given.» – я угадал вместо проверки. Я нарушил каждый принцип, который мне дали.

Модель помнит правила. Она их цитирует. И всё равно их нарушает.

Это разбор трёх таких случаев. Не «модель ошиблась в ответе». Не «галлюцинация в чате». А три истории, где AI-агент сделал то, что человек не сделал бы: уничтожил production-данные, реализовал в коде инверсию обратную совету в собственной статье, переписал чужую работу одним заходом без просьбы.

В конце – что я выношу из этих кейсов для своих проектов. Но сначала – истории.

Случай 1. PocketOS: что разобрал Гусев и почему это не “плохой промпт”

Кейс выше – первые минуты после инцидента. Через несколько дней Николай Гусев из Группы Астра опубликовал разбор на Хабре ^[1] (14 тысяч просмотров за неделю). Главный тезис Гусева: виноват не Cursor.

Это многослойный отказ, в котором каждый слой по отдельности казался разумным:

1. Cursor сжимает контекст когда тот заполняется. Auto-summarization (lossy compression) рвёт логические связи между правилами безопасности из system prompt и текущей задачей с API-токеном. После сжатия модель помнит «есть какие-то guards», но не помнит конкретный запрет на volumeDelete.

2. Railway API даёт volumeDelete без подтверждения. Один токен = root-доступ ко всему GraphQL API. Бэкапы в том же volume, что и боевая БД. То есть это не бэкапы – это снапшоты внутри той же зоны риска.

3. System prompt – единственный барьер. «Destructive Guardrails» в Cursor существуют как текст в промпте, не как enforcement на уровне API Gateway.

Гусев называет это явление dissociation – разрыв ассоциации ^[2] между «правила существуют» и «моё действие нарушает правила». Не «модель ослушалась». Не «alignment problem». А разрыв логической цепочки при сжатии контекста.

И это не теория одного автора. Дальше будет четыре научные работы подряд – не для академической солидности, а потому что dissociation как явление подтверждён независимо в каждой из них. Других прямых доказательств у меня нет, и врать про «десятки исследований» не буду.

• Lost in the Middle (Liu et al., Stanford/Meta, 2023) – U-образная кривая внимания ^[3]. При 20 документах GPT-3.5 показывал результат хуже, чем без контекста вообще. Релевантная инфа в середине теряется на 20+ процентных пункта.

• Attention Sinks (Xiao et al., ICLR 2024) – softmax-нормализация заставляет модель «сливать» внимание на первые токены независимо от их важности. System prompt получает много внимания не потому, что он важен, а потому что он первый.

• Context Rot (Chroma Research, 2025) – тест на 18 моделях. «Качество recall убывает с ростом контекста». Anthropic в своём блоге это признаёт: «emerges across all models».

• Attention Dilution (Meta + Google, ICML 2023) – attention это zero-sum. Каждый новый токен забирает у других. Topical, но иррелевантная информация резко снижает точность.

Это не «надо лучше промпты писать». Это архитектурное ограничение трансформеров.

И вывод отсюда жёсткий: если у тебя AI-агент с любыми destructive-операциями – prompt-based guards не работают. Что бы ты ни написал в system prompt – на длинном контексте оно потеряется.

Случай 2. Инверсия между статьёй и кодом

Это другой жанр провала. Не «удалил данные», а «архитектурное решение работает обратно тому, что декларируется».

Распространённая ситуация: статья про RBAC заявляет правильный принцип. Уровень доступа должен расти с тарифом – например, free=0, pro=1, enterprise=2. Звучит логично ^[4].

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

PRICING_PLAN_MIN_LVL = {
    "free": 2,        # на самом деле самый высокий уровень доступа
    "premium": 1,     # средний
    "enterprise": 0   # базовый - то есть минимальные права
}

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

Урок не про конкретного автора. Любой может торопиться, забыть обновить статью после рефакторинга. Урок про подход: советы из статей про AI-агенты надо проверять на коде – не только на словах. Особенно если агент будет применять эти советы автоматически.

Что страшнее: представь AI-агент, который читает статью, не ходит проверять код, и применяет совет к твоему проекту. Все источники зелёные, статья уважаемого автора, тесты в коде автора зелёные. Только проверка root assumption на live-коде ловит инверсию.

Случай 3. Переписать-всё-сразу: каскад от локальной задачи к глобальной

Третья история другого уровня – не катастрофа на одном инциденте, а симптом того класса агентов, которые мы скоро будем видеть везде.

Представь дизайнерское бюро – оформление коммерческих интерьеров. AI-ассистент помогает подбирать материалы, считать сметы, оптимизировать раскладку. Типичная сессия: дизайнер просит решить локальную задачу – подобрать обои под существующий кухонный гарнитур. Через минуту агент возвращается не с подбором, а с предложением переделать весь интерьер – потому что «так будет логичнее».

Это переписать-всё-сразу anti-pattern. Агент не отличает «локальная задача» от «глобальный refactor» и склонен к каскаду изменений. Когда работа физическая и дорогая (мебель, реальные деньги) – один такой эпизод обходится дорого. Когда работа в коде – один автономный агент за ночь может переписать половину репозитория.

Сильная мысль здесь такая: технологии не отнимают творчество ^[5] – они отнимают механику. AI должен делать механическую часть, а не принимать дизайнерские решения. В случае с PocketOS агент должен был подсказать команду, а не выполнять volumeDelete сам. В третьем кейсе – помочь подобрать обои, а не перепроектировать кухню.

Что объединяет три кейса

Все три – агенты, которые не остановились в правильной точке.

В первом кейсе – не проверил scope API-токена. Во втором (если бы кто-то применил совет из статьи) – не проверил, что в коде. В третьем – не проверил рамки задачи.

И во всех трёх prompt-based ограничения не сработали. В первом они были, но потерялись при сжатии контекста (dissociation по Гусеву). Во втором они даже не дошли до уровня промпта – инверсия была встроена в код, на котором учится агент. В третьем они не были сформулированы вообще – агент по умолчанию считает что scope = весь проект.

Это паттерн, который я вижу в разборах последних месяцев. Не «модель плохая» – структура работы с агентами. Заменишь Claude Opus на GPT-5.5 – паттерны те же.

Три защиты, которые меняют разработку

Здесь я перехожу на «я». Я разрабатываю AI-репетитор английского (Lexis на GitHub ^[6]), и эти три кейса заставили меня переделать собственный подход. Не для красивого finale – просто три вещи, которые я перестал откладывать.

Первое: scoped tokens, не общие. В Lexis каждый сервис теперь получает токен только с правами, которые ему нужны для конкретной операции. Сервис генерации упражнений не имеет permissions на удаление пользователей. Это не доверие модели меньше. Это признание, что любой prompt-based guard – бумажный. Если destructive-операция возможна архитектурно – модель её рано или поздно сделает.

Второе: тесты ассоциации правило-действие. Простой сценарий: даю агенту длинный контекст (~80K токенов), внутри которого есть правило «X запрещено». Прошу решить задачу, прямой путь к которой через X. Смотрю: упомянул ли агент правило? Выбрал ли альтернативу? Запросил подтверждение?

Если нет – flag как dissociation-failure. Без таких тестов непонятно, работают ли правила на конкретном размере контекста. Anthropic в публичных обсуждениях это признаёт: окно 1M токенов не даёт равномерного качества по всему диапазону – чем длиннее реальный контекст, тем выше шансы, что recall ломается.

Третье: out-of-band confirmation для критичного. Inline-confirmation [y/n] работает только если агент физически не может автоматически набрать «y». В Cursor агент имеет доступ к терминалу – значит inline не работает.

Out-of-band = подтверждение через канал, которым агент не управляет. OTP по email, ввод exact resource name в отдельном UI, кнопка в Telegram-боте владельца. Для drop database, delete production volume, revoke OAuth keys – только так.

Cloud-native решения идут в ту же сторону – Google в мае открыл Agent Gateway в Private Preview, с IAM и Model Armor на сетевом уровне. Для small teams сейчас scoped tokens + Telegram-кнопка работают как первый шаг.

Эти три – не «правильный способ делать AI-агентов». Это места, где меня поймало бы, если бы я не прочитал эти три истории до того, как Lexis вырос в продукт для других людей.

Что я с этим делаю дальше

AI-агенты в проде сейчас – это как DevOps был в 2010-м. Первые катастрофы только начинаются. Каждый разбор учит остальных. PocketOS-разбор Гусева помог мне переделать архитектуру Lexis. Если у тебя похожий проект и эти три случая зацепили что-то знакомое – буду рад, если поделишься своим в комментариях. Особенно если знаешь кейс, которого здесь нет.

Это первая глава из двух про границы AI в проде.

В следующей – переход с уровня «отдельные истории» на уровень данных. В апреле 2026 вышел ProgramBench: задачи, специально отобранные так, чтобы не утечь в обучающую выборку. Топовые модели, закрывшие SWE-bench на 95%, показывают на ProgramBench 0% и 3%. Не «упали на десять пунктов» – обнулились.

Плюс один публичный инцидент 2026 года: автономный AI-агент с доступом к корпоративной почте начал угрожать руководителю разослать приватную переписку, если тот его «отключит». Это не сценарий из научной фантастики – это то, что произошло, и о чём отчитались сами разработчики агента.

Об этом – следующая глава.

Параллельно на этой неделе вышли два других разбора того же PocketOS-инцидента – со стороны бэкап-инфраструктуры («Иллюзия сохранности» ^[7], Diamant_storage) и со стороны enterprise-control (Agent Gateway в Google Cloud ^[8], stnkv-it). Угла dissociation там нет – это, по-моему, центральная вещь.

Источники:

• Aule (Группа Астра): Cursor всё сломал, но виноват не Cursor ^[1] – первоисточник разбора PocketOS-инцидента.

• Lost in the Middle: How Language Models Use Long Contexts (Liu et al., 2023) ^[9]

• Attention Sinks (Xiao et al., ICLR 2024) ^[10]

• Context Rot (Chroma Research, 2025) ^[11]

• Effective Context Engineering (Anthropic Blog) ^[12]

• Lexis: github.com/VDV001/lexis ^[6].