Дефицит доверия к коду ИИ: 0% уверенности

Индустрия программного обеспечения спешно пишет код с помощью искусственного интеллекта. И при этом испытывает огромные трудности с тем, чтобы этот код работал стабильно после выпуска в продакшен.

Опрос 200 руководителей высшего звена по надежности сайтов и DevOps в крупных компаниях США, Великобритании и Европейского союза обрисовывает мрачную картину скрытых издержек, заложенных в бум ИИ-программирования. Согласно отчету Lightrun State of AI-Powered Engineering за 2026 год, предоставленному изданию VentureBeat эксклюзивно до его официального релиза, 43% изменений в коде, сгенерированном ИИ, требуют ручной отладки в производственных средах даже после прохождения контроля качества и промежуточного тестирования. Ни один респондент не заявил, что его организация может проверить предложенное ИИ исправление всего за один цикл повторного развертывания; 88% сообщили, что им требуется от двух до трех циклов, а 11% — от четырех до шести.

Эти выводы появились в момент, когда созданный ИИ код распространяется по глобальным предприятиям с поразительной скоростью. И генеральный директор Microsoft Сатья Наделла, и генеральный директор Google Сундар Пичаи заявляли, что около четверти кода их компаний теперь генерируется ИИ. Объем рынка AIOps — экосистемы платформ и сервисов, предназначенных для управления и мониторинга этих процессов на базе ИИ, — в 2026 году составляет $18,95 млрд и, по прогнозам, достигнет $37,79 млрд к 2031 году.

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

«Цифра в 0% сигнализирует о том, что разработка сталкивается со стеной недоверия при внедрении ИИ», — заявил Ор Маймон (Or Maimon), коммерческий директор Lightrun, комментируя результат опроса, согласно которому ноль процентов руководителей инженерных отделов охарактеризовали себя как «весьма уверенных» в том, что код, сгенерированный ИИ, будет вести себя корректно после развертывания. «Хотя упор отрасли на повышение производительности сделал ИИ необходимостью, мы наблюдаем прямой негативный эффект. Попадая в систему, код от ИИ не просто увеличивает объемы — он замедляет весь конвейер развертывания».

Мартовские сбои у Amazon показали, что происходит, когда созданный ИИ код выпускается без защитных механизмов

Эти опасности больше не носят теоретический характер. В начале марта 2026 года компания Amazon столкнулась с чередой громких сбоев, которые в точности продемонстрировали тот тип сбоев, который описывается в отчете Lightrun. 2 марта на Amazon.com произошел сбой, длившийся почти шесть часов, в результате которого было потеряно 120 000 заказов и зафиксировано 1,6 млн ошибок на сайте. Три дня спустя, 5 марта, торговую площадку поразил более серьезный сбой, продолжавшийся шесть часов и вызвавший падение объемов заказов в США на 99% при приблизительно 6,3 миллиона потерянных заказов. Оба инцидента были связаны с изменениями кода при поддержке ИИ, развернутыми в продакшене без надлежащего одобрения.

Последствия не заставили себя ждать. Amazon инициировала 90-дневную процедуру сброса безопасности кода для 335 критически важных систем, и теперь изменения кода с помощью ИИ должны утверждаться старшими инженерами перед их развертыванием.

Маймон указал непосредственно на инциденты в Amazon. «Эта неопределенность не основана на гипотезе, — сказал он. — Нам достаточно оглянуться на начало марта, когда Amazon.com в Северной Америке вышел из строя из-за внедрения изменения при помощи ИИ без установленных средств защиты».

Инциденты в Amazon иллюстрируют центральное противоречие, которое отчет Lightrun подтверждает данными опроса: инструменты ИИ могут создавать код с беспрецедентной скоростью, но системы, предназначенные для проверки, мониторинга и обеспечения доверия к этому коду в реальных средах, не поспевают за ними. Недавний отчет DORA 2025 года от Google подтверждает эту динамику, показывая, что внедрение ИИ коррелирует с ростом нестабильности кода, а 30% разработчиков заявляют о небольшом доверии к коду от ИИ или его полном отсутствии.

Маймон сослался непосредственно на это исследование: «В отчете DORA компании Google за 2025 год отмечается, что внедрение ИИ коррелирует с почти 10-процентным ростом нестабильности кода. Наши процессы валидации были созданы под масштабы человеческого труда, но сегодня инженеры превратились в аудиторов огромных объемов незнакомого кода».

