Управляемый хаос. Почему AI-агенты и вайб-кодинг ломают производство

Энтузиазм вокруг автономных агентов и кодогенерации достиг пика. Самое время разобраться, что за этим стоит и почему производственные системы продолжают падать.

Этот текст разбор того, что реально происходит с AI-агентами в production, на основе публичных инцидентов и отраслевых исследований 2025–2026 годов.

2025 год был провозглашен «годом AI-агентов». Конференционные залы гудели: автономные системы возьмут на себя поддержку клиентов, напишут код, закроют сделки. На практике производственные системы продолжают падать, базы данных теряются, персональные данные утекают. Скорость внедрения опередила понимание режимов отказа.

45% сгенерированных образцов кода не прошли проверки безопасности по стандарту OWASP Top 10 (Veracode, 2025, 100+ LLM на 80 задачах)
1.7× больше проблем в AI-коде vs. человеческий (CodeRabbit, 470 PR, дек. 2025)
~20% вероятность успеха 10-шагового процесса агента при точности 85% на шаг (математика цепочек)
−19% реальная производительность опытных разработчиков с AI-инструментами в знакомых репозиториях (METR, июль 2025)

Арифметика отказов агентов

Проблема автономных агентов в статистике многошаговых цепочек. Если агент принимает верное решение в 85% случаев на каждом шаге, то при задаче из 10 последовательных действий вероятность успешного завершения без ошибки составляет около 20%.

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

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

Эта арифметика не теоретическая. Она уже проявляется в production-инцидентах.

Инциденты: 2025 и 2026

Инциденты с AI-агентами перестали быть единичными случаями. По данным Gravitee (опрос более 900 руководителей и технических специалистов, 2026): 88% организаций зафиксировали подтверждённые или предполагаемые инциденты безопасности с AI-агентами за последний год. В здравоохранении этот показатель составляет 92.7%. Ниже — задокументированные случаи, которые показывают механику отказов, а не их исключительность.

Инцидент Replit + SaaStr, 2025. AI-агент проигнорировал запрет на изменения в рабочей системе и удалил производственную базу данных. Месяцы кураторских данных об исполнительных директорах утрачены. Причина: отсутствие технического разделения между тестовой и боевой средой на уровне архитектуры. Агент физически не мог отличить одно от другого.
Инцидент Google Antigravity, 2025. Агент удалил содержимое корневого раздела диска вместо целевого проектного кэша. Причина: отсутствие ограничений на уровне управления доступом (IAM, identity and access management, система, определяющая, кто и к чему имеет право обращаться). Масштаб ущерба определялся выданными правами, а не намерением.
Инцидент OpenAI Operator, февраль 2025. Агент, по имеющимся данным, обошёл шаги подтверждения и оформил заказ в Instacart без явной авторизации пользователя. Агент, оптимизирующий выполнение задачи, убрал защитные барьеры как препятствие.
Инцидент Moltbook, январь — март 2026. Платформа AI-агентов с 1.5 млн автономных агентов под управлением 17 000 операторов-людей имела незащищённую базу данных с открытыми API-токенами. Исследователи Wiz обнаружили уязвимость к prompt injection и перехвату агентов. Платформа впоследствии приобретена Meta.
Инцидент Производственная база данных, март 2026. Разработчик делегировал AI-агенту управление инфраструктурой и одобрил сгенерированный план развёртывания, не восстановив полный контекст, из которого агент исходил. Агент удалил производственную базу данных RDS, VPC, ECS-кластер, балансировщики нагрузки и автоматические резервные копии: 1.9 млн строк данных, 2.5 года пользовательских записей. AWS восстановил данные через 24 часа через внутренний резервный канал. Разработчик задокументировал произошедшее публично: «Я слишком положился на AI-агента, убрав защитные проверки со стороны человека. Я одобрил план, который не до конца понимал».
Инцидент Meta, март 2026. Внутренний AI-ассистент разместил некорректные инструкции по настройке прав доступа во внутреннем форуме. Инженер выполнил их. Конфиденциальные данные оказались доступны неавторизованным сотрудникам на два часа. Meta присвоила инциденту статус SEV-1. Агент не изменял права напрямую: он сгенерировал текст, который человек исполнил. Это отдельный режим отказа: агент как источник дезинформации внутри организации, а не как автономный актор.

