Наблюдаемость в агентную эру

Кода стало больше, чем внимания

Почему привычный мониторинг ломается, когда код пишут агенты, и что приходит на смену. По докладам AI Native DevCon 2026.

Джастин Кормак в докладе «When Tests Lie» (AI Native DevCon) рассказывает про своё хранилище, совместимое с S3: 350 000 строк Rust, написанных почти целиком AI, — и он не читал этот код. Rust он, по собственному признанию, знает наполовину. За одну неделю рефакторинга диф составил +120 000 / −75 000 строк. Один файл дорос до 43 000 строк, прежде чем его пришлось разбирать вручную. Для сравнения, по его же оценке: типовые реализации объектного хранилища пишут от двух лет до десятилетия.

Держи эту картинку в голове весь остальной текст. Не потому, что все так работают, а потому что это предельный случай уже наступившей нормы: код есть, автора у него нет.

Оливье Помель, CEO Datadog, в разговоре «Datadog CEO on AI Security, Trust and the Future of Observability» описывает тот же сдвиг с другой стороны. За 40–50 лет продуктивность выросла на порядки, AI добавляет ещё ×100–×1000 — это его риторические оценки, не замеры, и Помель здесь заинтересованная сторона: ровно этот сдвиг увеличивает рынок его компании. Но побочный эффект он формулирует точно: разработчик всё хуже понимает, что делает его приложение. Центр работы уезжает с «набрать код» на «работает ли оно, не стоит ли дороже, чем должно, делает ли то, что нужно бизнесу».

Мерлин из incident.io в докладе «I Broke Production at 2 AM» добавляет арифметику. Даже если петли обратной связи снижают change failure rate, при росте числа изменений в пять–десять раз (его оценка, не замер) абсолютное число поломок растёт. Мониторинг проектировался под другой темп потока изменений.

И дальше — тезис, ради которого стоит читать всё остальное. Помель: у обычного приложения после деплоя есть довольно точное представление, делает ли оно то, что должно. У AI-приложения такого представления нет в принципе. «For an AI application, you don't [know], and you need to measure in production». Это переворачивает роль наблюдаемости: из подстраховки, которую вспоминают, когда что-то пошло не так, она становится единственным каналом, по которому ты вообще узнаёшь, что построил.

Про заявленный тезис

Название доклада Мирко Новаковича (CEO Dash0, ex-founder Instana) звучит как приговор: «Why Most Observability Platforms Won't Survive the AI Agent Era». Прежде чем принимать его за вывод, посмотри, кто его произносит и что за ним стоит.

Аргумент «за» — его собственный, и он честно называет это экзистенциальным вопросом для своей компании. Если пользователь работает с наблюдаемостью изнутри Cursor, Claude Code или стороннего AI SRE-агента, ценность создаётся там, а платформа остаётся хранилищем. «At the end people will pay for the value, not for the data». Хранилище — это гонка на дно по цене.

Аргумент «против» звучит от Помеля, и он тоже вендор — крупнейший incumbent категории. Его контраргумент: компания, которая уже собирает всю телеметрию, может выбирать, в каких классах инцидентов автоматизировать действие, а где промолчать. Беспилотник не может сказать «я делаю только левые повороты», а платформа наблюдаемости — может, и потому стартует с высокой precision при низком recall.

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

Что дальше

Раздел 1 — что именно сломалось в мониторинге: объём, отсутствие автора, недетерминизм, и почему при крупной аварии алерты бесполезны.

Раздел 2 — ядро: почему тесты при агентной генерации перестали быть доказательством и что работает вместо них.

Раздел 3 — что трассировать в агентном прогоне, чем это отличается от классической трассировки и сколько стоит.

Раздел 4 — инциденты, обратная связь из прода в агента и задокументированные провалы автоматизации.

Заключение — порядок сборки контура, что мерить и где человек обязан остаться.

И одна методическая рамка на весь текст. Почти все, кто содержательно говорит о наблюдаемости в агентную эру, её продают: Datadog, Dash0, Traceloop/OpenLLMetry, Hud, incident.io, Tessl. Это не повод их не слушать — у них лучшие данные в отрасли и они первыми упираются в реальные ограничения. Это повод каждый раз отделять наблюдение от продуктовой ставки. Дальше такие места помечены прямо в тексте, и там, где спикеры друг другу противоречат, показаны обе позиции без попытки свести их к одной.

Что сломалось в мониторинге

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

Объём: поток изменений вырос быстрее, чем контур контроля

Мерлин (incident.io, доклад «I Broke Production at 2 AM») формулирует это как арифметику, а не как жалобу. AI резко поднял rate of change. Допустим, петли обратной связи работают и change failure rate падает — но если число изменений выросло в пять или десять раз (его оценка, не замер), абсолютное число поломок всё равно растёт. incident.io продаёт платформу incident response, интерес прямой; но сама арифметика от интереса не зависит.

Масштаб на конкретике даёт Кормак («When Tests Lie»): 350 000 строк Rust, неделя рефакторинга — +120 000 / −75 000 строк, 5000 тестов, проходящих за две минуты. Ревью такого потока глазами невозможно не потому, что люди ленивы, а потому что глаз столько не пропускает.

Есть и архитектурный предел. Симон Мартинелли в докладе «Lessons from Spec-driven Development» описывает клиента-страховую: около 500 микросервисов и около 500 микрофронтендов. По его опыту это делает агентную работу почти невозможной — агенту нужен весь релевантный контекст в одном месте. Его рекомендация — self-contained systems, вертикали «UI + логика + БД» в одном репозитории, а не возврат к монолиту с тысячами таблиц. Оговорка: это его консалтинговый опыт на бизнес-приложениях, не продуктовая разработка. Но вывод для наблюдаемости прямой: топология системы теперь влияет на то, можно ли её вообще расследовать агентом.

Автор: код есть, спросить некого

Мэй Уолтер (сооснователь Hud, вендор runtime intelligence) в докладе «From Blind Spots to Merged PRs» описывает петлю, которая перестала фильтровать: один агент делает PR, второй говорит «выглядит отлично», тесты зелёные — и код всё равно находит творческие способы упасть в проде. Оба конца контроля стали автоматическими. Её формулировка: «Coding agents have no idea how [the code] actually behaves [in production]».

Тут же техническая причина, а не только организационная. Продовый контекст выражен в сервисах и эндпоинтах — в её примере эндпоинт отвечает 5 секунд, P99 — 6 секунд, P100 — 17 секунд. Кодовый агент рассуждает функциями, файлами и методами классов. Связь между тем и другим он может угадать, но не знает. Отсюда её решение — prod-to-code mapping на уровне функций (разбор в разделе 4). Её же оговорка: часть проблем действительно ловится статическим анализом, и mapping нужен там, где надо перейти от «расследование ведёт человек» к «расследование ведёт workflow».

Помель (Datadog, заинтересованная сторона) описывает ту же дыру со стороны навыка: чем выше продуктивность, тем меньше разработчик понимает свою систему. И делает продуктовый вывод — если ты не писал код, наблюдать надо не код, а исход: делают ли пользователи то, что нужно, получают ли ценность. Причину ищешь потом и там, где она есть — в коде, в спеке, в инфраструктуре. Отсюда его прогноз о слиянии observability с product analytics. Прогноз совпадает с роадмапом Datadog, где product analytics уже стоит поверх RUM, — читай как позицию, а не как нейтральное предсказание.

