Это глава 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: что разобрал Гусев и почему это не “плохой промпт”

Кейс выше - первые минуты после инцидента. Через несколько дней Николай Гусев из Группы Астра опубликовал разбор на Хабре (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 - разрыв ассоциации между «правила существуют» и «моё действие нарушает правила». Не «модель ослушалась». Не «alignment problem». А разрыв логической цепочки при сжатии контекста.

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

• Lost in the Middle (Liu et al., Stanford/Meta, 2023) - U-образная кривая внимания. При 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. Звучит логично.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь я перехожу на «я». Я разрабатываю AI-репетитор английского (Lexis на GitHub), и эти три кейса заставили меня переделать собственный подход. Не для красивого 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-инцидента - со стороны бэкап-инфраструктуры («Иллюзия сохранности», Diamant_storage) и со стороны enterprise-control (Agent Gateway в Google Cloud, stnkv-it). Угла dissociation там нет - это, по-моему, центральная вещь.

Источники:

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

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

• Attention Sinks (Xiao et al., ICLR 2024)

• Context Rot (Chroma Research, 2025)

• Effective Context Engineering (Anthropic Blog)

• Lexis: github.com/VDV001/lexis.