Это глава 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.
Это многослойный отказ, в котором каждый слой по отдельности казался разумным:
-
Cursor сжимает контекст когда тот заполняется. Auto-summarization (lossy compression) рвёт логические связи между правилами безопасности из system prompt и текущей задачей с API-токеном. После сжатия модель помнит «есть какие-то guards», но не помнит конкретный запрет на
volumeDelete. -
Railway API даёт
volumeDeleteбез подтверждения. Один токен = root-доступ ко всему GraphQL API. Бэкапы в том же volume, что и боевая БД. То есть это не бэкапы – это снапшоты внутри той же зоны риска. -
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)
-
Lexis: github.com/VDV001/lexis.
Автор: vdv007