Недетерминизм: одинаковый вход, разный выход

Андрей Райков (principal engineer, Delivery Hero — не вендор, внутренний кейс) в докладе «AI Driven Load Test Analysis» перечисляет ровно то, что ломает мониторинговую логику «сравнили с порогом»:

• результаты различаются между прогонами при одинаковом промпте;
• различаются между моделями;
• деградируют со временем — через одну-две недели вывод «менялся драматически», и это при том, что каждый раз создаётся новый тред, без длинного диалога.

Его правило: «Every time you modify your prompt you should expect unexpected». И отдельно — детерминированная версия той же задачи («тупое сравнение чисел») работала пять лет: «It's very dumb but it works».

Помель добавляет главное. У обычного приложения после деплоя есть довольно точное представление, делает ли оно то, что должно. У AI-приложения такого представления нет в принципе — измерять можно только в проде. Его иллюстрация: было 1% неудовлетворительных диалогов, стало 5% — почему?

Следствие, которое дорого стоит эксплуатации: телеметрия сменила класс данных. Раньше в трейсы и логи не попадали рецепты врача и номера соцстрахования. Вход и выход модели — попадают. Меняются требования к хранению, доступу и защите; при этом без просмотра этих данных наблюдаемость LLM-приложения не построить вообще. Это противоречие Помель не разрешает — он его констатирует.

Отдельная поломка на входе — качество самой телеметрии. Новакович (Dash0, вендор) напоминает: в OpenTelemetry обязателен ровно один тег, service.name. Раньше проприетарный агент дописывал pod name и host name сам; теперь контекст приходит от клиента, и если клиент их не проставил, запрос «дай логи этого пода» физически невыполним. Появились компании, занимающиеся только качеством телеметрии. Практические обходные пути — в разделе 3.

Дашборд как протез

Новакович: график придумали не потому, что он истина, а потому что человек не видит спайк в 5000 точек, а на картинке видит. Агент читает исходные данные напрямую. Значит первичный экран сервиса — не chart, а текстовый статус вида «работает в пределах последних 30 дней, но появились две новые ошибки, выглядят подозрительно». Его формулировка: «An agent doesn't need charts anymore. The charts are just for the user». Оговорка обязательна: Dash0 строит продукт именно на этой ставке, а «5000 точек» — иллюстрация, не замер.

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

И два наблюдения, которые стоит держать рядом:

• «Рождественская ёлка». При серьёзной аварии всё связано со всем, поэтому мигает всё. Когда красное всё, ты по-прежнему не знаешь, откуда идёт. Именно тут нужен эксперт, знающий «эта база подключена ко всему».
• Знание не в Confluence, а в головах. Экспертиза «где смотреть» не документирована. Уходят два человека — знание исчезает. Новакович предлагает «enterprise architecture management tool для агентов»: машиночитаемый корпус знаний о системе, включая architectural decisions. И сам признаёт, что не знает, кто должен этот слой держать — «не уверен, что это будем мы».

Спор о невыживании платформ

Тезис Новаковича стоит развернуть в обе стороны, потому что аргументы разной природы.

Аргумент	Кто и с каким интересом	Чем подкреплён
За. Ценность уезжает в агента, платформа остаётся базой данных — гонка на дно по цене	Новакович, Dash0 — вендор, но говорит о риске собственной компании	Ничем измеримым; «At the end people will pay for the value, not for the data»
За. 90% вендоров конвертируют OTel во внутренний формат и теряют семантические конвенции, а модели натренированы именно на OTel	Новакович — Dash0 OTel-native, это его прямое конкурентное отличие	Оценка спикера, не исследование. Цифру 90% надо проверять отдельно
Против. Incumbent может выбирать классы инцидентов: высокая precision при низком recall. «Беспилотник не может делать только левые повороты, платформа — может»	Помель, Datadog — защита позиции лидера	Логика, цифр не приведено
Против. Данных без платформы всё равно нет: агенту нужен инструмент triage поверх миллиона трейсов	Новакович же — то есть его собственный аргумент работает и против его тезиса	Разбор в разделе 3

Отдельно к спору примыкает трезвость самого Помеля, и она полезнее его прогнозов. На вопрос «что вас пугает» он отвечает: хайп-циклы и оверселлинг. Напоминает, что категория AIOps существовала десять лет назад и «AI» там был регулярками; Datadog первые десять лет намеренно не писал AI на сайте. Его позиция — недообещать и перевыполнять, и он прямо признаёт, что технология «ещё не совсем там», а агенты пока не работают массово в поле. Личное: «I haven't reached break-even yet. I'm still spending more time learning about it [AI] than it saves me».

Со сцены: два ложных срабатывания — и систему выключают навсегда

• Кто и где: Оливье Помель, CEO Datadog, разговор «Datadog CEO on AI Security, Trust and the Future of Observability» (подкаст AI Native Dev). Крупнейший вендор категории — заинтересованная сторона.
• Что показали: заказчики говорят «давайте мне false positives, я сам разберусь» — и это, по его словам, ложь. Люди пойдут по ложному следу ради коллеги, но не ради машины. Отсюда планка precision для автоматических выводов должна быть очень высокой. Отдельное наблюдение: в безопасности планка ниже, чем в operations, потому что соотношение риска и выгоды другое — «уронить нагрузку, чтобы предотвратить взлом, приемлемо; уронить её, чтобы предотвратить падение, — нет».
• Цифры: «два false positive подряд» — эмпирика Datadog, не формальный замер. Точный root cause три-четыре года назад был «научной фантастикой», сейчас, по его оценке, «в пределах досягаемости».
• Что это меняет: доверие к автоматике не деградирует плавно, оно обваливается. Значит стратегия выката не «покрыть больше случаев», а «сузиться до тех, где ты почти наверняка прав». Помель прямо говорит, что главное препятствие — LLM не умеют понимать, чего они не знают, и всегда охотно отвечают, поэтому основная инженерная работа идёт не в «ответить», а в «понять, когда мы правы».
• Как читать: это одно из самых полезных наблюдений темы, но оно же — объяснение вендора, почему он не выпускает автоматику быстрее конкурентов.

Коротко

• Сломалось допущение, а не инструмент. Мониторинг рассчитан на поток изменений, у которого есть автор и повторяемое поведение; агентная разработка убирает и то, и другое (Мерлин/incident.io, Уолтер/Hud, Райков/Delivery Hero).
• Тесты и ревью перестали быть фильтром, когда оба конца петли автоматические: «Coding agents have no idea how the code actually behaves» (Уолтер, Hud — вендор).
• У AI-приложения нет момента «оно работает» до прода (Помель, Datadog — вендор). Наблюдаемость превращается из подстраховки в единственный источник знания о системе.
• Телеметрия стала персональными данными, а её качество — узким местом: в OTel обязателен ровно один тег service.name (Помель; Новакович, Dash0 — вендор).
• Тезис «большинство платформ не выживет» не разрешён. За него — уход ценности в агента и потеря семантики OTel; против — возможность incumbent'а выбирать задачи и стартовать с высокой precision. Обе стороны вендоры, измеримых аргументов ни одна не привела.