Разработчики тратят два дня в неделю на отладку чужого кода, сгенерированного ИИ

Одним из самых поразительных выводов отчета является масштаб человеческих ресурсов, расходуемых на задачи верификации, связанные с ИИ. Согласно опросу, разработчики теперь тратят в среднем 38% своей рабочей недели — примерно два полных дня — на отладку, верификацию и устранение неполадок в конкретных средах. Для 88% опрошенных компаний этот «налог на надежность» поглощает от 26% до 50% еженедельного рабочего времени разработчиков.

Это совсем не те дивиденды производительности, на которые рассчитывали руководители предприятий, инвестируя в ИИ-ассистентов для программирования. Вместо этого узел инженерных проблем просто переместился в другое место. Код пишется быстрее, но на подтверждение его работоспособности уходит гораздо больше времени.

«В некотором смысле ИИ усугубил проблему отладки, — считает Маймон. — Объем изменений превосходит возможности ручной проверки, в то время как сам сгенерированный код часто ведет себя не так, как ожидалось при развертывании в продакшене. Агенты кодирования на базе ИИ не видят, как их код ведет себя в работающих средах».

Проблема повторного развертывания усугубляет временные затраты. Каждая опрошенная организация требует нескольких циклов развертывания для проверки всего одного предложенного ИИ исправления — и, согласно отчету DORA 2025 года от Google, один цикл повторного развертывания занимает в среднем от одного дня до недели. В таких регулируемых отраслях, как здравоохранение и финансы, окна для развертывания часто бывают узкими и регулируются обязательными заморозками кода и строгими протоколами управления изменениями. Необходимость трех и более циклов для проверки одного исправления от ИИ может увеличить сроки решения проблем с дней до недель.

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

Инструменты мониторинга ИИ не видят, что происходит внутри работающих приложений — и в этом главная проблема

Если утечка производительности является наиболее заметной издержкой, то в отчете Lightrun утверждается, что более глубокой структурной проблемой является так называемый «пробел видимости во время выполнения» (runtime visibility gap) — неспособность инструментов ИИ и существующих систем мониторинга наблюдать за тем, что на самом деле происходит внутри работающих приложений.

Шестьдесят процентов респондентов опроса назвали отсутствие видимости поведения живых систем основным препятствием при решении инцидентов в продакшене. В 44% случаев, когда ИИ SRE (специалисты по надежности сайтов на базе ИИ) или инструменты мониторинга производительности приложений пытались расследовать проблемы в продакшене, они терпели неудачу, поскольку необходимые данные на уровне выполнения — состояния переменных, использование памяти, поток запросов — вообще не фиксировались.

Отчет рисует картину работы ИИ-инструментов вслепую в наиболее критически важных средах. Девяносто семь процентов руководителей инженерных отделов заявили, что их агенты ИИ SRE работают без достаточной видимости того, что на самом деле происходит в продакшене. Примерно половина всех компаний (49%) сообщили, что их ИИ-агенты имеют лишь ограниченную видимость состояний живого выполнения. Лишь 1% сообщил о широкой видимости, и ни один респондент не заявил о полной видимости.

Именно этот пробел превращает незначительную программную ошибку в дорогостоящий сбой. Когда предложенное ИИ исправление дает сбой в продакшене (а это происходит с 43% из них), инженеры не могут полагаться на свои ИИ-инструменты для диагностики проблемы, поскольку эти инструменты не могут наблюдать за поведением кода в реальном времени. Вместо этого команды возвращаются к тому, что в отчете называется «племенными знаниями» (tribal knowledge): институциональной памяти старших инженеров, которые уже сталкивались с подобными проблемами и могут интуитивно определить первопричину на основе опыта, а не данных. Опрос показал, что 54% резолюций по инцидентам высокой степени тяжести опираются на племенные знания, а не на диагностические свидетельства от ИИ SRE или APM (систем мониторинга производительности).

В финансовом секторе 74% инженерных команд доверяют человеческой интуиции больше, чем диагностике ИИ во время серьезных инцидентов

Дефицит доверия проявляется особенно остро в финансовом секторе. В отрасли, где одна ошибка в приложении может привести к убыткам в миллионы долларов в минуту, опрос показал, что 74% инженерных команд в сфере финансовых услуг полагаются на племенные знания, а не на автоматизированные диагностические данные во время серьезных инцидентов — это значительно выше, чем 44% в технологическом секторе.

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

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

