ИИ-агенты начали менять код в OpenAI с такой скоростью, что прежняя система контроля версий перестала выдерживать нагрузку. Компания создала собственный бэкенд Pando, совместимый с Git, и перевела на него весь внутренний монорепозиторий. После миграции медианная задержка при отправке изменений сократилась почти на 80%, а новая инфраструктура научилась раздавать около петабайта Git-данных в сутки.
Проблемы появились из-за роста параллельной разработки с помощью Codex. Один инженер теперь может одновременно готовить несколько изменений, отправлять каждое на проверку и запускать связанные задания непрерывной интеграции. Каждый процесс создает дополнительные push, fetch, clone и merge, поэтому нагрузка растет значительно быстрее числа разработчиков. К концу 2025 года внутренняя Git-инфраструктура OpenAI уже не успевала обслуживать поток операций, а надежность слияний временами опускалась ниже 90%.
OpenAI решила сохранить привычный протокол Git и стандартные клиенты, но полностью перестроить серверную часть. Pando масштабирует записи по горизонтали и позволяет множеству клиентов одновременно отправлять изменения в разные ветки. Компания отказалась от требования показывать всем клиентам единый снимок состояния всего репозитория в каждый момент времени. Вместо глобальной согласованности Pando поддерживает причинно-следственную согласованность и строгий порядок изменений внутри каждой отдельной ветки.
Практический компромисс выглядит следующим образом: две независимые ветки могут обновляться параллельно и не блокировать друг друга, однако клиент при одновременном чтении нескольких веток способен увидеть состояния из немного разных моментов времени. Для разработчиков и ИИ-агентов важнее другое свойство: после push новое изменение сразу доступно для последующего чтения, а конфликт возникает только при одновременной попытке изменить одну и ту же ветку.
Масштаб внутреннего репозитория сделал дорогостоящей даже обычную передачу списка веток. В OpenAI накопились миллионы веток, а полный набор Git-ссылок может занимать больше 100 МиБ. Pando поэтому не показывает клиенту все refs перед каждой отправкой изменений. Сервер обычно предоставляет только основную ветку trunk, относительно которой клиент формирует новый пакет данных.
Ограничение немного увеличивает размер отдельных push, зато делает содержимое пакетов предсказуемым и пригодным для повторного использования. В монорепозитории OpenAI медианный размер пакета при таком подходе оказался меньше 20 КиБ, а 99-й процентиль не превышал 3 МиБ. Для компании дополнительный сетевой трафик оказался выгоднее постоянной генерации уникальных наборов данных на сервере.
Обычный Git-сервер при fetch определяет, какие объекты уже есть у конкретного клиента, собирает недостающие данные и формирует новый pack-файл. Подобная операция расходует процессорное время и плохо кэшируется. Pando сохраняет полученные pack-файлы как неизменяемые объекты в общем blob-хранилище, а затем повторно раздает подходящие пакеты другим клиентам. Для загрузки нескольких пакетов используются packfile URI, предусмотренные протоколом Git.
Региональные серверы кэшируют Git-пакеты рядом с клиентами. Доля попаданий в локальный кэш превышает 99%, поэтому большая часть запросов не требует повторного чтения центрального хранилища или новой упаковки объектов. На стандартных виртуальных машинах облачных провайдеров OpenAI смогла полностью загрузить сетевые соединения скоростью 10 Гбит/с при операциях clone и fetch.
Количество небольших пакетов при активной разработке быстро растет, поэтому Pando периодически объединяет накопившиеся данные в более крупные наборы. Механизм напоминает уплотнение в LSM-деревьях: свежие пакеты попадают на начальный уровень, затем фоновые процессы группируют их в последовательные уровни вплоть до L4. Уплотнение улучшает сжатие и одновременно ускоряет поиск нужного набора данных при fetch.
Архитектура уже прошла проверку реальной нагрузкой. Pando обслуживал более 57 ТБ Git-пакетов за один час, причем свыше 99% трафика поступало из локального дискового кэша. Для передачи почти петабайта данных в сутки серверной части, по оценке OpenAI, достаточно нескольких процессорных ядер. Увеличивать пропускную способность можно добавлением серверов Pando, узлов хранилища метаданных и blob-хранилищ без общего узкого места для всех веток.
На создание Pando ушло 10 недель, а производственный трафик система начала обслуживать в апреле 2026 года. Архитектуру ядра спроектировал один инженер, реализацию выполняли команды ИИ-агентов, а внедрением занималась небольшая группа специалистов. Бэкенд написан на Rust без старых зависимостей, а совместимость со стандартным Git проверялась отдельным набором тестов и детерминированными симуляциями, предназначенными в том числе для поиска гонок и ошибок при планировании пакетов.
OpenAI привлекла ИИ и к проверке самой архитектуры. Агенты на базе GPT-6 Astra использовали TLA+ и Lean для формальной верификации свойств Pando, поиска ошибок и доказательства отдельных характеристик системы. Некоторые непрерывные сеансы проверки продолжались сотни часов. Дополнительно агенты круглосуточно тестируют Git и Pando в поисках пограничных сценариев и проблем безопасности.
Pando остается внутренним продуктом, однако работа уже затронула обычный Git. OpenAI ведет публичный форк проекта и передает универсальные улучшения разработчикам основной версии. Среди изменений появились параллельная загрузка и индексация pack-файлов, дополнительная диагностика сетевых задержек, более надежное восстановление прерванных загрузок и механизм explicit haves, позволяющий точнее описывать объекты, которые клиент уже может не включать в отправляемый пакет. Часть патчей уже попала в основной Git, остальные разработки OpenAI публикует в отдельном трекере.
Исходный код самого Pando пока не опубликован. OpenAI изучает способы предоставить связанные технологии внешним пользователям и рассматривает новые сценарии, где большие группы ИИ-агентов одновременно изменяют общий репозиторий. Опыт компании показывает новую проблему агентной разработки: инфраструктуре контроля версий приходится масштабироваться уже не под скорость работы команды программистов, а под тысячи параллельных операций, которые программные агенты способны создавать практически непрерывно.