Когда тесты врут

Доклад Джастина Кормака «When Tests Lie» (AI Native DevCon) — самый неудобный материал темы, потому что он не про инструменты, а про то, что перестало быть доказательством. Кормак ничего не продаёт: в расшифровке его компания не названа, проект личный. Это редкий случай, когда цифры приходят без продуктовой ставки за ними.

Контекст: он написал (точнее, AI написал под его руководством) хранилище, совместимое с S3. 350 000 строк Rust. Код он не читал, Rust знает наполовину. Неделя рефакторинга — +120 000 / −75 000 строк. Один файл вырос до 43 000 строк, пока не пришлось его разбирать. 5000 тестов проходят за две минуты; две минуты — его личный порог приемлемости, всё, что дольше, перестают гонять.

И на этом фоне — его главный вывод: 5000 тестов и почти полное покрытие ничего не доказывают.

Почему 100% покрытия — ловушка

Кормак честно попробовал догнать покрытие до 100% на большом проекте. Агент написал тривиальные тесты плюс тесты на невоспроизводимые ошибки — например, на отказ генератора случайных чисел. Такие тесты не падают никогда и не ловят ничего; они просто существуют, чтобы строка была закрашена. Он отказался от цели и осел на 75–100% по файлам, без фанатизма.

Его формулировка через Деминга: «Looking at the lines of code does not actually find the bugs».

Дальше — список того, чего тесты не находят в принципе, и это ядро доклада:

• Проблемы безопасности. Тест проверяет то, что ты предположил; атака — то, что ты не предположил.
• Качество архитектуры. Тесты не отвечают на вопрос «хороша ли эта архитектура». Зелёный прогон совместим с любым уровнем архитектурного долга.
• Всё, что ты не умеешь измерить. Не сформулировал — не проверяется.

И жёсткое следствие: «Focusing on test coverage means you're not thinking about security enough». Гонка за покрытием не просто бесполезна — она вытесняет мышление о безопасности, потому что съедает то же внимание.

Отсюда его переопределение роли тестов: «Tests are really discovery tools». Тест — не доказательство корректности, а инструмент разведки пространства поведений. Метрика хорошего тест-сьюта — не процент, а сколько нового он про систему рассказал. У Кормака индикатор был конкретный: его тесты нашли две воспроизводимые 500-е ошибки в самом S3. Это и стало сигналом, что сьют реально исследует пространство, а не пересказывает код.

С той же стороны заходит Дру Нокс (Tessl, вендор — head of product AI) в разговоре со Стивом Йегги «You'll Never Write Code the Same Way Again»: «Coverage can often be theater». У них на каждом PR требуется почти 100% покрытия внутри диффа — и они прямо говорят, что это ничего не доказывает.

Что тогда служит доказательством

Ни один из спикеров не предлагает замену «одна метрика вместо другой». Предлагается набор источников доказательства, у каждого своя цена и свои границы.

Приём	Что доказывает	Ограничение (по словам самого спикера)
Внешний оракул (реальная система)	Что поведение совпадает с эталонным	Оракул не равен спецификации; S3 частично eventually consistent, нужны ретраи
Mutation testing	Что тесты вообще способны поймать поломку	Много false positives, агенту нельзя дать действовать напрямую
Типы	Что класс багов невозможен	Работает не везде; требует перепроектирования, а не дописывания тестов
AI security review всего кода	Находит то, что пропустило AI code review	~3/4 находок валидны, остальное — шум для разбора
Fuzz / property-based	Находит края, которые никто не формулировал	Не заменяет понимание, только расширяет разведку
Post-conditions из спеки	Даёт acceptance criteria, проверяемые тестами	Опыт консалтинга на бизнес-приложениях, не продуктовая разработка

Разберём по порядку.

Оракул — сильнейший приём Кормака. Он использовал живой S3 как эталон: 1500 тестов бьются в реальный S3, фиксируют его поведение, дальше агенту говорят «делай ровно так». Обобщение, которое он даёт залу: если строишь сложную систему — сначала напиши тривиальную версию с тем же поведением и используй её как оракул. Ограничение честное: S3 частично eventually consistent, приходится добавлять ретраи, и оракул не равен спецификации — он равен тому, как система ведёт себя сегодня.

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

Документация — не доказательство, а источник гипотез. Сотни страниц документации S3, по его опыту, «в каждой детали оказываются неверны». Его правило: «Never trust anyone's documentation at all». Полезность доков в другом — они подсказывают, где искать интересное.

Тут же — разделение труда, которое стоит запомнить. Человек хорошо вычитывает edge cases из документации, агент — плохо. Человек читает доки AWS и спрашивает «а это правда?», и находит края. Агент, направленный на те же доки, этого не умел. Зато агент отлично пишет тесты по подсказанным гипотезам и по типовым краям — 0, 1, 10001. То есть гипотезы генерирует человек, объём проверок — агент.

Публичный API не покрывает невидимое поведение. Через публичное API нельзя увидеть, когда объект действительно удаляется в S3. Кормак отдельно жалеет, что не построил management/reporting-интерфейсы: по ним можно было бы тестировать внутренности. Практический вывод: наблюдаемость системы — это тоже тестируемость, и её надо проектировать заранее.

Иногда правильный ответ — типы, а не тесты. Проблема TOCTOU с двойной проверкой прав решилась не трассировкой и не тестами, а типом authorized request: функции за воротами принимают только авторизованные запросы. Класс багов исчез вместе с необходимостью его тестировать.

Mutation testing как доказательство того, что тесты живые — практика Tessl (Нокс, вендор). Поверх требования покрытия внутри диффа код мутируют так, чтобы сломать, и смотрят, поймали ли тесты. Отчёт читает агент и оставляет комментарии — напрямую действовать ему не дают, слишком много false positives. Раз в неделю — прогон по всей кодовой базе. Заявленный эффект — «почти всегда приводит к улучшению тест-сьюта»; цифр не приведено.

Оттуда же самое частое слепое пятно тест-агентов: они никогда не проверяют ноль. Бизнес-логика вида «этот список никогда не будет пустым» не выражена в коде, а тест-агенты любят проверить 5 и 50. Граничные условия — главный улов mutation testing.

Fuzz и property-based — метод, а не экзотика. Рабочая практика Кормака: после каждого инцидента спросить агента «какие тесты поймали бы это?». Агент предлагает новые классы тестов; fuzz и property-based находили реальные баги.

AI security review отдельно от AI code review. Кормак прогоняет Codex Security, находки чекинит в репозиторий и просит агента их разобрать. Примерно три четверти находок валидны. Плюс регулярные сессии «как мы могли этого избежать, какой тест это ловит». Его вывод: ревью всего состояния кода полезнее, чем только ревью PR.

Спека как источник проверяемых условий. Мартинелли («Lessons from Spec-driven Development»): post-conditions use case'ов — это и есть acceptance criteria, которые прямо проверяются тестами. У его клиента команда сократилась с 5–7 до 1–2 человек на self-contained system, спецификацию пишут две недели, реализуют быстрее. Оговорка: консалтинг на бизнес-приложениях.