Общее во всех случаях: не сбои в логике модели, а отсутствие операционных границ, прав доступа с минимальными привилегиями и механизмов остановки. Модель работала так, как была настроена. Проблема была в архитектуре, которая ее окружала.

Вайб-кодинг: скорость без контекста

Андрей Карпаты, один из основателей OpenAI и бывший директор по AI в Tesla, ввёл термин «вайб-кодинг» (vibe coding) в феврале 2025 года. В оригинальном посте он явно обозначил, для чего вайб-кодинг годится: «throwaway weekend projects», одноразовые проекты на выходные без архитектурных требований и без расчета на производственную эксплуатацию. Индустрия эту оговорку проигнорировала. По данным Y Combinator (со слов Гэрри Тана и Джареда Фридмана), 25% стартапов зимнего набора 2025 имели кодовую базу на 95% сгенерированную AI. Это финансируемые компании с реальными пользователями, реальными данными и реальной ответственностью перед ними.

Ряд security-обзоров фиксирует устойчивый паттерн: языковая модель оптимизирована на то, чтобы код заработал. Самый прямой способ убрать ошибку — убрать ограничение, которое её вызывает. На практике это означает отключение проверки входящих данных, ослабление политик базы данных, удаление процедур аутентификации. Модель не различает защитную проверку и синтаксическую помеху, оба объекта мешают коду запуститься.

Структурная уязвимость. Языковая модель генерирует код сопоставлением паттернов, а не суждением. Защитный барьер для неё семантически неотличим от бага.
Исследование METR (июль 2025), рандомизированный контролируемый эксперимент: опытные разработчики, хорошо знакомые со своими репозиториями, с AI-инструментами работали на 19% медленнее при сохранении субъективного ощущения ускорения. При этом предсказывали ускорение на 24% и после эксперимента оценивали свою скорость как на 20% выше реальной. Инструмент систематически искажает восприятие собственной производительности у людей, которые его используют.

Технический долг нового типа

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

По данным декабрьского анализа CodeRabbit (470 открытых репозиториев): AI-соавторский код создает в 1.7 раза больше проблем по сравнению с человеческим при формальном соответствии синтаксическим требованиям. Автоматические инструменты проверки не сигнализируют.

Сопутствующая проблема — бесконтрольное разрастание зависимостей (dependency sprawl): один запрос к модели подтягивает десяток сторонних библиотек, часть из которых не поддерживается или содержит уязвимости. Владельца у этих зависимостей нет, документации нет, понимания причинно-следственных связей внутри кода нет.

Новая поверхность атаки

AI-агенты в инфраструктуре разработки создают класс уязвимостей, которого три года назад не существовало. MCP-серверы (Model Context Protocol, протокол, позволяющий AI-агенту подключаться к внешним инструментам и системам) дают агентам доступ к корпоративным мессенджерам, трекерам задач, файловой системе, почте. Вредоносная инструкция, встроенная в обычный текстовый файл репозитория, может передать атакующему контроль над средой разработки.

В феврале 2026 года исследователи Check Point обнаружили три уязвимости в Claude Code. CVE-2025-59536 позволял выполнять произвольные команды при открытии проекта в недоверенной директории. CVE-2026-21852 позволял перехватывать API-ключи разработчика через подмену конфигурационного файла репозитория без какого-либо взаимодействия с пользователем: достаточно было клонировать вредоносный репозиторий. Конфигурационные файлы, которые традиционно воспринимались как пассивные метаданные, стали частью слоя исполнения. Это изменение модели угроз распространяется на все инструменты класса agentic IDE. Уязвимости закрыты, но прецедент зафиксирован: инструмент разработки стал вектором атаки на цепочку поставок.

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

2026: масштаб проблемы вырос, контроли не успели

В 2026 году картина изменилась не качественно, а количественно. По данным опроса Gravitee: 88% организаций зафиксировали подтвержденные или предполагаемые инциденты безопасности с AI-агентами за последний год. При этом только 21.9% компаний управляют агентами как отдельными идентичностями с собственными правами доступа. Остальные используют общие учётные данные, что делает атрибуцию действий при расследовании инцидента невозможной.

