Wenn die Coding-Agenten einer Firma anfangen, in großem Maßstab Branches zu öffnen und Jobs parallel laufen zu lassen, wird der stille Teil der Werkzeugkette, an den niemand denkt, die Versionsverwaltung, zu dem, was bricht. OpenAI sagt, genau das sei seinem eigenen Git-Dienst passiert, und seine Antwort war, ein neues Backend von Grund auf zu bauen. Das nützliche Signal hier ist nicht das Werkzeug selbst, sondern das Lastmuster, dem jedes Team begegnet, das Agenten in der eigenen Continuous Integration und Versionsverwaltung hochskaliert.
Der Druck kam von Codex, das OpenAIs Ingenieuren erlaubte, viel mehr auf einmal zu tun: mehr Branches, mehr Pushes, mehr Fetches aus Entwicklungsumgebungen, Forschungsjobs und CI. Ab Ende vergangenen Jahres kämpften die Systeme hinter dem Monorepo, mit einer Zuverlässigkeit, die zeitweise unter 90% fiel, also langsame oder fehlgeschlagene Pushes und Merges. Statt Git aufzugeben, behielt OpenAI den vertrauten Arbeitsablauf und baute das Backend darunter neu, der Ergebnisname ist Pando. Die Entwurfsziele waren, Schreibvorgänge über viele Branches zugleich zu skalieren und dieselbe Historie vielen Lesern aus dem Cache zu liefern.
Die berichteten Ergebnisse sind erheblich. Pando senkte die Latenz eines mittleren Pushes um fast 80% und liefert nun fast ein Petabyte Git-Daten pro Tag, mit über 57 Terabyte in einer einzigen Stunde und über 99% dieser Bytes aus dem lokalen Festplatten-Cache. OpenAI baute es in Rust ohne Altlasten-Abhängigkeiten und sagt, es sei in etwa 10 Wochen vom Start in die Produktion gegangen, wobei Codex selbst und eine Mischung von Modellen viel der Arbeit erledigten. Im April begann es, Produktionsverkehr zu bedienen.
Die Relevanz für den Rest von uns ist das Muster, nicht das Produkt. Pando ist nicht quelloffen, die meisten Teams können es also nicht übernehmen. Nur die clientseitigen Verbesserungen, die OpenAI an Git zurückgab, sind öffentlich, über den eigenen Fork, was heißt, dass sich dies eher als Warnung denn als Werkzeug liest: Die Systeme um Git wurden von zwei Jahrzehnten menschlicher Arbeitsabläufe geformt, und Schwärme von Agenten drücken sie auf Arten, für die diese Werkzeuge nicht ausgelegt waren.
Die ehrlichen Vorbehalte sind die üblichen für einen Engineering-Beitrag eines Anbieters. Die Zuverlässigkeits- und Latenzzahlen stammen von OpenAI selbst und wurden nicht unabhängig geprüft, und ein auf ein sehr großes Monorepo abgestimmtes Backend lässt sich nicht unbedingt auf kleinere oder anders geformte Repositorys übertragen. Dennoch lohnt es sich, während mehr Teams Agenten auf ihre Codebasen richten, die Lehre ernst zu nehmen, dass parallele Maschinenarbeit CI und Versionsverwaltung auf neue Weise belastet, bevor sie als eigene fehlgeschlagene Merges auftaucht. Wir rezensieren OpenAI Codex, den Agenten, der diese Last überhaupt erst erzeugte.