Отдельно: флаки-тесты и почему правило не работает

У Кормака жёсткое правило: никаких флаки-тестов, чиним немедленно. Агент систематически его игнорирует — потому что в обучающих данных разработчики флаки не чинят. Правило прописано в AGENTS.md, и это не помогает; приходится буквально ругаться.

Отдельный антипаттерн: агент «подгоняет» код под сегодняшнее поведение AWS, потом обратно, вместо того чтобы починить тест. Лечится не инструкцией, а скоростью: быстрые тесты, много прогонов, ночные прогоны на нескольких машинах ловят редкие флейки.

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

Второй механизм оттуда же — самодельный трейсинг внутри проекта, отдельно от прод-мониторинга. Кормак попросил агента построить поддерживаемый tracing framework прямо в кодовой базе. Результат: можно отдать агенту трейс из ночного прогона и сказать «вот что случилось», вместо того чтобы он гадал. Его предупреждение: «If you give an AI a bug but you don't know how to repro it... it can waste a lot of time». Ограничение честное — у самодельного трейсинга были накладные расходы, из-за чего он врал в performance-тестах: годился для «где большие провалы», не для точных чисел.

Провал, который стоит помнить

Со сцены: модель «идеально» решала демо, потому что знала ответы

• Кто и где: Мирко Новакович, CEO Dash0 (ex-founder Instana), доклад «Why Most Observability Platforms Won't Survive the AI Agent Era», AI Native DevCon. Вендор — и одновременно автор тезиса о невыживании платформ.
• Что показали: у OpenTelemetry есть открытое демо-приложение с намеренно заложенными и задокументированными проблемами. Первые эксперименты команды с LLM на нём давали превосходные результаты — модель находила проблемы уверенно и точно. Пока не выяснилось, что она обучена на документации этих самых проблем.
• Цифры: не приведены — и это часть урока: «превосходный результат» не был измерен ни против чего внешнего.
• Что это меняет: классическая утечка бенчмарка, и команда чуть не приняла её за качество продукта. Если ты оцениваешь агента на публичном демо, открытом репозитории или известном датасете, ты, скорее всего, измеряешь память модели, а не её работу. Оценивать надо на своём, закрытом, желательно свежем.
• Цитата: «It could cheat the test because it knew the problems up front».

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

Коротко

• Тесты — инструмент разведки, а не доказательство. «Tests are really discovery tools» (Кормак, «When Tests Lie», не вендор). 5000 тестов и покрытие 75–100% на 350 000 строк не отвечают на вопрос, работает ли система.
• Три вещи тесты не находят никогда: проблемы безопасности, качество архитектуры и всё, что ты не умеешь измерить. Гонка за покрытием прямо вытесняет мышление о безопасности.
• Доказательство приходит извне: внешний оракул (1500 тестов против живого S3), mutation testing (Нокс, Tessl — вендор), типы вместо тестов, AI security review по всей кодовой базе (~3/4 находок валидны).
• Оракул, написанный тем же AI, — тавтология. Он должен приходить другим путём, в идеале из внешней системы.
• Утечка бенчмарка выглядит как успех. Кейс Dash0 на OTel-демо: модель «решала» задачи, потому что была обучена на описании их проблем.

Что трассировать в агентном прогоне

Главный доклад по теме — «Agents Observability with OpenLLMetry» Нира Газита (Traceloop). Сразу оговорка: Traceloop — коммерческая компания вокруг open-source проекта, то есть вендор, продающий платформу поверх OpenTelemetry. Это не обесценивает техническую часть, но объясняет, почему в докладе много про «подключается двумя строчками» и мало про то, когда этого не хватает.

OpenLLMetry — это не новый протокол

Первое, что стоит понимать: OpenLLMetry не конкурирует с OpenTelemetry, это набор инструментаций поверх OTel, растянутый на GenAI. Механика — monkey patching SDK провайдеров и фреймворков, всё происходит на стороне приложения. Экспорт в любую платформу меняется переменными окружения. По цифрам доклада: 40+ поддерживаемых фреймворков и провайдеров, подключение — две строки кода плюс установка SDK. Название, по рассказу Газита, родилось из твита Патрика за две недели до релиза.

Если OTel в кодовой базе уже стоит, обёртка в две строки не нужна: инструментации лежат отдельными пакетами, ставятся напрямую и работают с auto-instrumentation. Две строки — это удобство для тех, кто не хочет разбираться с настройкой OTel, а не архитектурное требование.

Раскладка по трём столпам

Газит даёт конкретную раскладку — что и куда пишется в агентном прогоне.

Столп	Что кладём	Почему сюда
Logs	Промпты, completions, вызовы функций	Большие текстовые блобы: важен и факт события, и точное содержимое
Metrics	Token usage, latency, error rate	Агрегаты по временным окнам — то, что имеет смысл считать
Traces	Многошаговый прогон целиком: цепочка LangChain, полное исполнение агента	Нужен и каждый шаг отдельно, и весь процесс сразу

Для RAG-пайплайна этого мало. Инструментация Pinecone, по описанию Газита, логирует все запросы, индексы и возвращённые векторные данные плюс метрики латентности и релевантности — scores. Вывод общий: наблюдаемость RAG обязана покрывать retrieval, а не только вызов модели. Если ты видишь только промпт и ответ, ты не отличишь плохую генерацию от плохого поиска.

Чем это отличается от классической трассировки

Разница, которую Газит показывает демо, а не словами. Агент с одним инструментом — веб-поиском. Вывод в консоль нечитаем: месиво. Трейс того же прогона показывает цепочку:

agent call
  └─ tool call
       └─ фактический запрос: «current weather in Tel Aviv»
       └─ JSON-ответ инструмента
  └─ вызов модели
  └─ итоговый ответ

Его формулировка по итогам демо: «If you can't compare this to the messy logs that we had here — I think it's clear what's better».

Ценность здесь не в отдельных событиях, а в связке «весь процесс сразу + точное содержимое каждого шага». Классический трейс отвечает на вопрос «где потратилось время». Агентный трейс должен отвечать ещё и на «почему было принято это решение» — а для этого в спане обязано лежать содержимое, а не только тайминг и статус.

Отсюда и главное честное ограничение доклада: Газит сам говорит, что базового tracing мало. Визуализация графа исполнения агента ещё не построена, это его личное «жду в будущем». То есть на сегодня ты получаешь структурированную запись прогона, но не картину того, как агент ходил по пространству решений.

Тот же запрос с другой стороны формулирует Новакович (Dash0, вендор): главный запрос пользователей — понять, почему агент пришёл к выводу «проблема в базе». Нужны видимые шаги рассуждения и переходы между ними. В агентную эру объектом наблюдаемости становится не только система, но и сам агент-расследователь.

Недетерминизм: что с ним делать практически

Самый дешёвый и конкретный приём всего батча — от Газита. У OpenAI есть поле system_fingerprint: какая внутренняя система обслуживала запрос. Оно меняется довольно часто. Люди жалуются «на этой неделе модель поглупела», и во многих случаях причина видна прямо в телеметрии: при том же названии модели сменился fingerprint.

