Инженерные команды генерируют с помощью AI-агентов больше кода, чем когда-либо. Но когда этот код попадает в production, начинаются проблемы.
Интересная штука: дело не обязательно в самом AI-коде. Проблема вот в чём — традиционные инструменты мониторинга просто не справляются с детальными, функция-уровневыми данными, которые нужны агентам, чтобы понять, как код ведёт себя в сложной production-среде. Без такой информации агенты не могут обнаружить проблемы или предложить исправления, которые учитывают реальность production.
Вот с этим вызовом пытается помочь справиться стартап Hud. В среду они запускают свой runtime-сенсор — инструмент, который следит за тем, как каждая функция ведёт себя в production, давая разработчикам реальную картину происходящего.
«Каждая команда, которая разрабатывает software в масштабе, сталкивается с одной фундаментальной проблемой: создавать качественные продукты, которые работают в реальном мире», — рассказал VentureBeat Роее Адлер, генеральный директор и основатель Hud. «В эру AI-ускоренной разработки не знать, как код себя ведёт в production, становится ещё более критичным вызовом».
С чем борются разработчики
Боль-точки, которые чувствуют инженеры, очень похожи во всех компаниях. Мошик Эйлон, технический лидер группы в Monday.com, руководит 130 инженерами и сталкивается с одной и той же фрустрацией с традиционными инструментами мониторинга.
«Когда приходит алёрт, обычно ты начинаешь проверять endpoint с высокой ошибкой или latency, и хочешь увидеть downstream-зависимости», — поделился Эйлон. «Часто это оказывается самым приложением, а дальше — чёрный ящик. Видишь только 80% latency на уровне приложения и всё».
Дальше начинается ручное расследование через кучу инструментов. Смотришь логи. Синхронизируешь временные метки. Пытаешься воссоздать, что делало приложение. Для новых проблем глубоко в большой кодовой базе команды часто просто не имеют нужных данных.
Даниэль Марашлян, CTO и соучредитель Drata, заметил, что его инженеры проводят часы на то, что он назвал «налогом на расследование». «Они связывали generic-алёрт с конкретным владельцем кода, потом рыли логи, чтобы восстановить состояние приложения», — рассказал Марашлян. «Мы хотели избавиться от этого, чтобы команда могла сосредоточиться только на исправлении, а не на поиске проблемы».
Архитектура Drata усугубляет ситуацию. Компания интегрируется с множеством внешних сервисов для автоматизированного соответствия compliance, что создаёт сложные расследования при возникновении проблем. Инженеры отслеживают поведение через огромную кодовую базу, охватывающую модули риска, compliance, интеграции и репортинга.
Марашлян выделил три конкретные проблемы, которые толкнули Drata в сторону runtime-сенсоров. Первая: затраты на переключение контекста.
«Наши данные были разбросаны повсюду, и инженеры становились человеческими мостами между отключенными инструментами», — сказал он.
Вторая проблема: alert fatigue. «Когда у тебя сложная распределённая система, общие каналы оповещений становятся постоянным потоком noise — то, что наша команда называет ‘динь-динь-динь’, который в итоге просто игнорируется», — объяснил Марашлян.
Третий ключевой фактор: необходимость интеграции с AI-стратегией компании.
«AI-агент может написать код, но не может исправить production-баг, если не видит runtime-переменных или root cause», — подчеркнул Марашлян.
Почему традиционные APM-системы не решают проблему
Корпорации давно полагаются на инструменты, известные как Application Performance Monitoring (APM).
При нынешних темпах развития agentic AI и современных workflow разработки и Monday.com, и Drata просто не получали нужной visibility из существующих APM-решений.
«Если я хочу получить такую информацию из Datadog или CoreLogix, мне нужно поглощать тонны логов или spans, и это стоит огромных денег», — заметил Эйлон.
Он отметил, что Monday.com используют очень низкие sampling rates из-за бюджетных ограничений. В результате они часто упускают ровно те данные, которые нужны для отладки.
Традиционные APM-инструменты ещё и требуют предсказательности, а это проблема — разработчик часто просто не знает, что ему неизвестно.
«Традиционная observability требует, чтобы ты заранее знал, что тебе понадобится для отладки», — сказал Марашлян. «Но когда появляется новая проблема, особенно глубоко в большой сложной кодовой базе, нужных данных часто просто нет».
Drata оценили несколько решений в категориях AI site reliability engineering и automated incident response, но не нашли подходящее.
«Большинство инструментов, которые мы смотрели, отлично управляли процессом инцидента, маршрутизировали тикеты, суммировали Slack-потоки или коррелировали графики», — рассказал он. «Но часто останавливались именно на коде. Они говорили ‘Сервис A упал’, но не объясняли почему конкретно».
Другая возможность, которая есть в некоторых инструментах, включая error-мониторы типа Sentry: способность захватывать исключения. Но вот в чём загвоздка, по словам Адлера: узнать об исключении — это хорошо, но это не связывает их с business impact и не даёт AI-агентам контекст, нужный для предложения исправлений.
Как runtime-сенсоры работают иначе
Runtime-сенсоры переносят разум туда, где код исполняется. Сенсор Hud работает как SDK, который встраивается одной строкой кода. Он видит каждый запуск функции, но отправляет только лёгкие aggregate-данные, если что-то не ломается.
Когда происходят ошибки или замедления, сенсор автоматически собирает глубокие forensic-данные: HTTP-параметры, database-запросы и ответы, полный execution-контекст. Система устанавливает performance baseline за день и может алёртить как на резкие замедления, так и на outliers, которые пропускает percentile-мониторинг.
«Теперь мы получаем всю эту информацию для всех функций, независимо от уровня, даже для underlying packages», — рассказал Эйлон. «Иногда проблема очень глубокая, но мы её видим довольно быстро».
Платформа работает через четыре канала:
- Веб-приложение для централизованного мониторинга и анализа
- IDE-расширения для VS Code, JetBrains и Cursor, которые показывают production-метрики там, где ты пишешь код
- MCP-сервер, который подаёт структурированные данные AI-кодирующим агентам
- Система алёртов, которая выявляет проблемы без ручной конфигурации
Интеграция MCP-сервера критична для AI-ассистированной разработки. Инженеры Monday.com теперь могут запрашивать поведение production прямо в Cursor.
«Я просто спрашиваю Cursor: эй, почему этот endpoint медленный?», — поделился Эйлон. «Когда он использует Hud MCP, я получаю все granular-метрики: вот эта функция на 30% медленнее после последнего deployment. И я вижу root cause».
Это меняет весь workflow incident response. Вместо того чтобы начинать в Datadog и лазить по слоям, инженеры начинают с вопроса AI-агенту. Агент сразу имеет доступ к функция-уровневым production-данным.
От мистических инцидентов к минутным исправлениям
Переход от теоретической возможности к практическому результату виден в том, как инженерные команды на самом деле используют runtime-сенсоры. То, что раньше занимало часы или дни расследований, теперь решается за минуты.
«Я привык к этим мистическим инцидентам — всплеск CPU и не понимаешь, откуда», — рассказал Эйлон. «Несколько лет назад была именно такая ситуация, и мне пришлось создавать свой инструмент, который берёт CPU-профиль и memory dump. Теперь у меня есть все данные о функциях, и я видел, как инженеры решают такое просто со скоростью света».
В Drata цифры впечатляют. Компания создала внутреннюю /triage-команду, которую support-инженеры запускают в своих AI-ассистентах, чтобы мгновенно определить root cause. Ручная triage-работа упала с примерно 3 часов в день до менее чем 10 минут. Mean time to resolution улучшился примерно на 70%.
Команда также генерирует ежедневный «Heads Up»-репорт quick-win ошибок. Потому что root cause уже захвачена, разработчики могут исправить такие проблемы за минуты. Support-инженеры теперь проводят forensic-диагностику, для которой раньше требовался senior-разработчик. Throughput-тикетов увеличился без расширения L2-команды.
Где эта технология занимает место
Runtime-сенсоры занимают отдельную нишу от традиционных APM, которые отлично работают с service-уровневым мониторингом, но борются с granular, cost-effective функция-уровневыми данными. Они отличаются от error-мониторов, которые захватывают исключения без business-контекста.
Технические требования для поддержки AI-кодирующих агентов отличаются от человеческой observability. Агентам нужны структурированные функция-уровневые данные, над которыми они могут рассуждать. Они не могут парсить и коррелировать raw-логи так, как люди. Традиционная observability также предполагает, что ты можешь предсказать, что тебе понадобится, и настроить instrumenting соответственно. Этот подход ломается с AI-сгенерированным кодом, где инженеры могут не глубоко понимать каждую функцию.
«Я думаю, мы вступаем в новую эру AI-сгенерированного кода и видим новый стек, как пазл, складывающийся в картину», — сказал Адлер. «Я просто не думаю, что cloud computing observability-стек аккуратно впишется в то, как будущее выглядеть».
Что это значит для enterprise
Для организаций, которые уже используют AI-кодирующие ассистенты типа GitHub Copilot или Cursor, runtime intelligence — это safety layer для production-развёртываний. Технология позволяет то, что Monday.com называет «agentic investigation» вместо ручного прыгания между инструментами.
Более широкое значение связано с доверием. «С AI-сгенерированным кодом мы получаем гораздо больше AI-кода, и инженеры начинают не знать весь код», — отметил Эйлон.
Runtime-сенсоры закрывают этот gap знаний, предоставляя production-контекст прямо в IDE, где ты пишешь код.
Для компаний, которые хотят масштабировать AI code generation за пределы пилотов, runtime intelligence решает фундаментальную проблему. AI-агенты генерируют код на основе предположений о поведении системы. Production-среды сложны и неожиданны. Функция-уровневые данные поведения, автоматически захватываемые из production, дают агентам контекст, нужный для генерации надёжного кода в масштабе.
Организациям стоит проверить, может ли их существующий observability-стек cost-effective обеспечить granularity, которая нужна AI-агентам. Если получение функция-уровневой visibility требует драматического увеличения ingestion-затрат или ручного instrumenting, runtime-сенсоры могут предложить более sustainable архитектуру для AI-ускоренных workflow разработки, которые уже появляются по всей индустрии.
Будущее разработки — это когда AI пишет код, но нужно видеть, что происходит в production. И это уже не фантастика, а реальность, которую нужно осваивать прямо сейчас.🔔 Чтобы узнать больше о том, как AI меняет разработку, observability и production-мониторинг, подпишитесь на мой канал «ProAI» в Telegram!