PostHog выпускает код с огромной скоростью, и за последние месяцы этот темп только вырос благодаря внедрению LLM. Мы перешли от слияния 1354 PR в октябре 2025 года к более чем 6500 PR в октябре 2026 года на данный момент (рост более чем на 380%).
В задачу команды Developer Experience входит обеспечение максимально быстрого выпуска кода инженерами PostHog при одновременном балансировании качества кода и стабильности CI. На самом деле, у нас есть цель сделать создание 10 000 пулл-реквестов в месяц простым делом. Тем не менее, успевать за обслуживанием CI только за счет ручного наблюдения и реагирования сложно.
Поэтому мы вдохновились тем, как процессы выстроены в других отделах PostHog. В этом октябре 11% объединенных PR были автономными — это значит, что PostHog открыл их самостоятельно после того, как скаут (запланированный агент, который исследует данные вашего продукта) нашел то, с чем стоит поработать.
Мы увидели это и решили ответить тем же. Те же автономные агенты, которые увеличивают наш объем PR, могут помочь нам справляться с обслуживанием CI. Вот как мы всё это настроили:
Мы гордимся тем, что являемся проектом с открытым исходным кодом и используем GitHub для размещения нашего монорепозитория. Это означает, что большинство связанных с CI данных хранится на GitHub, и их можно оттуда запрашивать. Но частые запросы к этим данным приводят к исчерпанию лимитов (rate limits), да и в любом случае было бы крайне неэффективно постоянно запрашивать у GitHub в основном неизменяемые данные (например, объединенные PR и завершенные запуски воркфлоу за прошлую неделю). Прежде всего, PostHog — это продуктовая дата-компания! Поэтому мы решили перенести данные CI/CD в собственный продукт и посмотреть, какие функции и идеи мы сможем оттуда извлечь.
Для этого мы используем наш складской источник (warehouse source) GitHub, который непрерывно синхронизирует данные репозитория. В частности, нас интересовали данные о пулл-реквестах, запусках воркфлоу и задачах воркфлоу (workflow jobs).
Изначально мы рассматривали существующие сервисы для анализа данных CI и помощи команде DevEx в лучшем понимании поведения разработчиков и их проблем, но обнаружили, что большинство этих сервисов созданы вокруг измерения производительности инженерных команд. Нас это не совсем интересовало.
Вместо этого мы создали собственный внутренний продукт под названием Engineering Analytics. Его основное видение таково:
Это продуктовая аналитика, но «пользователи» — это пулл-реквесты, а «события» — то, что с ними происходит на пути к продакшену.
Это продуктовая аналитика, но «пользователи» — это пулл-реквесты, а «события» — то, что с ними происходит на пути к продакшену.
При создании этого инструмента мы воспользовались множеством готовых примитивов анализа данных, логики и визуализации, которые уже были разработаны для других продуктов PostHog. Мы опирались на их лучшие практики, просто добавив данные CI/CD и требования нашего собственного продукта.
Под капотом Engineering Analytics представляет собой тщательно подобранное представление по тем областям, которые волнуют команду DevEx: наша система CI, очередь слияния (merge queue) и тесты.
Помимо того, что это удобное место для инженеров, где можно быстро получить общее представление о состоянии CI, мы с самого начала включили поддержку MCP, чтобы наши агенты могли запрашивать конкретные данные при расследовании проблем с CI или в поиске возможностей для оптимизации. Таким образом, агентам не нужно полагаться на GitHub API, и мы можем лучше контролировать данные и агентские сценарии. Это также позволяет нам создавать и использовать специальные skills инструменты, подобные investigating-ci-failures, которые помогают агентам находить коммит, сломавший определенную задачу CI, а затем проверять, исправил ли ее более поздний коммит.
Engineering Analytics интегрируется с возможностями автономности PostHog и генерирует собственные «сигналы» (выводы вместе с подтверждающими данными), которые агенты затем исследуют автономно и потенциально пытаются исправить путем открытия пулл-реквестов.
Эти сигналы генерируются с помощью трех детерминированных детекторов, которые работают с полученными данными GitHub (каждый представляет собой уже готовый запрос):
- Нестабильная проверка (Flaky check): задача, которая завершается с ошибкой, а затем успешно проходит при перезапуске того же коммита.
Нестабильная проверка (Flaky check): задача, которая завершается с ошибкой, а затем успешно проходит при перезапуске того же коммита.
- Сломанная ветка по умолчанию: воркфлоу, который продолжает давать сбои в нашей основной ветке.
Сломанная ветка по умолчанию: воркфлоу, который продолжает давать сбои в нашей основной ветке.
- Регрессия длительности: воркфлоу, который стал работать медленнее, чем в предыдущем периоде.
Регрессия длительности: воркфлоу, который стал работать медленнее, чем в предыдущем периоде.
Эти детекторы привели к реальным исправлениям, таким как:
- Исправление падающей задачи CI: шард WebKit Storybook завершался с ошибкой при каждом пуше в нашу ветку по умолчанию.
- Устранение нестабильности задачи тестов Rust: задача давала сбой дважды за неделю (два теста конкурировали за общее состояние трассировки).
- Ускорение проверки на каждом пулл-реквесте: задача воркфлоу устанавливала все рабочее пространство перед сухой прогонкой (dry run), которая на самом деле не требовала никаких зависимостей. После исправления вся задача занимает 33 секунды (вместо 51 секунды).
Благодаря Engineering Analytics в сочетании с автономностью мы выпустили с тех пор более десятка связанных улучшений.
Поиск правильного соотношения сигнала и шума требует определенных экспериментов и тонкой настройки промптов. Для нас наличие детерминированных детекторов помогло удерживать агентов, работающих на сигналах, в рамках данных, которые, как мы знаем, важны для нас и которые мы ожидаем постоянно обрабатывать.
Помимо полезности подхода с приоритетом MCP, интерфейс Engineering Analytics завоевал популярность внутри команды DevEx, в первую очередь как универсальное решение («one-stop shop»), где мы можем получить полезный обзор всех контролируемых нами областей одним взглядом. Из-за этого мы работаем над оптимизацией производительности продукта путем перехода от нерегулярных (ad-hoc) запросов к предварительно вычисленным таблицам и оптимизации запросов везде, где это возможно. В качестве приятного бонуса от того, что UI и MCP используют общий слой запросов, оптимизации здесь также идут на пользу производительности агентов, обращающихся к этим инструментам.
Наконец, как только мы загрузили данные GitHub и связанные с ними данные CI, команда придумала и другие способы создания полезных функций на их основе. Например, недавно мы выпустили функцию «CI Explorer», которая визуализирует наши CI-воркфлоу в виде графиков. Это гораздо более интуитивно понятно (не говоря уже о скорости), чем щелкать по статичному интерфейсу GitHub.
Мы продолжаем формировать Engineering Analytics как внутренний бета-продукт, но вы уже сегодня можете создать что-то подобное, объединив источники хранилища (warehouse sources) с нашим MCP и скаутами. Для этого:
- Загрузите данные CI в хранилище. Подключите источник GitHub и синхронизируйте таблицы пулл-реквестов, запусков воркфлоу и задач воркфлоу. Добавьте вебхуки, чтобы поддерживать запуски и задачи в актуальном состоянии в реальном времени.
Загрузите данные CI в хранилище. Подключите источник GitHub и синхронизируйте таблицы пулл-реквестов, запусков воркфлоу и задач воркфлоу. Добавьте вебхуки, чтобы поддерживать запуски и задачи в актуальном состоянии в реальном времени.
- Позвольте вашему агенту делать запросы к ним. Подключите своего агента (или агентов) к MCP PostHog и попросите его найти что-то конкретное, например, какой CI-воркфлоу замедлился на этой неделе.
Позвольте вашему агенту делать запросы к ним. Подключите своего агента (или агентов) к MCP PostHog и попросите его найти что-то конкретное, например, какой CI-воркфлоу замедлился на этой неделе.
- Сделайте систему автономной. Настройте автономный режим и подключите приложение GitHub, чтобы агенты могли открывать пулл-реквесты от вашего имени. Затем попробуйте написать скаут, который следит за вашими недавно синхронизированными таблицами. В качестве отправной точки рассмотрите что-то вроде наших детерминированных детекторов, но в документации есть и другие идеи для пользовательских скаутов.
Сделайте систему автономной. Настройте автономный режим и подключите приложение GitHub, чтобы агенты могли открывать пулл-реквесты от вашего имени. Затем попробуйте написать скаут, который следит за вашими недавно синхронизированными таблицами. В качестве отправной точки рассмотрите что-то вроде наших детерминированных детекторов, но в документации есть и другие идеи для пользовательских скаутов.
Ваша CI/CD-платформа уже собирает все эти данные. Почему бы не заставить их работать на вас!
