Přejít k navigační liště

Zdroják » Různé » Proč Anthropic ve svém monorepozitáři opustil Git? AI agenti změnili pravidla hry

Proč Anthropic ve svém monorepozitáři opustil Git? AI agenti změnili pravidla hry

Články ‐ ‐ Různé ‐

Anthropic nahradil Git ve svém hlavním monorepozitáři vlastním systémem Scion. Důvodem je prudký nárůst změn vytvářených s pomocí AI agentů: zatímco v květnu 2026 firma začleňovala přibližně 2 500 změn denně, v září jich bylo přes 30 000. Nový systém přesouvá správu historie na server, omezuje stahování nepotřebných dat a zrychluje přípravu kódu pro testování. Nejde však o univerzální náhradu Gitu.

Git patří mezi nejrozšířenější nástroje pro správu verzí softwaru už více než dvě desetiletí. Umožňuje vývojářům sledovat změny, spolupracovat na společných projektech a vracet se ke starším verzím kódu. Ani tak zavedený nástroj ale nemusí vyhovovat každému způsobu práce. Společnost Anthropic se dostala do situace, kdy množství kódu vytvářeného s pomocí AI agentů začalo přetěžovat infrastrukturu postavenou kolem Gitu.

Firma proto vyvinula vlastní systém pro správu verzí s názvem Scion a během pěti měsíců na něj převedla svůj hlavní monorepozitář. Sedmičlenný tým přitom využíval Claude nejen při běžném programování, ale také při optimalizaci samotného nového systému.

Nešlo jen o optimalizaci několika příkazů. Anthropic musel přehodnotit způsob, jakým se kód ukládá, jak se k němu dostávají testovací úlohy a jak se změny začleňují do společné větve. Případ ukazuje, že s rostoucím podílem automatizovaného programování se úzká místa vývoje mohou přesunout od samotného psaní kódu k infrastruktuře, která jej obsluhuje.

Počet změn vzrostl za čtyři měsíce dvanáctkrát

Rozsah problému nejlépe ilustrují čísla, která zveřejnila společnost Anthropic ve svém technickém článku Redesigning source control at Anthropic z 13. října 2026. V květnu firma začleňovala do svého hlavního repozitáře průměrně přibližně 2 500 změn denně. V září už jich bylo přes 30 000. Za čtyři měsíce tak objem začleňovaných změn vzrostl více než dvanáctinásobně.

Změny přitom nepřipravují jen lidští vývojáři. Claude dokáže samostatně upravovat programy, spouštět testy, hledat chyby a opakovaně vylepšovat vlastní řešení. V prostředí, kde pracuje velké množství agentů paralelně, může vznikat a být připraveno ke kontrole mnohem více změn, než na kolik byly tradiční vývojářské procesy stavěné.

Anthropic provozuje rozsáhlý monorepozitář, tedy jedno společné úložiště obsahující kód mnoha projektů a komponent. Historie hlavní větve má téměř 100 GB a komprimovaná pracovní kopie přesahuje 25 GB.

Dalším důležitým údajem je počet checkoutů, tedy operací, při kterých se připravuje konkrétní verze zdrojového kódu pro další práci. Samotná infrastruktura pro průběžnou integraci (CI) jich provádí přibližně 25 milionů denně. K tomu je potřeba připočítat vývojářská prostředí, izolovaná prostředí AI agentů a výzkumné úlohy.

Pokud by každý z těchto 25 milionů CI checkoutů stahoval kompletní komprimovanou kopii repozitáře, teoretický objem přenosů by přesáhl 600 petabajtů denně. Nejde o skutečně přenášená data, ale o ilustraci nákladů naivního způsobu stahování. Odhad navíc nezahrnuje další checkouty v prostředích vývojářů a AI agentů.

Proč Git přestal stačit

Zásadní problém nespočívá v tom, že by Git neuměl pracovat s velkými repozitáři. Jeho architektura ale vznikala pro jiný způsob práce, než jaký dnes Anthropic potřebuje.

Git je distribuovaný systém. Každý klon může obsahovat historii potřebnou k prohlížení změn, porovnávání verzí nebo práci bez připojení k serveru. To je pro běžné vývojáře velká výhoda: lokální počítač má potřebná data k dispozici a nemusí se při každé operaci spoléhat na vzdálenou službu.

