Наблюдаемость LLM: 6 уроков от CTO Datadog

Урок 1: ИИ сломал старый формат ревью кода

Начнём с давления, которое запускает остальное: кода больше, чем кто-либо способен прочитать.

Лё-Кок прямо говорит, что старая модель — человек читает pull request построчно — не выдерживает столкновения с разработкой при поддержке ИИ. Тревога, которую он слышит по отрасли, связана с тем, что ревью становится невозможным: слишком много всего происходит, чтобы успевать за чтением PR.

Его ответ — не просить людей читать быстрее, а перенести ревью в другое место.

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

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

Урок 2: Продакшн — единственный тест, который важен

Пройти все тесты в CI необходимо, но этого далеко недостаточно. Важные сбои происходят позже.

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

С LLM это сложнее: в обычном коде вы хотя бы можете рассмотреть каждую ветку, а механистически объяснить, почему модель вернула тот или иной ответ, никто не может, так что одинаковый ввод не гарантирует одинаковый вывод. Случайные странности нельзя полностью «выинжинирить».

Поэтому вы перестаёте пытаться доказать корректность системы до релиза. Вместо этого вы

• Пишете оценки желаемого поведения,
• мониторите это в проде,
• держите под рукой стоп-контроль на случай неудачного раската.

Вопрос больше не в том, «прошло или нет», а в том, единична ли проблема или это начало тренда.

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

Урок 3: Пусть агенты возьмут на себя рутину

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

Разбор инцидента — это перебор гипотез к симптому, и при долгих инцидентах срабатывает часто самая невероятная. Агент Bits AI от Datadog проверяет их все параллельно, на шаг впереди инженера, а человек направляет его к догадке, которую никакой дашборд не подсветит.

Главный пункт — усталость. Дежурный релиз — это всплеск внимания, за которым следуют часы пустоты, и так по кругу, пока не притупляется суждение.

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

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

Урок 4: Разделите работу на два контура

Лё-Кок выстраивает работу агентов Datadog вокруг двух контуров.

Контур разработки

Большинство инженеров узнают первый контур:

1. Написать код
2. Выкатить
3. Проверить, работает ли
4. Исправить
5. Повторить

Фокус Datadog в том, что проблема, зародившаяся в коде, чаще всего и исправляется в коде, поэтому платформа старается сразу предложить фикс, опираясь на знания об приложении: владельцах, недавних изменениях и возникших ошибках.

Он приводит пример оптимизации запросов к базе. Любая модель способна переписать медленный запрос; сложнее доказать, что переписанный вариант быстрее и безопаснее до попадания в прод. Поэтому Datadog сначала тестирует его на реалистичной копии продовых данных и передаёт pull request с приложенными доказательствами.

Контур эксплуатации и безопасности

Второй контур работает параллельно — теми же людьми или другой командой:

1. Обнаружить
2. Расследовать
3. Устранить
4. Повторить

Здесь AI Guard от Datadog проводит триаж событий безопасности и блокирует атаки быстрее, чем аналитик вручную. Агенты также могут выполнять рутинные операционные задачи, которыми инженеры занимаются ежедневно без особого энтузиазма — например, изменить размер того самого пода в Kubernetes.

В обоих контурах Лё-Кок настаивает на порядке действий. Datadog не начинает с «вот ИИ, какую проблему он решит?». Он начинает с реальной проблемы, на которую уже жалуются клиенты — обычно в духе «я не хочу делать эту повторяющуюся вещь» — и дальше отвечает на вопрос, можно ли доверить это агенту.

Урок 5: Держите расходы на ИИ под контролем

Рядом с безопасностью сидит ещё одно ограничение — стоимость, и удержание цены введения LLM в эксплуатацию становится отдельной дисциплиной. Ответ Лё-Кока на DASH — Agent Console от Datadog.

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

Эти паттерны становятся эвристиками, а не жёсткими правилами: передовые модели, вроде новейших Claude Opus или моделей GPT, — для планирования; что-то недорогое, вроде Claude Haiku, — для генерации тестов.

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

Урок 6: Научитесь учиться

На вопрос, что должны изучать начинающие инженеры, Лё-Кок даёт ответ, который звучит по‑старому, но таким не является.

Модели — самые терпеливые наставники из когда‑либо созданных, способные объяснить что угодно и в любом темпе — доступ, который раньше был привилегией монархов с личными гувернёрами. Но наставник полезен лишь тогда, когда вы его допрашиваете. Навык — знать, что спросить и как проверить ответ.

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

• Что означает этот термин?
• Как это измерить?
• Какая математика за этим стоит?
• Как понять, что это работает хорошо?

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

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

Заключение

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

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

Навык, которого требует такой взгляд от инженеров, очевиден: читать системы по тому, как они ведут себя в проде, а не только по исходникам. Если хотите сформировать эту привычку, наш скилл-трек Machine Learning in Production — хороший старт.