Это позволяет отделить две вещи, которые иначе неразличимы:

• дрейф провайдера — поменялось у них;
• собственная регрессия — поменялось у тебя.

Ограничение Газит называет сам: внутрь «надстроек» провайдера — JSON schema, assistants — видимости нет. Он относит это к желаемому, но недоступному.

Второй практический слой — OTel Collector. Газит перечисляет две задачи, ради которых его ставят: слать данные в несколько мест сразу (Datadog + Honeycomb) и вычищать персональные данные до отправки. Для агентных трейсов второе критично, потому что в спанах лежат промпты и ответы — то самое, о чём в разделе 1 говорил Помель: телеметрия сменила класс данных.

Третий слой — качество тегов, продолжение сюжета из раздела 1. Новакович: в OTel обязателен ровно один тег, service.name. Если клиент не проставил pod name и host name, запрос «дай логи этого пода» невыполним физически, а не по интерфейсу. Частичное решение, которое он называет, — Kubernetes-оператор, проставляющий теги и автоинжектящий инструментацию. Появились и компании, занимающиеся исключительно качеством телеметрии.

Почему модели вообще понимают телеметрию

Наблюдение Новаковича, объясняющее много: модели работают с трейсами «из коробки» не потому, что видели много трейсов, а потому что видели спецификацию. Трейс — это текст с тегами по открыто задокументированной семантической конвенции; модели натренированы на этой документации, поэтому знают, что host.name — имя хоста, а HTTP 404 — проблема. Работают с телеметрией примерно так же, как с кодом.

Больших публичных корпусов самих трейсов при этом почти нет — есть несколько репозиториев «донорских» логов и спанов. Оговорка обязательна: это ключевой аргумент OTel-native вендора, и он же обосновывает его претензию к конкурентам (90% вендоров конвертируют OTel во внутренний формат и теряют семантику — оценка спикера, не исследование).

Практическое следствие для тебя: чем ближе твоя телеметрия к стандартным семантическим конвенциям, тем меньше промпт-инжиниринга понадобится, чтобы агент её понял. Кастомные имена метрик — это налог, который ты платишь каждым запросом.

Один трейс, миллион трейсов и граница модели

Новакович проводит границу очень чётко:

• Уронить один проблемный трейс в модель — работает. Она распознаёт код ошибки Oracle, объясняет исчерпание connection pool, даёт контекст из документации. Делает работу человека.
• Найти аномалию в миллионе трейсов — нет. Объём.

Решение — не «дать модели больше контекста», а дать ей инструмент. Функция triage сравнивает теги в ошибочных трейсах и находит общий признак: «у всех ошибочных один и тот же customer ID». Агенту она отдаётся как tool через MCP. Его формулировка: «You have to build your API essentially in a way that it works for the agent».

Это же наблюдение, к слову, работает против его собственного тезиса о невыживании платформ: если агенту нужен triage поверх миллиона трейсов, кто-то должен этот triage держать.

Стоимость и токены как метрика наблюдаемости