U Anthropic je však situace odlišná. Velkou část klientů tvoří automatizované úlohy a AI agenti připojení k firemní infrastruktuře. Často nepotřebují celou historii repozitáře. Potřebují například sestavit a otestovat jedinou komponentu nebo zjistit, které soubory se změnily v konkrétní úpravě.

Přesto je nutné zajistit rychlý přístup ke správné verzi kódu a souvisejícím informacím. Při milionech operací denně se i relativně malá režie opakuje v obrovském měřítku.

Anthropic před nasazením Scionu využíval například:

  • mělké klony, které omezují množství stažené historie;
  • řídké checkouty, které zpřístupňují jen vybrané části repozitáře;
  • vzdálené načítání chybějících objektů;
  • snímky repozitáře uložené v objektovém úložišti;
  • interní Git zrcadla pro rozložení zátěže.

Tato řešení pomáhala, ale měla své limity. V nejvytíženějším období provozovala společnost několik set interních Git zrcadel. S rostoucím počtem změn bylo stále obtížnější udržovat je aktuální a zajistit správné fungování operací závislých na historii.

Místo dalšího vrstvení optimalizací se Anthropic rozhodl změnit samotný princip fungování systému. Pokud jsou téměř všichni klienti online a pracují automatizovaně, nemusí mít každý z nich kompletní lokální kopii historie.

Scion přesouvá těžiště na server

Scion je navržený jako systém, v němž server zastává mnohem aktivnější roli než v tradičním pracovním postupu s Gitem. Klienti mohou požadovat konkrétní data nebo informace o historii přímo od serveru, aniž by museli nejprve získat velkou část repozitáře.

Rozdíl je patrný zejména u automatizovaných úloh. Představme si, že AI agent upraví soubor tax.py v části aplikace odpovědné za fakturaci. Testovací úloha nemusí potřebovat kompletní historii všech projektů ve společném repozitáři. Scion může zpřístupnit potřebné soubory a metadata podle konkrétního požadavku.

Server zároveň obsluhuje operace nad historií, které by jinak vyžadovaly práci s lokálními daty. Klient tak nemusí vždy stahovat další objekty jen proto, aby zjistil, jak se určitá část kódu vyvíjela.

Důležitou součástí návrhu je také cachování. Scion využívá několik úrovní cache: lokální cache na stroji, sdílenou cache v daném regionu a centrální infrastrukturu. Pokud potřebná data už někde existují, není nutné je pokaždé znovu získávat ze vzdáleného úložiště.

Každá úroveň cache podle Anthropicu dosahuje úspěšnosti přes 99 %. Požadovaná data jsou navíc identifikována podle obsahu a po uložení se nemění. Jednotlivé servery je proto mohou sdílet bez nutnosti ověřovat, zda se mezitím změnila.

Cílem není pouze rychleji stáhnout celý repozitář. Ještě důležitější je omezit počet situací, kdy klient potřebuje celý repozitář vůbec stahovat. Některé automatizované úlohy mohou potřebné informace získat přímo přes serverové API, aniž by si připravovaly pracovní kopii na disku.

Změny se ukládají jinak než v Gitu

Rozdíl mezi Scionem a Gitem se týká také reprezentace historie. Git při vytváření commitu pracuje mimo jiné se stromem souborů, který popisuje obsah repozitáře v daném okamžiku. Stromy a objekty umožňují efektivní sdílení nezměněného obsahu, ale operace nad velkým množstvím změn mohou být v určitých pracovních postupech nákladné.

Scion používá záznamy změn neboli changesety, které popisují upravené soubory vzhledem k prvnímu rodičovskému záznamu. Záznamy se ukládají do protokolu změn (write-ahead log) a odkazují na komprimovaný obsah souborů v objektovém úložišti.

Výsledkem je, že vytvoření záznamu změny může vyžadovat práci úměrnou rozsahu samotné změny, nikoli velikosti celého repozitáře. Pro prostředí, v němž vznikají tisíce změn denně, jde o důležitý rozdíl.

Samotný changeset ale nestačí k rychlému zodpovídání všech dotazů na historii. Scion proto vytváří také odvozená data (derived data), která slouží například k rychlému zjištění, kdo naposledy upravil konkrétní řádek, nebo které změny ovlivnily určitý soubor. Tato data se mohou počítat průběžně nebo až ve chvíli, kdy jsou skutečně potřeba.

