OpenAI ускорила отправку изменений в Git почти в пять раз с Pando

Агент закончил правку, но тесты ещё не начались: сначала нужно отправить изменения и скачать код в окружение проверки. При десятках параллельных задач ожидание Git способно съесть часть выигрыша от быстрой генерации кода. История Pando полезна командам, которые наращивают число агентов и хотят понять, где искать следующую очередь.

Что показала OpenAI

В техническом разборе от 2 ноября OpenAI описала Pando, внутренний бэкенд Git. Компания сообщает о сокращении медианной задержки push почти в пять раз и раздаче почти петабайта Git-данных в сутки. Совместимость с клиентом и протоколом Git сохранилась.

В основе два решения: независимые обновления разных веток и повторное использование готовых пакетов данных при чтении. При этом чтение нескольких веток не гарантирует единый снимок всего репозитория на один момент времени. Pando работает внутри OpenAI; компания рассматривает способы поделиться технологией, но сроков выпуска не называет.

Для практики здесь важна граница измерения. Медиана push описывает типичную задержку одной операции. По ней нельзя вычислить, насколько быстрее команда выпускает продукт. Между отправкой изменений и релизом остаются тесты, ревью, исправления и согласования. Почти пятикратное ускорение этого участка само по себе не обещает такого же ускорения разработки.

Пример: агенты готовят несколько правок

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

Разделение работы по веткам позволяет рассматривать эти операции отдельно. Изменение поиска не обязано ждать обновления корзины только потому, что оба живут в одном репозитории. А повторная раздача готового пакета похожа на выдачу одинакового архива нескольким получателям: серверу выгодно использовать уже подготовленные данные. Это упрощённая иллюстрация двух принципов Pando, а не описание конкретной инфраструктуры магазина.

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

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

Что проверить у себя

Начать можно с замера одной полной задачи: от готовой правки до результата проверки. Разделите время на отправку изменений, получение кода, ожидание свободного исполнителя и сами тесты. Такой разбор покажет, какой участок действительно тормозит работу. Если основная задержка приходится на очередь тестов, замена Git-сервера даст ограниченный эффект.

Затем повторите замер при обычной и пиковой параллельности. Для команды важен момент, когда дополнительные агенты перестают сокращать время выполнения задач. Полезно смотреть и типичные задержки, и редкие долгие ожидания: именно последние способны задержать срочное исправление. Сравнивать результаты следует на одинаковых задачах и с одинаковым числом проверок.

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