Token usage у Газита стоит в metrics наравне с latency и error rate — и это не бухгалтерия, а метрика поведения. Стив Йегги («You'll Never Write Code the Same Way Again») доводит мысль до предела: в software factory работа буквально производится тратой токенов — рой генерирует отчёты и тикеты, второй рой их чинит, третий ревьюит. Отсюда два следствия:

• работу надо трекать как first-class сущность (у них для этого Beads — граф работ в git);
• «качество становится ручкой, на которой ты выбираешь, сколько токенов потратить».

Цифра, которую он приводит: 4 млн токенов в день — заявленный порог, на котором человек становится «AI-грамотным». Это пересказ чужой обучающей программы (Netflix: 5 часов, свой менеджер, своя реальная задача, когорта до 10 человек), не собственный замер Йегги. Его же ироничная поправка: «token maxing» — сначала людей учат тратить токены, потом приходится учить не тратить.

Экономика наблюдаемой фабрики у Йегги и Нокса (Tessl, вендор) устроена через роутинг: задачи тегируются «уровнем интеллекта» и раскладываются по моделям — дорогая на планирование, дешёвая на исполнение, ревью выдерживает модель на класс ниже генерации. Важная деталь: оптимизировать модель под интерактивную сессию бессмысленно (нельзя предсказать сложность), а под повторяющийся автоматизированный workflow — можно, потому что известно, как часто он падает. Отдельно замечают, что GitHub Actions — не самый дешёвый и не самый подходящий рантайм для длинных агентных задач.

И формулировка, которая переопределяет предмет наблюдения: «Not a given PR, but a system that produces PRs». Ты мониторишь не изменение, а машину, которая изменения производит.

Нагрузочное тестирование в агентную эру

Со сцены: 1500 подов не влезли в контекст

• Кто и где: Андрей Райков, principal engineer, Delivery Hero. Доклад «AI Driven Load Test Analysis», AI Native DevCon. Не вендор — внутренний кейс.
• Что показали: внутренний reliability manifesto требует «design for failure» — сервис должен масштабироваться до 3x прод-нагрузки быстро и 4x на длинной дистанции, на реалистичных сценариях, в проде. Пять лет назад отчёт делали руками: 12 страниц Google Doc и 20–30 скриншотов из Datadog, Grafana и CloudWatch — на один прогон одного сервиса. Интеграция модели — буквально три строки кода; вся сложность оказалась в промпте. Промпт разбит на три части: (1) определения и требования прямо из manifesto — мультипликатор, пороги error rate и latency, частота; (2) данные — прод (throughput, метаданные эндпоинтов, чтобы модель оценила реалистичность теста) и сам прогон (CPU, память, latency, error rate, throughput); (3) формат ответа — самая чувствительная часть, любое изменение слова меняет результат.
• Цифры: 10+ млн заказов в день, 70+ стран, 26 сервисов; раньше прогон раз в две недели, сейчас требование — еженедельно. В примере доклада 150 подов, в реальном прогоне — 1500, то есть сотни тысяч чисел.
• Что сломалось: при добавлении данных о CPU и памяти «всё сломалось» — модель уткнулась в контекстное окно и начала брать информацию произвольно. Починили не увеличением окна, а структурированием промпта и урезанием данных: агрегаты «сколько CPU на под» вместо сырых точек. Structured output помогал не всегда — исходные данные каждый прогон разные, и модель интерпретирует их по-разному. Плюс «AI are talkative»: просишь одно число, получаешь абзацы вокруг него.
• Что это меняет: после починки промпта модель уверенно находит выбросы в потреблении CPU по подам и выдвинула гипотезу о проблеме с балансировщиком — часть подов получает больше нагрузки, чем должна. Райков подтверждает, что гипотеза требует проверки, но правдоподобна. Второй полезный эффект — модель явно сообщает, каких данных ей не хватило: «не могу сказать про CPU и память, вы их не дали». Агрегация до отправки — не оптимизация расходов, а условие корректности.

Коротко

• OpenLLMetry — это OTel, растянутый на GenAI (Газит, Traceloop — вендор): monkey patching на стороне приложения, 40+ провайдеров, две строки подключения, экспорт меняется переменными окружения.
• Раскладка по столпам конкретна: logs — промпты, completions, вызовы функций; metrics — токены, latency, error rate; traces — весь многошаговый прогон. Для RAG обязателен retrieval со scores.
• Агентный трейс должен нести содержимое, а не только тайминги — иначе он не отвечает на вопрос «почему было принято это решение». Визуализации графа исполнения агента, по признанию самого Газита, ещё нет.
• system_fingerprint — дешёвый способ отличить дрейф провайдера от своей регрессии. Внутрь надстроек провайдера видимости нет.
• Один трейс модель разбирает, миллион — нет (Новакович, Dash0 — вендор). Нужен triage как tool через MCP: «build your API in a way that it works for the agent».
• Контекстное окно — это ограничение корректности, а не только стоимости. Кейс Delivery Hero: 1500 подов, модель начала выбирать данные произвольно; лечится агрегацией, а не большим окном.

Инциденты и обратная связь в прод

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

Кейс «два ночи»: не хватает не данных, а общей картины

Мерлин (incident.io, вендор — продаёт весь стек: on-call, response, AI SRE, status pages) в докладе «I Broke Production at 2 AM» описывает знакомую сцену. Телефон звонит в два ночи. Алерты горят везде. На звонке ещё трое, у каждого своя теория, полной картины нет ни у кого — и решения принимаются с долей нужной информации. Каждая минута дорога. Масштаб: 700 000 инцидентов у клиентов накопительно, около 1500 клиентов, 180 человек в компании.

Продуктовый ответ конкретный: агент начинает расследование до того, как человек зашёл в Slack-канал. К моменту, когда дежурный открыл ноутбук, контекст уже собран. Это разумно именно потому, что дефицит — не в данных, а во времени на их сведение. Рядом ставится «рождественская ёлка» Новаковича (Dash0, вендор): при серьёзной аварии мигает всё, и когда красное всё, ты по-прежнему не знаешь, откуда идёт. Агент полезен не тем, что «умнее», а тем, что успевает пройти больше веток за то же время.

И его же формулировка следующего шага: переход от single-player к multiplayer. В разборе аварии рядом с людьми параллельно работают один-три агента, каждый копает своё, человек добавляет контекст. Ведущий подкаста сводит это в формулу «context + evals»: делегирование требует снабдить исполнителя знанием и иметь способ проверить работу. Evals заведомо неполны — как и у людей, — но выборочная проверка обязательна.

Отдельно Новакович пересказывает публичное заявление CIO The Telegraph о том, что клиент переписал плейбук incident resolution: раньше шли по списку шагов, теперь первым действием спрашивают агента. Это пересказ вендором чужого поста в LinkedIn — проверяй по первоисточнику, прежде чем ссылаться.

Пост-мортем: два правила, которые не меняются, и одно, которое меняется

Не меняется первое: разбор остаётся blameless. Мерлин повторяет это дважды, в том числе как открывающий тезис доклада. Смотрят не на то, что человек сделал не так, а на процессы и отсутствие guardrails, позволившие ситуации возникнуть. Агенты этого не смягчают — при выросшем потоке изменений вопрос «кто виноват» ещё бессмысленнее. Не меняется второе: ценность корпуса появляется только со временем, на накопленных разборах, — Мерлин оговаривает это прямо.

Меняется третье — форма пост-мортема. В документ встраиваются не строки текста, а объекты: сервисы, команды, клиенты, pull requests, Slack-переписки, другие инциденты, таймлайн. Накопленный корпус «богатых» пост-мортемов читают и люди, и AI — для распознавания повторяющихся паттернов: если похожее уже было, это кандидат в root cause нового инцидента.

Технический приём, который стоит украсть: у каждого узла редактора есть «HTML schema awareness» — описание на естественном языке, что это за узел и как его создавать, и оно передаётся модели. Правило шире одного продукта: чтобы агент писал в твою структуру, структура должна себя объяснять. Сроки проекта: старт в августе, демо в сентябре, early access в ноябре, GA в декабре, старый редактор выключен в январе.

Runtime intelligence: прод как вход для агента

Мэй Уолтер (сооснователь Hud, вендор — это и есть их продукт) в докладе «From Blind Spots to Merged PRs» описывает слой между продом и кодовым агентом. По каждой функции собирается: как часто выполняется, сколько занимает, падает ли. При сбое проактивно снимается глубокий форензический контекст.

Ключ в порядке действий: не гонять агента по гигабайтам логов, а сначала сузить область до функции, потом достать глубину. Это прямое следствие проблемы из раздела 3 — модель разбирает один трейс и не разбирает миллион.

Второй, по её словам самый недооценённый эффект prod-to-code mapping — инверсия вопроса. Не только «почему это медленно», но и «я собираюсь тронуть эту функцию — на что это повлияет, задену ли я платежи или авторизацию». «I'm going to touch this. What does that impact? And should I care about it?» Это меняет оценку риска до внесения изменения, а не после.

Архитектурно петля у них из трёх намеренно открытых слоёв: язык запросов к данным (у них ClickHouse), скиллы с методологией расследования, автоматизации поверх (autofix, удаление мёртвого кода). Агенту нужен доступ на каждом уровне — «инструментов недостаточно, потому что агенту может понадобиться то, что я не могу выразить словами». Оговорка Уолтер: воркфлоу — это код. Их не отгружают и забывают, их постоянно правят; если правки трудны, люди перестают их делать.

Про скиллы у неё же аргумент, полезный за пределами их продукта: методология («как подходить к HTTP 500», «как к утечке памяти», «как к деградации производительности») зашивается заранее, чтобы агент не тратил токены и chain-of-thought на переоткрытие известного. Побочный эффект — это выводит знание Дэйва из головы Дэйва.

Требования к рантайму агентных воркфлоу они формулировали осознанно: не на ноутбуке, а в облаке; нейтральность по compute, harness и модели («никто не знает, какая лучшая — бывают сезоны»); безопасность прав и тул-коллов из готового решения; триггеры и по вебхукам, и по расписанию; лёгкость правок. Выбрали GitHub Agentic Workflows именно потому, что GitHub Actions у людей уже есть — путь наименьшего сопротивления, а не лучший в вакууме. Запуск еженедельный, отчёт в Slack.

Со сцены: 100 мс в норме, 45 секунд в выбросах

• Кто и где: Мэй Уолтер, сооснователь Hud, доклад «From Blind Spots to Merged PRs», AI Native DevCon. Вендор — runtime intelligence и есть их продукт.
• Что показали: отбор находок идёт не по «лучшей оптимизации», а по трём осям — hot paths (часто вызываемые эндпоинты), бизнес-влияние (платежи, аутентификация) и риск. Ищут максимальный эффект при минимальном риске, без миграций. Формат вывода человекочитаемый, буквально: «этот эндпоинт обычно 100 мс, но иногда 45 секунд — потому что используется Mongo distinct; замена на search даст 30–40%». Дальше человек выбирает — посмотреть глубже, завести тикет или открыть PR; обе ветки размечены, чтобы это можно было измерять.
• Цифры: P90 около 100 мс против выбросов около 45 с; ожидаемый выигрыш 30–40%; N+1 запрос, проживший в кодовой базе шесть лет (самой базе 15 лет).
• Что это меняет: центральная идея доклада — проблема не в том, что нельзя починить, а в том, что нельзя приоритизировать. «Час или три недели?» — чтобы узнать цену, приходится заплатить исследованием. Её метафора: как нести товар на кассу, чтобы узнать, сколько он стоит. Если исследование делает агент еженедельно и выдаёт оценённые по ROI возможности, performance-спринт, который откладывали месяцами, начинает происходить регулярно. Оговорка её же: бэклог от этого не опустеет, цель — лучшие решения, а не исчезновение работы.

Что у Hud не сработало

Честная часть доклада — три задокументированных провала.

Провал первый: автоматические PR. Логичный следующий шаг — «открывать PR на все находки высокого импакта и низкого риска» — провалился. Никто их не смотрит. Уолтер сравнивает это с опытом «700 issues в Datadog и Sentry»: список, на который смотрят и решают не начинать. Её вывод стоит запомнить дословно: убеждать надо человека, что это стоит внимания, а не агента, что это стоит токенов — «instead of convincing the agent that it's worth the tokens — he will always think that they are».

Провал второй: plausible but unverified. Первые предложения агента звучали верно, но было неизвестно, там ли бутылочное горлышко: при 20 секундах ответа непонятно, где именно потрачено время, — а предложение уже выглядит убедительно.

Провал третий: lazy fix. Есть исключение — давайте его поймаем. Оптимизация «по локальному синтаксису» даёт локальный ответ, а нужен более широкий взгляд. Лечится описанием того, что такое хороший фикс, — «как staff engineer объясняет новичку».

Из этих трёх Уолтер выводит порог, который применим гораздо шире её доклада:

«If something works 90% of the time, it's not an automation, it's streamlining humans».

90% — это не автоматизация, а ускорение человека. Переход от «ведёт человек» к «ведёт workflow» требует принципиально более высокой уверенности, потому что каждое ложное предложение стоит прерывания потока инженера и убивает доверие ко всему процессу. Цифра 90% — риторический порог, не замер; но она стоит ровно там же, где эмпирика Помеля про два false positive подряд из раздела 1. Два вендора, независимо, описывают один и тот же обрыв доверия.

Отсюда же стратегия выката, которую Помель (Datadog, вендор) формулирует прямо: начинать не с «решаем все инциденты», а с узкого подмножества, где уверенность максимальна — высокая precision ценой низкого recall. Препятствие он называет честно: LLM не умеют понимать, чего они не знают, и всегда охотно отвечают, поэтому основная работа идёт не в «ответить», а в «понять, когда мы правы». Его оговорка про сложность: разбор инцидента занимает команды квалифицированных людей и недели — в отличие от вождения, которое осваивает любой шестнадцатилетний.

Замыкание петли: детект, фикс и доставка

Помель рассказывает траекторию Datadog так: первые десять лет — принципиально никаких обратных действий, только приём данных. Несколько лет назад начали строить workflow automation, и именно это теперь позволяет замкнуть петлю: детект, генерация кода фикса и доставка. Самое простое поле — 500-е ошибки после релиза: диагноз очевиден, код фикса генерится легко, вся сложность в проведении и валидации изменения. Его аргумент за автоматизацию действия: «For AI to show its value, you need to automate action. If you have to keep pestering the humans to do things, you're not going to be successful». Это CEO, обосновывающий продуктовую траекторию своей компании.

Технически под это подложена собственная модель — Toto, foundation model для временных рядов. Причины две: общие LLM плохи в числах и особенно в time series, и модель должна быть маленькой, чтобы запускаться in-process на огромном числе рядов.

Обучали на собственных данных, где есть сигнал качества — видно, какие ряды используются для алертов и как часто на них смотрят. Первая, «наивно» построенная версия оказалась state-of-the-art, включая не-observability задачи, — это заявление вендора без ссылки на бенчмарк, в открытый доступ модель не выкладывали. Цель — сдвиг от детекта к опережению: «этот монитор сработает через час, потому что растёт очередь запросов к базе», причём правило не закодировано, модель выучила связь.

Полезный контринтуитивный результат оттуда же: модели, обученные под конкретного крупного клиента, пока работают хуже широких. Данные у клиентов разнообразные, но компоненты общие (MySQL, Postgres) и имена метрик семантически похожи. Плюс продуктовое ограничение: ценность должна быть видна в первый день.

Две вещи, которые ломают петлю снаружи

Prompt injection через логи и трейсы — это не теория. Помель говорит, что инъекции уже наблюдались (раньше это был XSS через лог). С LLM поверхность размывается: control plane и data plane слиты, всё, что пришло, фактически исполняется моделью. Плюс автофикс требует генерации и исполнения кода — двойной риск. Вывод: жёсткий sandbox и defensive coding для всех входящих данных, и сквозных end-to-end моделей в этой области не будет — нужны проверки на каждом шаге. «It's good habit to imagine that anything that processes external data might end up executing untrusted code». Его аналогия: «open S3 bucket» новой эпохи — это промпт в чате.

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

Обратная связь не в диф, а в систему

Последний кусок — правило Йегги и Нокса (Tessl, вендор). Прежде чем оставить комментарий агенту, инженер обязан хотя бы раз отмотать назад и изменить скилл, тест или архитектуру так, чтобы ошибка не возникла, и перезапустить. Если со второго раза не получилось one-shot — тогда можно комментировать.

Это то же движение, что у Кормака после инцидентов («какие тесты поймали бы это?») и у Уолтер со скиллами: обратная связь идёт в систему, а не в конкретный диф. Оговорка Tessl: фабрика бит-ротится, на её гигиену закладывают отдельные роли и токены. Их цели — no human-written code и no interactive coding sessions; «no human code review» назван долгосрочной целью, ещё не достигнутой.

Коротко

• Дефицит при инциденте — не в данных, а в сведении картины. Ответ incident.io (вендор): агент начинает расследование до прихода дежурного; 700 000 инцидентов накопительно, ~1500 клиентов.
• Пост-мортем становится структурированными данными, а не текстом: сервисы, команды, PR, Slack, таймлайн как объекты. Чтобы агент писал в структуру, структура должна себя объяснять. Blameless-принцип агентами не смягчается.
• Runtime intelligence сужает область до функции, потом достаёт глубину (Уолтер, Hud — вендор). Инверсия вопроса — «что сломается, если я трону эту функцию» — недооценена сильнее всего.
• Автоматические PR провалились у Hud. Убеждать надо человека, а не агента: «он всегда считает, что токены того стоят». Плюс два антипаттерна — plausible but unverified и lazy fix.
• 90% — не автоматизация, а ускорение человека. Эта планка совпадает с эмпирикой Datadog про два false positive подряд: доверие обваливается, а не деградирует плавно.
• Петля замыкается только через действие, и там же вылезают prompt injection через логи и трейсы и вопрос ответственности — обе проблемы Помель считает нерешёнными.

Новый контур обратной связи

Если свести весь материал к одному предложению, получится так: раньше наблюдаемость отвечала на вопрос «что сломалось», теперь она отвечает на вопрос «что мы вообще построили» — и это разные контуры, с разными требованиями к точности.

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

Порядок сборки

0. Фундамент — телеметрия, которую поймёт агент

• 0.1 OTel-нативно, без конвертации в проприетарный формат. Модели понимают трейсы из спецификации, а не из данных (Новакович, Dash0 — вендор). Кастомные имена = налог на каждый запрос.
• 0.2 Теги. В OTel обязателен ровно один — service.name. Pod name / host name проставлять принудительно (k8s-оператор + авто-инжект инструментации).
• 0.3 Collector: мультисинк + скрабинг PII до отправки. В спанах агента лежат промпты и ответы — это уже персональные данные, а не логи (Помель, Datadog — вендор).

1. Агентный прогон — что писать (Газит, Traceloop — вендор)

• 1.1 Logs — промпты, completions, вызовы функций (содержимое целиком).
• 1.2 Metrics — token usage, latency, error rate.
• 1.3 Traces — весь многошаговый прогон + каждый шаг отдельно.
• 1.4 RAG — retrieval отдельно: запросы, индексы, векторы, scores.
• 1.5 system_fingerprint — чтобы отличать дрейф провайдера от собственной регрессии.

2. Доказательство — то, что заменяет покрытие (Кормак, не вендор)

• 2.1 Внешний оракул: живая система или зафиксированная вне репозитория модель поведения. НЕ написанный тем же агентом — это тавтология.
• 2.2 Mutation testing поверх покрытия; отчёт читает агент, действовать напрямую не даём — много false positives (Нокс, Tessl — вендор).
• 2.3 Типы там, где они убивают класс багов целиком.
• 2.4 AI security review по всему состоянию кода, а не только по PR.
• 2.5 Оценка агента — только на закрытом и свежем. Публичное демо измеряет память модели (кейс Dash0 на OTel-демо).

3. Prod-to-code — обратная связь (Уолтер, Hud — вендор)

• 3.1 Маппинг на уровне функций: частота, длительность, падения.
• 3.2 Сначала сузить область функцией, потом доставать глубину. Модель разбирает один трейс и не разбирает миллион.
• 3.3 Triage как tool через MCP, а не как «дадим больше контекста».
• 3.4 Скиллы с методологией (HTTP 500, утечка памяти, деградация), чтобы не платить токенами за переоткрытие известного.

4. Действие — замыкание петли

• 4.1 Стартовать с узкого класса, где уверенность максимальна: высокая precision ценой низкого recall (Помель — вендор).
• 4.2 Начинать с 500-х после релиза: диагноз очевиден, сложность — в проведении и валидации изменения.
• 4.3 Sandbox и defensive coding для всех входящих данных. Логи и трейсы — вектор prompt injection, это уже наблюдалось.
• 4.4 Обратная связь идёт в систему: сначала почини скилл, тест или архитектуру и перезапусти, и только со второго раза комментируй диф (Йегги + Нокс, Tessl — вендор).

Шаги 0–1 стоит делать в любом случае. Шаг 2 — там, где агент пишет значимую долю кода. Шаг 3 окупается на кодовых базах со стажем (у Hud N+1 запрос прожил шесть лет в пятнадцатилетней базе). Шаг 4 — последний, и его стоит держать узким дольше, чем хочется.

Что мерить

Что	Зачем	Откуда цифра
Token usage на прогон и на класс задач	Токены — единица работы фабрики; качество = ручка расхода	Йегги; Газит (метрики)
Смена system_fingerprint при том же имени модели	Отделить дрейф провайдера от своей регрессии	Газит, Traceloop — вендор
Доля валидных находок автоматики	Ниже порога — автоматику выключают навсегда	Кормак: ~3/4 у security review; Помель: два false positive подряд
Дельта до и после фикса (P90 против выбросов)	Проверить, что чинили бутылочное горлышко, а не то, что рядом	Уолтер: 100 мс против 45 с, ожидание 30–40%
Судьба каждой находки: посмотрели / тикет / PR	Единственный способ узнать, что автоматику вообще читают	Уолтер: обе ветки размечены
Что тесты поймали при мутации	Покрытие не доказывает ничего, мутация — доказывает	Нокс, Tessl — вендор
Свежесть корпуса пост-мортемов	Ценность появляется только на накопленном	Мерлин, incident.io — вендор

Чего в материале нет и придумывать не надо: измеренной экономии времени от агентной наблюдаемости, честного бенчмарка precision AI SRE-агентов, подтверждённой цифры «90% вендоров конвертируют OTel». Всё это оценки спикеров.

Где ставить человека

Три места, и они выводятся из провалов, а не из принципов.

Первое — генерация гипотез. Кормак прямо разделил: человек читает документацию и спрашивает «а это правда?», находя края; агент этого не умел. Зато агент отлично проверяет подсказанные гипотезы и типовые края — 0, 1, 10001. Гипотезы твои, объём проверок его.

Второе — решение «стоит ли это внимания». Провал автоматических PR у Hud: агент всегда считает, что токены того стоят, поэтому убеждать надо человека. Список из 700 issues — это список, на который смотрят и решают не начинать.

Третье — приёмка автоматического действия, пока precision не доказана на твоих данных. Планка Уолтер (90% — это не автоматизация, а ускорение человека) и эмпирика Помеля (два false positive подряд — и систему выключают навсегда) описывают один и тот же обрыв: доверие не деградирует плавно, оно обваливается. И то, и другое — риторические пороги вендоров, но они сходятся независимо.

Что человеку не обязательно делать — читать весь код. У Кормака 350 000 строк Rust, которые он не читал, и при этом две воспроизводимые 500-е ошибки, найденные в самом S3. Внимание тратится не на строки, а на границы: оракул, спека, приёмка.

Спор, который остался нерешённым

Тезис «большинство платформ наблюдаемости не переживёт агентную эру» так и не получил в этих докладах измеримого подтверждения. Новакович (Dash0) описывает риск своей же компании: ценность создаётся внутри агента, платформа остаётся хранилищем, а это гонка на дно по цене. Помель (Datadog) отвечает, что incumbent может выбирать классы задач и стартовать с высокой precision. Оба вендоры, оба описывают роадмапы.

Показательнее их обоих — трезвость Помеля в конце: категория AIOps существовала десять лет назад, и «AI» там был регулярками; Datadog первые десять лет намеренно не писал AI на сайте; технология «ещё не совсем там». И его личная строчка: «I haven't reached break-even yet. I'm still spending more time learning about it than it saves me». Это говорит CEO компании, которой выгодно утверждать обратное.

Финальная мысль

Классический контур выглядел так: спека, код, тесты, релиз, наблюдаемость. Наблюдаемость стояла в конце, как страховка на случай, если предыдущие шаги ошиблись.

Из материала складывается другая схема. У AI-приложения нет момента «оно работает» до прода (Помель). Тесты стали инструментом разведки, а не доказательством (Кормак). Кодовый агент не знает, как его код ведёт себя в реальности (Уолтер). Предмет наблюдения сместился с изменения на систему, которая изменения производит (Йегги: «not a given PR, but a system that produces PRs»).

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