Coding agenti zrychlili psaní kódu. Tím ale nezmizelo čekání na kontrolu změn – jen se přesunulo jinam. Linear popisuje vlastní zkušenost v článku AI coding has made CI a bottleneck, so we reworked ours to keep up: jakmile agenti začali vyrábět změny rychleji, průběžná integrace se stala brzdou celého vývojového procesu.
Nejde přitom jen o to, že testovací sada trvá déle. Každý pull request musí projít stejnými kontrolami, některé úlohy se spouštějí před ostatními a každý paralelní běh si nejdřív vezme svůj díl času na start runneru, checkout repozitáře a instalaci závislostí. Když se počet změn zvyšuje, staré předpoklady CI začnou být vidět mnohem ostřeji.
Když kód zrychlí, čekání nezmizí
Linear uvádí, že jeho testovací sada od začátku roku téměř zečtyřnásobila velikost. Přesto se podařilo zkrátit čekání na výsledek CI u pull requestu z více než šesti minut na něco přes pět minut a přibližně o polovinu snížit čas, který runner stráví jednotlivými testy.
To není tak působivé jako tvrzení o desetinásobně rychlejším AI agentovi. Pro vývojový tým je to ale podstatnější metrika. Agent může připravit změnu za pár minut, jenže pokud pak každý pokus čeká několik minut na kontrolu, rychlost psaní kódu se do rychlosti dodávky nepromítne.
Linear navíc podle vlastního popisu přidává zhruba 2 000 testů týdně. Bez průběžných úprav by dnešní sada trvala asi jedenáct minut, tedy téměř dvojnásobek současného čekání. CI tak není jednorázový projekt, který se jednou optimalizuje a tím je hotovo. Je to další část systému, která roste spolu s kódem.
Největší zrychlení nebylo v jednom kouzelném triku
První lekce je poměrně obyčejná: někdy je rychlejší vyměnit prostředí než donekonečna ladit každý krok pipeline. Linear přesunulo workload z GitHub Actions na externí runnery s rychlejšími procesory, úložištěm a cache. Ve srovnání dvou dnů před změnou a po ní běžely joby v průměru o 34 procent rychleji; u kompilace TypeScriptu byl rozdíl 52 procent.
Samotný toolchain pak přinesl další úsporu. Přechod na nativní TypeScript compiler tsgo podle Linear zkrátil týdenní medián kontroly tsc o 73 procent. U lintování firma přepsala několik pravidel tak, aby nepotřebovala celý TypeScriptový typový graf, ale vystačila si se statickou analýzou syntaxe. Čas API lintování klesl o 68 procent a lintování celého repozitáře o 55 procent.
To je důležitý detail. Problém nebyl pouze v tom, že testy byly pomalé. Část času spotřebovávaly kontroly, které blokovaly další práci, i když samy prováděly jen omezené množství užitečné práce. V AI-urychleném vývoji se vyplatí hledat právě takové malé, ale opakované ztráty.
Kritická cesta je důležitější než průměrný čas
Linear se proto podívalo na joby, které stojí na začátku celého běhu a rozhodují, co se spustí dál. Některé z nich kvůli jednoduché kontrole změn stahovaly celý pracovní strom, přestože potřebovaly jen malou část repozitáře. Omezení hloubky fetchu zkrátilo nejpomalejší z těchto bran z 94 sekund na 20. U jobů, které pracovní strom vůbec nepotřebovaly, checkout úplně odstranili a zkrátili čas z 27 sekund na 7.
Po přesunu na externí runnery se navíc objevily občasné problémy s připojením ke GitHubu. Linear nahradilo běžný actions/checkout vlastním composite action, které používá opakování s backoffem, ukončí zaseknuté připojení zhruba po třiceti sekundách a využívá trvalou Git cache. Nejde o efektní optimalizaci, ale přesně takové závady dokážou držet celou kritickou cestu prázdnou.
Ještě jeden job zapisoval cache marker těsně před mergem. Testy už byly hotové, ale pull request kvůli tomuto kroku zůstával v merge queue. Přesunutí zápisu mimo kritickou cestu ušetřilo podle Linear 42 sekund na každém API pull requestu a vstupu do merge queue.
Paralelní testy nepomohou, když každý nejdřív čeká na vlastní start
Další část práce se týkala opakovaného setupu. API testy si při každém běhu instalovaly stejný Postgres client. Linear ho vložilo do základního CI image společně s potřebnými závislostmi. V monorepu se zároveň přestalo instalovat všechno všude: API job dostal jen balíček API a jeho závislosti.
Instalace se tím zkrátila z 44-73 sekund na 16-18 sekund. Firma také zjistila, že cache node_modules není automaticky výhodná. Obnova cache trvala přibližně 28 sekund, zatímco filtrovaná instalace kolem 7,5 sekundy. Cache tedy přidávala čas i proměnlivost, aniž by přinesla měřitelnou výhodu.
Sedm nezávislých kontrol dříve pokaždé startovalo runner, stahovalo repozitář a instalovalo závislosti kvůli několika sekundám skutečné práce. Linear je sloučilo do dvou jobů a úlohy spouštělo souběžně uvnitř nich. Podle firmy to při tehdejším využití ušetřilo asi 87 000 runner-minut měsíčně, což odpovídalo 11,8 procenta celkové spotřeby CI.
Teprve když se podařilo zkrátit pevné náklady každého shardu, dávalo smysl testy dělit agresivněji. Linear přešlo ze čtyř shardů na osm. Kritický job byl v prvním měření přibližně o 19 procent rychlejší a o 19 procent levnější. Nejpomalejší shard se o týden později zkrátil z 5,25 minuty na 4,33 minuty.
Je v tom ale háček, který se v debatách o paralelizaci často ztrácí. Každý další shard také znamená další start, checkout a setup. Když tyto pevné náklady zůstanou vysoké, více paralelních běhů jen znásobí účet. Rychlejší testování proto nezačíná u tlačítka „přidej další shard“, ale u otázky, kolik času každý shard promrhá ještě před prvním testem.
Agenti mění i způsob, jakým se CI používá
U běžného týmu se předpokládá, že vývojář vytvoří změnu, počká na kontrolu a případně ji opraví. Coding agent může stejný cyklus opakovat rychleji a ve větším počtu. Neznamená to automaticky více hotového softwaru – znamená to více změn, které musí systém umět rychle a spolehlivě vyhodnotit.
Proto se problém netýká jen testovacího runneru. Tým potřebuje rozlišit, které kontroly musí blokovat merge, které mohou běžet později a které se mají spouštět jen při změně konkrétní části systému. Každá kontrola na kritické cestě by měla mít důvod, ne jen historické právo tam zůstat.
To souvisí i s koordinací více agentů. Na Radyzu jsme psali o projektu Foremerge, který se snaží zachytit konflikty mezi agenty ještě před zápisem kódu. Když několik agentů pracuje souběžně, CI musí ověřovat nejen jednotlivé změny, ale také to, co vznikne po jejich spojení.
A nakonec zůstává odpovědnost. Rychlejší automatické změny neznamenají, že tým může přestat rozumět systému. Problém odpovědnosti za kód vytvořený agentem jsme rozebírali také v článku AI agent jako junior vývojář s klíči od databáze. CI může odhalit mnoho chyb, ale samo neurčí, zda změna dává smysl pro celý produkt.
Co si z toho může odnést menší tým
Linear řeší infrastrukturu ve velkém měřítku, ale principy nejsou vyhrazené pro firmu s rozsáhlým monorepem. Menší tým nemusí hned pořizovat nové runnery. Měl by ale vědět, kde přesně čas mizí.
- Měřte zvlášť čekání ve frontě, start runneru, checkout, instalaci závislostí a samotné testy.
- Z kritické cesty odstraňte kroky, které nic nerozhodují o bezpečném mergi.
- Dělte testy podle skutečné délky běhu, ne pouze podle počtu souborů.
- Cache posuzujte podle reálného času obnovy a ukládání, ne podle toho, že cache zní jako optimalizace.
- Nastavte limity pro počet souběžných změn agentů a jasně určete, které změny vyžadují lidské schválení.
Bottleneck se jen přestěhoval
Coding agenti Linear nezpomalili. Naopak ukázali, že dosavadní CI bylo navržené pro pomalejší tempo změn. Když se psaní kódu zrychlí, začne být vidět čekání na validaci, nejasná kritická cesta, opakovaný setup a špatně rozdělené testy.
To je možná nejpraktičtější lekce celého příběhu. AI nemusí vývojový tým brzdit tím, že by psala špatný kód. Stačí, když bude psát dobré změny rychleji, než je tým a jeho infrastruktura dokážou ověřovat. Pak se z testů nestane pojistka, ale fronta.
Linear bude podle vlastního popisu přidávat další testy tempem zhruba 2 000 týdně. Skutečná zkouška proto nebude v tom, jestli se podařilo dostat CI pod pět minut, ale jestli se stejný proces podaří udržet rychlý i za měsíc. Agenti totiž nečekají, až bude infrastruktura připravená. Prostě pošlou další pull request.