Scion zároveň omezuje závislost na globálním stavu. V tradičních systémech mohou být větve a tagy reprezentovány odkazy, jejichž změny musí infrastruktura koordinovat. Scion staví běžnou práci na změnových záznamech a snaží se omezit situace, kdy je nutná koordinace mezi servery.

Tento návrh ovšem znamená i větší závislost na serverové infrastruktuře. Vývojář nemá automaticky k dispozici stejnou míru samostatnosti, jakou poskytuje plnohodnotný lokální klon Gitu. Pro automatizované úlohy připojené k firemní infrastruktuře může být tato výměna výhodná, ale pro běžnou distribuovanou spolupráci nemusí dávat smysl.

Scion navazuje na zkušenosti Googlu a Mety

Scion nevznikl ve vakuu. Anthropic ve svém článku výslovně zmiňuje předchozí zkušenosti s rozsáhlými monorepozitáři, zejména systém Piper od Googlu a Sapling od Mety.

Konkrétně upozorňuje na serverovou část Saplingu nazvanou Mononoke, která přinesla řadu technik využitých také ve Scionu. Patří mezi ně i datový model Bonsai. Anthropic své vysvětlení této návaznosti doplnil do článku 15. října 2026.

Tato souvislost je důležitá: Scion představuje vlastní řešení Anthropic, ale jeho architektura navazuje na zkušenosti získané při provozu jiných systémů pro správu rozsáhlých repozitářů. Novinkou je především to, jak tyto principy kombinuje s potřebami prostředí, v němž velkou část práce vykonávají automatizovaní agenti.

Checkouty v sekundách a o čtvrtinu více kapacity CPU pro CI

Anthropic uvádí, že checkouty pro CI a výzkumné úlohy, které dříve trvaly minuty, se po zavedení Scionu zkrátily na sekundy. Celková infrastruktura Scionu navíc potřebuje přibližně dvousetinu kapacity CPU a paměti oproti předchozí infrastruktuře založené na Git zrcadlech.

Samotná CI podle firmy získala díky nové architektuře 25 % kapacity CPU. Jde o významnou úsporu, která se při tak velkém počtu automatizovaných úloh promítá do možnosti provozovat více testů a dalších úloh na stejné infrastruktuře.

Tato čísla je potřeba interpretovat v kontextu. Neznamenají, že Scion je ve všech operacích dvěstěkrát rychlejší než Git nebo že by běžný vývojář po přechodu na něj získal podobné zrychlení. Jde o srovnání infrastruktury, kterou Anthropic používal pro svůj konkrétní provoz, a výsledků dosažených při jeho neobvyklém měřítku.

Významný je především efekt v součtu milionů operací. U jednotlivého vývojáře může být rozdíl mezi dvěma způsoby checkoutu zanedbatelný. V prostředí, kde se kód připravuje pro desítky milionů checkoutů denně, se ale zbytečně opakované operace promítají do nároků na procesory, paměť, síť i úložiště.

Scion tak neřeší jen problém velkého množství zdrojového kódu. Řeší především velké množství opakovaných přístupů ke stejnému kódu, které vznikají při paralelní práci agentů a testovacích systémů.

Claude pomáhal Scion vyvíjet

Na projektu je pozoruhodné i to, jakou roli v jeho vzniku hrála samotná AI. Sedm inženýrů dokázalo během pěti měsíců vytvořit Scion, nástroj pro kontrolu kódu Antique a několik dalších souvisejících systémů.

Anthropic popsal případ, kdy raná interní verze modelu Claude Mythos Preview přepsala první verzi celé pipeline pro převod dat z Gitu do Scionu. Původní implementace vznikla převážně ručně. Model dostal za úkol přepsat celý systém a podle společnosti to zvládl bez dalších instrukcí.

Výsledná implementace spotřebovávala dvacetkrát méně paměti a byla čtyřikrát rychlejší, přičemž zachovala všechny důležité implicitní invarianty týkající se pořadí zpracování a datových struktur.

To ovšem neznamená, že model sám rozhodl o celé architektuře nebo že vývoj probíhal bez lidského dohledu. Inženýři stále určovali požadavky, posuzovali kompromisy a odmítali řešení, která sice mohla fungovat, ale obcházela zamýšlené principy systému.

Anthropic ve svém článku zdůrazňuje, že významnou část práce inženýrů tvořilo právě usměrňování modelu a kontrola návrhů. AI agenti někdy volili řešení, která obcházela důležité architektonické předpoklady, nebo přidávali zbytečnou složitost. Tým proto kontroloval každou změnu, přičemž se více soustředil na její záměr a dopad než na ruční čtení každého řádku vygenerovaného kódu.

