# Datadog построил «универсальный станок» для агентов Claude Code
Канонический URL: https://zero2claude.ru/blog/datadog-temper-universal-machine-tool
Дата: 2026-07-21
Теги: claude-code, агенты, enterprise, автоматизация
Как в Datadog придумали Temper — систему, где агенты Claude Code пишут не код, а проверяемые спецификации, из которых детерминированное ядро собирает работающие сервисы.
Представь, что твоя команда разработки внезапно выросла втрое, но новые «сотрудники» — это агенты, которые пишут код днями без остановки и без единого перерыва на кофе. Именно так выглядит инженерия в Datadog: практически все инженеры компании используют ИИ для продакшен-кода, и как минимум две трети этой работы приходится на Claude Code. С такой скоростью генерации кода возникает неожиданная проблема — не «как заставить агента писать больше», а «как убедиться, что написанное безопасно запускать».
## Чем занимаются агенты в Datadog
В Datadog выделили четыре категории задач, где Claude Code реально помогает:
- **Точечные правки** — десятки неприятных багфиксов, оптимизаций производительности, мостиков между сервисами.
- **Крупные рефакторинги** — например, кастомный парсер protobuf переписали за три дня, а систему контроля метрик перевели с FoundationDB на Postgres менее чем за три месяца.
- **Замена крупных частей системы** — новые алгоритмы шардирования, переработка автомасштабирования.
- **Постройка целых систем с нуля** — замена MongoDB на Postgres, control-плейны BYOC, пайплайны приёма данных.
Чем дальше двигалась работа по этой карте, тем сложнее её становилось генерировать — и тем сложнее проверять. Это два разных измерения одной и той же проблемы, и именно тут начинается настоящая история Datadog.
## Проблема «потока»
Раньше поток работы инженера был линейным: понял задачу, написал код, протестировал, отревьюил, задеплоил, поддерживаешь — и по кругу. С агентами эта абстракция резко меняется.
«Ты больше не пишешь код — ты формируешь задачу для агента. Решаешь, что он должен видеть, какие инструменты у него есть, что считать успехом, как детектировать провал… Это как если бы всех инженеров разом повысили на три уровня в управленческой иерархии, о чём они, конечно, не просились», — говорит Сеш Налла, вице-президент по инженерии в Datadog.
С такими подходами, как Claude Managed Agents, сессии в Datadog теперь могут длиться днями. Каждый агент изобретает свои инструменты, свой связующий код, свои соглашения. Агенты становятся заметно полезнее, но людям приходится строить мосты между тем, что «наработал» агент, и инструментами, изначально созданными для людей.
## Станки как метафора
Здесь Сеш вспоминает про машиностроение. Станки — это тиски, кондукторы, калибры, фрезы, которые производят точные, повторяемые детали, из которых потом собирают что-то куда более сложное: двигатели, самолёты, реакторы, лунные модули. Именно станки стали прорывом индустриализации — детали стали составными, проверяемыми и заменяемыми.
Temper — это то, что Сеш описывает как попытку Datadog создать «универсальный станок» для агентных систем. Иными словами, минимальное ядро, необходимое агентам, чтобы строить нужные вещи безопасно и точно.
«Именно в этой точке я почувствовал, что нам нужно что-то более структурное. Если агенты будут строить и обслуживать крупные части наших систем, наших баз данных, критически важных для бизнеса, им нужен эквивалент концепции станка. Temper — это такой станок для Datadog», — объясняет Сеш.
## Дорога к Temper: три проекта-предшественника
Механизация означает, что агенты делают всё больше работы. Индустриализация — что эта работа становится повторяемой, проверяемой, управляемой и масштабируемой. В Datadog к этому шли не одним прыжком, а через три проекта, каждый из которых обнажал новое узкое место.
| Проект | Год | Что это | Что выяснилось |
|---|---|---|---|
| Courier | 2024 | Распределённая система очередей, построена вручную целиком | Сложность не в деталях, а в наблюдаемости и проверяемости взаимодействий между ними |
| BitsEvolve | Сентябрь 2025 | Замкнутый контур эволюционной оптимизации: «совет» моделей генерирует варианты кода, каскад бенчмарков и тестов решает, что выживает | Эволюция хороша ровно настолько, насколько хороша среда обратной связи — она и стала бутылочным горлышком |
| Helix | — | Стриминговый сервис уровня Kafka, построен Claude Code почти самостоятельно, с одним человеком у штурвала | Готовую систему собрали за несколько дней, но доведение до продакшена всё равно требует людей и заняло намного больше времени |
По Courier Сеш вспоминает: «Сложность была не в постройке частей, а в том, чтобы сделать взаимодействия между ними наблюдаемыми, тестируемыми и проверяемыми. Мы применяли формальное моделирование и симуляцию, находили места, где ошибки были бы дорогими или трудно обратимыми, и повышали строгость именно там».
BitsEvolve дал Сешу первое ощущение, что части софта можно «выращивать, как живые организмы» — через вариацию, обратную связь и адаптацию. А про Helix он говорит с почти детским удивлением: «К нашему изумлению, за несколько дней у нас появилась полностью функциональная система уровня Kafka — и мы увидели возможность сделать её в 2–5 раз дешевле». Но операционная зрелость системы нарабатывается со временем и усилиями многих людей — этот процесс всё ещё продолжается.
Узкое место сдвинулось снова: агенты уже могли строить большие куски системы, но людям всё ещё приходилось координировать выпуск этой работы в продакшен через инструменты, придуманные для людей.
## Что такое Temper и как он переворачивает уравнение
Агенты производят код быстрее, чем любая команда способна вручную его проверить, и при этом ошибаются. Разрыв между тем, что генерирует агент, и тем, что проходит верификацию, — это именно та зона, где накапливаются сбои. Просто «обвязать» агента вокруг обычной кодовой базы — значит превратить проблему в вопрос пропускной способности, не решив саму брешь в верификации.
Temper разворачивает это уравнение: вместо кода приложения агенты производят **спецификации**. Ядро читает каждую спецификацию, проверяет её через четыре слоя анализа и само разворачивает систему, которую спецификация описывает. Поскольку спецификация — это одновременно и то, что доказывается, и то, что выполняется, между «проверено» и «работает» не остаётся расхождения.
«Temper меняет центр системы. Агенту больше не нужно постоянно изобретать несвязанные инструменты под каждую локальную задачу. Вместо этого он выдаёт точное описание намерения и области задачи — как спецификацию. Это станок в том же смысле, в каком кондуктор или ЧПУ-станок: ты задаёшь спецификацию нужной резьбы винта, и это исключительно повторяемо. На таких станках можно строить самолёты и другие сложные вещи», — говорит Сеш.
Каждая возможность в Temper описывается тремя контрактами:
- **Поведение** — состояния, переходы, предусловия и свойства безопасности, которые должны выполняться.
- **Контракт данных** — типы сущностей, их свойства и действия, опубликованные в машиночитаемом виде, чтобы агент мог узнать весь API без документации.
- **Авторизация** — по умолчанию всё запрещено, доступ выдаётся по скоупам, а отказы фиксируются как «отложенные решения», которые человек может одобрить и подгрузить в политику на ходу.
## Четыре слоя проверки
Прежде чем ядро загрузит спецификацию, она проходит через четыре независимых слоя проверки:
| Слой | Что делает |
|---|---|
| Символическое рассуждение | Доказывает, что каждое условие выполнимо, а каждый инвариант индуктивен |
| Исчерпывающий обход состояний | Посещает каждое достижимое состояние системы |
| Детерминированная симуляция | Прогоняет реальный код продакшена с внедрением сбоев по seed (потери, задержки, переупорядочивание, крэши) — сбой воспроизводится точно с тем же seed |
| Случайное property-тестирование | Прогоняет около тысячи псевдослучайных последовательностей действий и «сжимает» любое нарушение до минимального контрпримера |
На небольшой спецификации весь этот каскад проверок укладывается заметно меньше секунды.
## «Тёмный завод» для Helix
Термин «тёмный завод» популяризировал разработчик Саймон Уиллисон — это процесс, где агенты продолжают работать на «виртуальном цеху» без людей. В таком тёмном заводе для Helix Temper играет сразу три роли: он control plane для управляемых агентов (сессии, роли, очереди задач, жизненный цикл), слой построения инструментов, который связывает обычные SDLC-инструменты (Git, CI, деплой) с маленькими Temper-приложениями, и control API для самого Helix — поверхность жизненного цикла вокруг слоя данных, который выполняет рабочую нагрузку.
«Сюрпризом стало то, что это начало ощущаться шире, чем просто инфраструктура для агентов. Если приглядеться, большая часть софта — это просто управляющая логика вокруг API базы данных: состояния, политики изменения данных, переходы жизненного цикла, интеграции с внешними системами. Temper может быть универсальным в этом смысле — он применим к любому софту такой формы», — говорит Сеш.
## Почему не обойтись обычным CRUD-приложением
Резонный вопрос: зачем всё это, если Claude Code прекрасно умеет писать обычные CRUD-приложения на TypeScript или Python? Сеш отвечает так: в обычном CRUD-приложении управляющая логика размазана по маршрутам, ограничениям базы данных, сервисному коду, фоновым задачам и документации. Тесты и покрытие могут быть хорошими, но операционный режим — обычно в виде конечного автомата — существует в коде неявно, «между строк».
Temper делает этот конечный автомат явным. Агент производит точное описание, а не произвольный код. Шаг компиляции происходит вне модели — так же, как ты передаёшь код на Rust компилятору Rust. Таблица переходов — это данные, а не спагетти из управляющей логики, зарытой в сервисных методах. Агенты могут менять эту таблицу динамически, безопасно, и подгружать изменения на ходу без прохода через CI.
## Куда это ведёт
Идея Temper проста: каждый артефакт должен быть достаточно маленьким, чтобы уместиться в голове одного человека. Высоконадёжный софт — в авиации, в финансовых системах — строился по этому принципу десятилетиями, но добиться такой строгости силами людей для обычного софта было слишком дорого — до появления агентов.
Промышленная революция стала возможной, потому что станки сделали детали составными, проверяемыми и заменяемыми — и это позволило строить всё более крупные и сложные машины. «Если агенты могут строить софт автономно внутри таких дисциплинированных фабрик, возможно, нам не нужно останавливаться на тёмных заводах. Софт, построенный так, начинает ощущаться как организм, который мы можем выращивать, культивировать и развивать через обратную связь, отбор и адаптацию», — говорит Сеш.
Спроси себя: настоящее узкое место — генерация кода или его проверка? Скорее всего, второе — вкладывайся туда, а не в скорость генерации. Пусть агент отдаёт спецификации для управляющей логики, а не произвольный код, и держи компиляцию и доказательства вне модели. Вытащи конечный автомат из маршрутов и сервисных методов и сделай его явными данными. И главное — каждый сгенерированный кусок должен помещаться в голове человека, иначе всё возвращается к исходной проблеме.
Если ты только начинаешь разбираться, что вообще такое агенты и зачем им «песочницы» и ограничения, посмотри наш бесплатный курс zero2claude — там разбираются похожие идеи, только на простых примерах для новичков.
## Частые вопросы
Это система в Datadog, где агенты Claude Code не пишут код приложения напрямую, а составляют спецификации — точные описания того, как должна вести себя система. Специальное «ядро» проверяет эти спецификации через четыре уровня анализа и само разворачивает работающий сервис на их основе.
Потому что обычный код прячет управляющую логику по разным файлам — маршрутам, сервисам, фоновым задачам, — и её сложно проверить целиком. Спецификация делает эту логику явной и единой, а компиляция и проверка происходят вне языковой модели, что исключает разрыв между «что проверено» и «что реально запущено».
Термин, введённый разработчиком Саймоном Уиллисоном: это процесс, где агенты продолжают работать без людей на «виртуальном производстве» — как автоматизированный цех, только для софта.
Нет. Люди всё так же нужны — например, чтобы одобрять политики доступа и решения, которые Temper фиксирует как «отложенные». Идея не в исключении человека, а в том, чтобы проверка происходила системно и автоматически, а не вручную построчным ревью.
Если хочешь попробовать всё это руками — начни с бесплатного курса [«Claude Code и терминал: с 0»](/learn/code-terminal).
По мотивам статьи Anthropic «How Datadog built a "universal machine tool" for Claude Code». Пересказали по-русски для новичков.