Это глава 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.
ссылка на оригинал статьи https://habr.com/ru/articles/1037098/