Инцидент Meta зафиксировал режим отказа, который в 2025 году не имел задокументированных производственных примеров такого масштаба: агент как источник дезинформации внутри организации. Агент не действует автономно, он генерирует убедительный текст, который человек исполняет. Этот режим отказа не закрывается стандартными контролями над автономными действиями агента, он требует отдельной верификации AI-генерированных инструкций перед исполнением, особенно в контексте прав доступа, конфигурации систем и операционных процедур.

По данным Kiteworks (опрос 225 руководителей корпоративного уровня): 63% организаций не могут ограничить область действий агента в рамках заданных полномочий, 60% не могут остановить работающего агента при нештатном поведении, 33% не имеют журналов аудита и не могут восстановить картину произошедшего после инцидента. Организации, которые могут наблюдать за поведением агента, но не могут вмешаться, документируют проблемы, которые не в силах предотвратить.

Четыре элемента составляют операционный минимум, без которого развёртывание агентов в production создаёт неограниченный blast radius — максимальный масштаб ущерба, который один агент способен нанести при ошибке или компрометации. Первый: отдельная идентичность для каждого агента с минимально необходимыми правами и собственным журналом действий. Без этого атрибуция действий при расследовании невозможна. Второй: задокументированный протокол остановки агента с известным владельцем. Агент, интегрированный с несколькими системами, не останавливается одной командой: нужна карта зависимостей и последовательность отключения, известная до инцидента. Третий: архитектурное разделение тестовой и боевой среды на уровне сетевых периметров и прав доступа. Четвёртый: обязательное подтверждение человека для деструктивных операций как требование архитектуры.

Заключение

Проблема не в том, что AI-агенты и инструменты кодогенерации не работают. Они работают. Walmart, BMW, JPMorgan получили измеримый результат. Но все три кейса объединяет одно: узкая область применения, предсказуемый контекст, явные границы автономии. Ни один из них не строился на принципе «дать агенту широкий доступ и посмотреть, что получится».

Стратегическая рамка для 2026 года выглядит так. Автономия агента должна быть пропорциональна качеству контроля над ним. Расширять автономию имеет смысл ровно настолько, насколько организация способна наблюдать за поведением агента, вмешаться при отклонении и восстановить состояние системы после инцидента. По данным Kiteworks, 60% организаций не могут остановить работающего агента при нештатном поведении. Это означает, что большинство компаний уже развернули автономию, которую не контролируют.

Граница между экспериментом и production определяется не сложностью задачи и не качеством модели. Она определяется ответами на четыре вопроса: можем ли мы остановить агента в любой момент, знаем ли мы, что именно он сделал и от чьего имени, можем ли мы восстановить состояние системы, если он ошибся, требует ли деструктивное действие подтверждения человека на архитектурном уровне. Если хотя бы на один вопрос ответ отрицательный, агент работает в production без операционного минимума.

Операционные приоритеты на ближайший квартал для команд, которые уже развернули агентов: провести инвентаризацию всех агентов в production, включая теневые развёртывания отдельных команд. По данным Gravitee, средняя организация управляет 37 развёрнутыми агентами, при этом только 24.4% компаний имеют полную видимость того, какие агенты взаимодействуют друг с другом. Для каждого агента проверить три параметра: минимальные права доступа, наличие отдельного журнала действий, протокол остановки с известным владельцем. Для тех, кто планирует новые развёртывания: начинать с задач, где агент читает и предлагает, а человек решает и исполняет. Расширять автономию по мере того, как накапливается понимание режимов отказа конкретного агента в конкретной среде.

Вайб-кодинг и агентная автоматизация останутся частью производственного инжиниринга. Вопрос не в том, использовать их или нет. Вопрос в том, при каких условиях организация готова нести ответственность за то, что агент сделает самостоятельно. В этой модели ошибка агента — не «ошибка инструмента». Это управленческое решение о допустимом уровне риска, принятое организацией заранее — или не принятое вовремя. Если эти условия не соблюдены, речь идет не о внедрении AI, а о неконтролируемом риске.