OpenAI si kvůli AI agentům přestavěla jednu z nejméně nápadných, ale nejdůležitějších částí vývoje: backend pro Git. Ne proto, že by Git náhle neuměl ukládat kód. Problém je, že ve chvíli, kdy jeden vývojář řídí několik agentů a každý z nich připravuje vlastní změny, začne být úzkým hrdlem samotná infrastruktura kolem repozitáře.
Rychlá zpráva o OpenAI a systému Pando popisuje změnu, která na první pohled vypadá jako další interní optimalizace. Ve skutečnosti ukazuje něco podstatnějšího: agentická éra nebude znamenat jen více kódu. Bude znamenat také úplně jiný tlak na nástroje, které ten kód přijímají, ukládají, porovnávají a distribuují.
Git už neškáluje podle počtu lidí
Klasický vývojový tým má přirozené limity. Lidé připravují změny postupně, kontrolují si navzájem práci a do hlavní větve posílají jen část rozpracovaných pokusů. AI agenti tento rytmus rozbíjejí. Jeden člověk může nechat několik agentů hledat řešení paralelně, spouštět testy v různých větvích a připravovat další iterace dřív, než vůbec stihne projít první výsledek.
OpenAI ve svém technickém popisu systému Pando tvrdí, že právě Codex změnil měřítko práce v jejím monorepu. Přibylo současných větví, pushů, merge operací, stažení repozitáře i běhů CI. Firma uvádí, že její dosavadní systém se při tomto zatížení potýkal s pomalými pushi a fetchi, neúspěšnými merge operacemi a obdobími, kdy spolehlivost klesala pod 90 procent.
Tohle číslo není nezávislý audit Git serverů ani obecná statistika pro celý obor. Je to popis vlastního provozu OpenAI. Přesto je důležitý, protože ukazuje, kde se problém objeví jako první: ne u psaní další funkce, ale u koordinace tisíců současných změn.
Pando není nový Git. Je to nový způsob, jak ho obsloužit
Pando je nový backend pro Git repozitáře, který má zachovat kompatibilitu s Git protokolem i běžným klientem. Vývojář ani agent tak nemusí kvůli serverové změně přepisovat své pracovní návyky. Změna se odehrává pod nimi, v tom, jak server ukládá packfile, aktualizuje odkazy na větve a obsluhuje čtení historie.
Podle OpenAI Pando v produkci snížil medián latence pushů téměř pětinásobně a denně doručuje skoro petabajt Git dat. I tady je potřeba držet se přesné formulace: jde o čísla, která zveřejnila sama OpenAI na základě svého provozu a vlastních měření. Nejde o srovnávací benchmark, který by nezávisle potvrdil, že Pando je obecně rychlejší než každý jiný Git server.
Technický trik je v zásadě prostý, i když jeho provedení jednoduché není. Pando aktualizuje nesouvisející větve odděleně, takže push do jedné větve nemusí čekat na push do jiné. Při čtení navíc znovu používá existující packfile místo toho, aby pro každého klienta vyráběl novou odpověď od začátku.
To je rozdíl mezi systémem navrženým pro několik desítek lidí a systémem navrženým pro tisíce současných zapisujících klientů. V případě OpenAI jsou těmi klienty nejen vývojáři, ale také automatizované procesy a agenti, kteří pracují rychleji a bez přirozených přestávek lidského týmu.
Cena za rychlost: historie už nemusí ukazovat jediný okamžik
Nejzajímavější část Pando není samotná optimalizace. Je to přiznaný kompromis. OpenAI opouští představu, že celý repozitář musí při každé operaci představovat jeden dokonale konzistentní okamžik. Místo toho používá model kauzální konzistence, který hlídá návaznost změn na jednotlivých referencích, ale nevnucuje jednu globální časovou osu všem větvím najednou.
Prakticky to znamená, že klient, který ve stejnou chvíli čte dvě různé větve, nemusí dostat jejich stav ze stejného okamžiku. Pando podle popisu OpenAI garantuje návaznost na konkrétní větev a princip read-your-own-write, ale neposkytuje bodový snímek všech referencí v celém repozitáři.
Pro běžný vývoj je to možná rozumná výměna. Agent, který pracuje na vlastní větvi, obvykle nepotřebuje filozofickou jistotu, že každá jiná větev na světě ukazuje přesně stejný okamžik. Potřebuje rychle zapsat změnu, znovu si ji stáhnout, spustit testy a pokračovat.
Pro některé provozní procesy ale tato hranice důležitá být může. Pokud nástroj staví rozhodnutí na globálním pohledu přes více větví nebo očekává jedinou konzistentní podobu repozitáře, musí s tímto modelem počítat. Rychlost se nekupuje zadarmo; část jistoty se přesouvá z automatické vlastnosti systému na pravidla konkrétního workflow.
Agentům nestačí více tokenů. Potřebují infrastrukturu, která je udrží v tempu
V debatách o AI agentech se často řeší model, kontextové okno a cena za token. To jsou viditelné parametry. Pando připomíná méně pohodlnou skutečnost: když agenti skutečně začnou pracovat paralelně, narazí na vrstvy, o kterých se v produktových demech skoro nemluví.
Budou potřebovat rychlejší repozitáře, více izolovaných pracovních prostředí, lepší cache, spolehlivější CI a přesnější audit toho, která změna vznikla kde. Když se deset agentů pokusí připravit deset různých oprav, problém není jen vybrat nejlepší patch. Problém je také uložit všechny pokusy tak, aby se systém nezhroutil dřív, než se k nim člověk dostane.
To navazuje na rozbor práce Codexu na bezpečnostních backportech Linuxu. Tam byla hlavní otázka, kdo zkontroluje výsledek a rozhodne o vydání opravy. U Pando se objevuje stejný problém o patro níž: kdo zajistí, že se všechny kandidátní změny vůbec dostanou bezpečně do procesu kontroly a že se v jejich historii nikdo neztratí.
Agentická práce tak nebude jen rychlejší verze práce lidského týmu. Bude mít jinou topologii. Větší počet paralelních větví, kratší životní cyklus jednotlivých pokusů a mnohem větší význam infrastruktury, která umí historii rozdělit bez toho, aby ji znečitelnila.
OpenAI mění server, ne pravidla odpovědnosti
Pando neřeší, jestli je změna kódu dobrá. Neříká, zda agent správně pochopil zadání, zda test pokrývá skutečné riziko nebo zda má člověk merge schválit. Řeší přepravu a uložení změn. To je důležitý rozdíl, protože rychlejší Git se velmi snadno začne zaměňovat za bezpečnější vývoj.
Ve skutečnosti může rychlejší infrastruktura zvýšit i cenu špatného rozhodnutí. Když systém dovolí vytvořit a rozeslat více změn za kratší dobu, zvětší se také fronta, kterou musí někdo kontrolovat. Automatizace proto nesmí měřit pouze počet pushů nebo počet hotových commitů. Musí sledovat, kolik práce se vrací, kolik změn skončí v odpadu a jak dlouho trvá cesta od návrhu k ověřenému výsledku.
Podobnou hranici jsme řešili také u delegování oprávnění mezi AI agenty. Identita ani technická dostupnost nástroje samy neříkají, zda agent směl konkrétní operaci provést. U Gitu platí něco podobného: existence commitu neříká, zda je změna správná, přijatelná nebo připravená pro produkci.
Git zůstane stejný hlavně pro člověka
OpenAI zároveň ukazuje, proč bude podobná infrastruktura důležitá i mimo její vlastní monorepo. Firma zveřejnila technické změny ve své kopii Gitu a veřejný repozitář openai/git staví jako místo, odkud chce část práce postupně vracet širší komunitě. Samotný repozitář ale není důkaz, že Pando je hotový univerzální produkt nebo že jeho architektura vyřeší všechny problémy ostatních týmů.
Pro uživatele Gitu je na celé věci nejzajímavější právě to, co neuvidí. Příkaz git push zůstane stejný. Větev bude stále větev a commit stále commit. Pod povrchem se ale může změnit způsob, jakým se jejich historie ukládá, replikuje a doručuje ostatním klientům.
To je ostatně typický znak důležité infrastruktury. Když funguje, není vidět. Teprve když se počet agentů znásobí a starý model obsluhy začne selhávat, zjistíme, že „AI software“ stojí na velmi obyčejných věcech: na frontách, discích, sítích, cache a pravidlech konzistence.
Pando proto není jen interní optimalizace OpenAI. Je to signál, že agenti tlačí vývojový ekosystém do další fáze. Nejdřív jsme jim dali možnost psát kód. Teď kvůli nim musíme přestavět systémy, které rozhodují, jak se ten kód pohybuje světem.
A tady je skutečný závěr: AI agenti nenahradí Git. Přinutí ho přestat předstírat, že vývoj probíhá postupně, v jednom rytmu a s jedním člověkem u každé změny. Budoucnost nebude jen o chytřejších agentech. Bude také o tom, zda infrastruktura unese jejich práci bez toho, aby zrychlila i chaos.