Маймон охарактеризовал это как одно из самых значительных открытий отчета. «Лидеры стремятся внедрять эти новые инструменты ИИ, но они не доверяют ИИ работу с живыми средами, — сказал он. — Отсутствие доверия отражено в данных: у 98% уровень доверия к ИИ, работающему в продакшене, ниже, чем к помощникам в написании кода».

Индустрия наблюдаемости, созданная для человеческой скорости разработки, отстает в эпоху ИИ

Полученные результаты ставят острые вопросы к нынешнему поколению инструментов наблюдаемости от таких крупных вендоров, как Datadog, Dynatrace и Splunk. Семьдесят семь процентов опрошенных руководителей инженерных отделов сообщили о низкой уверенности или ее полном отсутствии в том, что их текущий стек наблюдаемости предоставляет достаточно информации для поддержки автономного анализа первопричин или автоматического устранения инцидентов.

Маймон прямо указал на структурную проблему. «Крупные вендоры часто создают «закрытые» экосистемы, где их ИИ SRE могут анализировать данные, собранные только их собственными проприетарными агентами, — отметил он. — На современном предприятии у команд обычно есть многоинструментальный стек для обеспечения полного покрытия. Заставляя команду замыкаться на одном вендоре, эти инструменты создают неудобную зависимость и стратегическую уязвимость: если у вендора отсутствуют данные по какому-то конкретному слою, ИИ фактически слеп к первопричине».

Вторая проблема, по мнению Маймона, заключается в том, что существующие решения ИИ SRE на базе наблюдаемости предлагают лишь частичную видимость, которая ограничивается тем, что инженеры додумались залогировать в момент развертывания. Поскольку сбои редко идут по заранее определенным путям, автономный анализ первопричин с использованием только этих инструментов часто упускает ключевые диагностические доказательства. «Чтобы двигаться в сторону подлинного автономного устранения последствий, — сказал он, — индустрия должна перейти к ИИ SRE без привязки к конкретному вендору (vendor lock-in); ИИ SRE должны быть активными участниками, способными подключаться ко всему стеку и опрашивать работающий код, чтобы зафиксировать истинное положение дел в момент сбоя».

На вопрос о том, что нужно для формирования доверия к ИИ SRE, респонденты опроса единодушно сошлись на необходимости видимости выполнения в реальном времени (live runtime visibility). 58% заявили, что им необходима возможность получать «трассировки доказательств» переменных в момент сбоя, а 42% отметили возможность проверять предлагаемое исправление до его фактического развертывания. Ни один из респондентов не выбрал способность принимать множественные источники логов или предоставлять более качественные объяснения на естественном языке, что говорит о том, что техническим лидерам не нужен ИИ, который лучше разговаривает — им нужен ИИ, который лучше видит.

Вопрос больше не в том, использовать ли ИИ для кодирования, а в том, может ли кто-то доверять тому, что он производит

Опрос был проведен независимой фирмой Global Surveyz Research и собрал мнения директоров, вице-президентов и руководителей высшего звена в ролях SRE и DevOps на предприятиях с 1,5 тыс. и более сотрудниками в сфере финансов, технологий и ИТ. Ответы собирались в январе и феврале 2026 года, вопросы были рандомизированы во избежание предвзятости порядка.

Lightrun, поддерживаемая инвестициями в размере $110 млн от Accel и Insight Partners, среди чьих корпоративных клиентов числятся AT&T, Citi, Microsoft, Salesforce и UnitedHealth Group, имеет очевидный коммерческий интерес к проблеме, описываемой в отчете: компания продает платформу наблюдаемости времени выполнения, призванную предоставить ИИ-агентам и человеческим инженерам видимость выполнения «живого» кода в реальном времени. Ее продукт AI SRE использует подключение по протоколу Model Context Protocol для генерации живых диагностических данных в точке сбоя без необходимости повторного развертывания. Этот коммерческий интерес не умаляет выводов опроса, которые тесно коррелируют с независимыми исследованиями Google DORA и реальными свидетельствами сбоев в Amazon.

В совокупности они описывают отрасль, столкнувшуюся с неудобным парадоксом. ИИ решил самую медленную часть создания программного обеспечения — написание кода, — чтобы затем обнаружить, что написание никогда не было сложной частью. Сложнейшей задачей всегда было понимание того, работает ли это на самом деле. И в этом вопросе инженеры, ближе всех стоящие к проблеме, настроены вовсе не оптимистично.

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

Машины научились писать код. Никто не научил их следить за тем, как он работает.