Případ dobře vystihuje možný posun v práci softwarových inženýrů. Část rutinní implementace lze delegovat na modely, zatímco větší důraz připadá na návrh rozhraní, správnost systému, ověřování výsledků a rozhodování o tom, co je vhodné vůbec postavit.

Mění se i způsob začleňování změn

Git přitom není jedinou částí vývojového procesu, kterou bylo nutné přizpůsobit. Pokud AI agenti připravují změny mnohem rychleji, než je lidé stihnou kontrolovat, mohou se úzká místa přesunout do code review, testování a začleňování změn.

Anthropic proto vedle Scionu vyvinul také vlastní rozhraní pro kontrolu kódu nazvané Antique, vyhledávání v kódu a další součásti vývojové infrastruktury.

Firma přehodnotila i tradiční přístup k frontám změn. Pokud stovky nebo tisíce úprav čekají na dokončení testů, než se mohou začlenit, může se celý proces zpomalit. Anthropic proto více spoléhá na automatizované testování po začlenění změn a před nasazením.

Tento přístup může zvýšit propustnost, ale klade větší nároky na rychlé odhalování problémů, izolaci chybných změn a možnost jejich opravy nebo vrácení. Souběžné změny mohou vytvářet konflikty, které je následně potřeba vyřešit.

Nejde tedy o jednoduchou výměnu Gitu za rychlejší alternativu. Systém pro správu verzí musí odpovídat také způsobu, jakým se změny kontrolují, testují a nasazují.

Scion nebude univerzální náhradou Gitu

Pro většinu vývojářů zůstává Git správnou volbou. Anthropic sám uvádí, že Scion není vhodný jako obecná náhrada Gitu. Jeho principy dávají největší smysl u opravdu obrovských monorepozitářů, které obsluhují desítky tisíc inženýrů nebo roje AI agentů vytvářející velké množství kódu.

Migrace navíc není jednoduchá. Scion se od Gitu významně liší, takže organizace by musela přizpůsobit nejen samotnou správu verzí, ale také kontrolu kódu, vyhledávání, CI a další nástroje. Interní verze těchto komponent jsou úzce přizpůsobené potřebám Anthropic a nebylo by snadné je nabídnout jako univerzální řešení pro jiné organizace.

Společnost proto nepředstavuje Scion jako hotový veřejný produkt určený k běžnému nasazení. Místo toho chce sdílet principy, které by bylo možné přenést do existujícího ekosystému Gitu, a spolupracovat s GitHubem, GitLabem a open source komunitou.

Zajímavější než samotná výměna Gitu je proto princip, na kterém Scion stojí: server pro automatizované nástroje nemusí fungovat stejně jako lokální klient určený lidem. Platformy pro správu kódu by mohly nabídnout bohatší serverová rozhraní, díky nimž by agenti dokázali získat potřebné informace bez opakovaného stahování velkého množství dat.

Anthropic tak neříká, že Git je špatný nástroj. Ukazuje, že předpoklady, které z něj udělaly standard pro distribuovaný vývoj, nemusí být optimální pro každou novou podobu softwarového inženýrství.

Zatímco dříve bývalo hlavním omezením množství práce, kterou dokážou lidé napsat a zkontrolovat, při agentním vývoji se situace může obrátit. Kód vzniká rychleji a ve větším množství, takže další hranice výkonu leží v testování, správě změn a infrastruktuře, která celý proces drží pohromadě.

Scion je především ukázkou toho, jak může vypadat vývojová infrastruktura navržená pro svět, v němž software ve velkém vytvářejí také autonomní AI agenti.

Zdroj: Redesigning source control at Anthropic

Komentáře

Odebírat
Upozornit na
guest
0 Komentářů
Nejstarší
Nejnovější Nejvíce hlasů

DressCode si vezme váš PHP kód do parády

‐ PHP ‐
Komentáře: 0
Napsat nové pravidlo do PHP CS Fixeru nebo PHP_CodeSnifferu je za trest. David Grudl to zkusil kvůli jedinému řádku `use function` a místo pravidla z toho vznikl nový nástroj DressCode, postavený nad stromem, který ze zdrojáku nic nezahodí. Ukážeme si, jak ho nasadit, nastavit a zapojit do práce AI agenta.