企業のコーディングエージェントが大規模にブランチを開き、ジョブを並行して走らせ始めると、誰も気に留めないツールチェーンの地味な部分、すなわちバージョン管理が、壊れる箇所になります。OpenAIは、まさにそれが自社のGitサービスに起きたとし、その答えはゼロから新しいバックエンドを作ることでした。ここで有用な合図はツールそのものではなく、負荷の型です。自分たちの継続的インテグレーションやバージョン管理でエージェントを拡大するどのチームも、これに出くわします。
圧力はCodexから来ました。Codexによって、OpenAIの技術者はいちどにはるかに多くの作業ができるようになりました。より多くのブランチ、より多くのpush、開発環境や研究ジョブ、CIからのより多くのfetchです。昨年末ごろから、モノレポを支えるシステムは苦しみ、信頼性は時に90%を下回り、push mergeが遅くなったり失敗したりしました。OpenAIはGitを捨てる代わりに、使い慣れた作業の流れを保ち、その下のバックエンドを作り直し、その成果をPandoと名づけました。設計上の目標は、多くのブランチへの書き込みを同時に拡張し、同じ履歴を多くの読み手にキャッシュから提供することでした。
報告された結果は相当なものです。Pandoは中央値のpushの遅延をほぼ80%減らし、今では1日に1ペタバイト近くのGitデータを提供し、1時間で57テラバイト超、そのバイトの99%超がローカルディスクのキャッシュから来ています。OpenAIはこれをレガシー 依存のないRustで作り、着手から本番まで約10週間で進み、Codex自身と複数のモデルが作業の多くを担ったとしています。4月に本番トラフィックの処理を始めました。
私たちにとっての意味は、製品ではなく型です。Pandoはオープンソースではないので、ほとんどのチームは採用できません。公開されているのは、OpenAIがGitに還元したクライアント側の改善だけで、同社自身のforkを通じてです。つまりこれは、ツールというより警告として読めます。Gitを取り巻くシステムは20年にわたる人間の作業の流れによって形づくられており、エージェントの群れは、それらのツールが想定していなかった仕方でそれらを押し広げます。
率直な注意点は、提供元のエンジニアリング記事によくあるものです。信頼性と遅延の数字はOpenAI自身のもので、独立に検証されておらず、一つの非常に大きなモノレポに合わせたバックエンドは、より小さい、あるいは形の異なるリポジトリには当てはまらないかもしれません。それでも、より多くのチームが自社のコードベースにエージェントを向けるにつれ、機械の並行作業がCIやバージョン管理を新しい仕方で圧迫するという教訓は、自分たちのmergeの失敗として現れる前に真剣に受け止める価値があります。当サイトでは、そもそもこの負荷を生んだエージェントであるOpenAI Codexをレビューしています。