Fronta na review je teď vaše největší brzda v deploymentu

Začátkem letoška jsme převzali klientský codebase, kde čtyři agenti otevírali kolem 90 pull requestů denně a dva senioři, co je měli na starost, potichu přestali spát. Merge rate se zastavil na nějakých patnácti za den, zatímco počet otevřených PR přelezl tři stovky, a CI runnery jely naplno na tom, že hnaly stejnou test suite proti branchím, které pak týden ležely netknuté, dokud někdo naštvaně neschválil celou várku, jen aby to číslo šlo dolů. To není problém nástrojů, to je problém procesu. Přesně to změřila GitLab AI Accountability Report z června 2026, když zjistila, že 85 % vývojářů dnes říká, že se brzda přesunula z psaní kódu na jeho review a validaci. Zajímavé není to číslo. Zajímavé je, že na něj skoro nikdo nijak nezareagoval. Většina týmů, se kterými mluvím, jede stejnou PR šablonu, stejnou branch protection s povinnými dvěma approvaly a stejnou rotaci review ve stylu „kdo je volný, bere další

Nejúčinnější změna je přestat reviewovat každý pull request stejně, a osa, na které záleží, není kdo ho otevřel, ale čeho se dotýká. Nejdřív tierujeme podle rizikové plochy, teprve pak podle původu kódu. PR, který mění Tailwind třídu, přidá null check do zobrazovací komponenty nebo bumpne patch verzi v package.json, je kategoricky jiný než ten, který sahá na auth middleware, handler platebního webhooku, databázovou migraci nebo cokoliv pod adresářem, který jsme explicitně označili jako citlivý na blast radius. První tier je tedy plně autonomní merge na zelené CI: agentem psaný kód, nízkoriziková plocha, projde celá test suite plus type checky plus strop na velikost diffu, a jde to dovnitř, aniž by se na to kdy podíval člověk. Druhý tier je lehký lidský podpis, jeden reviewer s desetiminutovým SLA, pro středně rizikové změny nebo cokoliv, kde vlastní confidence signál agenta vyšel vratce. Třetí tier je povinné senior review vůbec bez auto-merge a pokrývá plochy, kde vás špatná změna stojí peníze, důvěru nebo budíček ve tři ráno. Zakódujete to do CODEOWNERS zkombinovaného s labelovací GitHub Action, která prohlíží cesty v diffu. Pro zmíněného klienta jsme jednu napsali v Go: čte YAML mapující cesty na tiery, olabeluje PR jako risk:low, risk:medium nebo risk:high a branch protection rule se pak řídí podle labelu. Výsledek byl, že asi 60 % agentích PR přestalo vůbec potřebovat člověka, což těm dvěma seniorům konečně umožnilo vrátit se k reviewu změn, na kterých fakt záleželo, místo topení se v dependency bumpech. Chyba, kterou týmy dělají, je tierovat podle autora: buď mávnou všechno od agenta, protože je to agent, nebo všechno zablokují, protože je to agent. Ani jedno není správně. Junior, který sahá na billing kód, potřebuje stejnou pozornost jako agent, který na něj sahá, a senior, který ladí copy, potřebuje stejnou nepozornost jako agent, který dělá totéž.

Za půl roku budete zírat na produkční incident a první otázka bude, které commity byly od člověka, které od kterého agenta a jaký prompt nebo task je vyplodil. Pokud jste to nezachytili při commitu, rekonstruujete to ze Slack archeologie. Zachyťte to u zdroje. Ke každému commitu, který agent vyprodukuje, přidáváme trailery, stejný mechanismus, jaký git už používá pro Signed-off-by. Commit message tedy končí Co-Authored-By, trailerem Agent-Model se skutečným identifikátorem modelu, Agent-Task-Id odkazujícím zpět na to, co práci zařadilo, a trailerem Provenance, který je prostě human, agent nebo agent-assisted. Přidat to je levné, injektuje to agentí wrapper, a znamená to, že git log --grep a váš data warehouse dokážou krájet merge rate, revert rate a defect rate podle původu bez jakéhokoliv hádání. To poslední je místo, kde se to vyplatí, protože jakmile umíte měřit revert rate per model a per rizikový tier, můžete tierovací politiku ladit podle důkazů místo podle politiky. Na jedné pipeline jsme zjistili, že revert rate agenta na tier-one auto-merge PR byl 1,8 %, tedy níž než lidský baseline 2,3 % na stejné ploše, což byl argument, který nám dovolil rozšířit síť auto-merge. Na tier-three plochách měl ten samý model revert rate 11 %, což byl argument, který tam člověka pevně udržel. Bez provenance tagů jsou ta dvě čísla nerozlišitelná a argumentujete pocitem. Otagujte to, uložte to, dejte to do dashboardu a nechte čísla rozhodnout, kde má být hranice důvěry.

Interní flotila agentů ve Stripe, ta věc, které říkají Minions, prý pushuje přes 1 300 pull requestů týdně, a je lákavé číst to číslo jako důkaz, že lidské review je zastaralé. To je špatné ponaučení. Správné ponaučení je, kde lidi nechávají, ne kde je odstranili. Objem je vysoký právě proto, že plochy, na kterých agenti operují, jsou omezené a dobře instrumentované: refaktory se silným test coverage, migrace za feature flagy, generování boilerplate proti schématům, která už mají property-based testy. Lidský úsudek nezmizel, přesunul se výš a zkoncentroval se. Někdo definoval omezení, někdo nastavil akceptační kritéria, někdo vlastní plochu, na kterou agent smí sáhnout, a když agent na té omezené ploše vyprodukuje něco, co projde automatickými branami, lidské review jednotlivého diffu už opravdu moc nepřidá. Úsudek se odehrál dřív, než PR vůbec existoval. Tohle je část, kterou engineering leadi pořád přehlížejí. K agentímu objemu se nedostanete tím, že budete reviewovat rychleji, ale tím, že přesunete lidské rozhodnutí dřív, do definice toho, co agenti smějí zkoušet a jak se jejich výstup validuje, aby se review na jeden PR mohlo na těch plochách, kde jste odvedli práci předem, smrsknout skoro na nulu. Důsledek je brutální a stojí za to ho říct natvrdo. Pokud má váš codebase tenký test coverage, nejasné vlastnictví a nosné implicitní chování, agenti vám review zátěž znásobí, ne uleví, protože každý jejich plausibilně vypadající diff teď vyžaduje člověka, aby domyslel důsledky, které testy nezachytí. Throughput agentů je downstream symptom upstream disciplíny. Týmy, co shipují 1 300 PR týdně, si to zasloužily tím, že nejdřív investovaly do nudných věcí.

Předělat, kdo co reviewuje, vyřeší polovinu brzdy. Ta druhá polovina je, že agenti vám ochotně saturují CI runnery tím, že ženou celé suite proti branchím, které se nikdy nemergnou, a to je čirá ztráta, kterou platíte po minutách. Pár věcí, které tu stojí za to udělat. Nejdřív pusťte rychlou lint-and-typecheck bránu a nechte to selhat lacino, ještě než roztočíte drahou integrační suite, protože obrovský podíl agentích PR umře na něčem, co by dvouminutová kontrola chytila. Odstraňte duplicitní práci hashováním diffu a přeskočte plné běhy na branchích, jejichž relevantní cesty se od posledního zeleného běhu nezměnily. Nastavte concurrency cap per agent, aby jeden ujetý task nemohl sežrat celý runner pool a vyhladovět lidské PR, na které někdo aktivně čeká, protože vývojář blokovaný na třicet minut je mnohem dražší než agentí PR sedící ve frontě. Vynucujeme taky staleness reaper, naplánovaný job, který zavře agentí PR bez aktivity a bez merge po 72 hodinách, protože nemergnutý agentí PR není work item, ke kterému se vrátíte, je to jen šum nafukující počet otevřených a občas se rebasující do konfliktů. Nic z toho není exotické. Je to stejný instinkt kapacitního plánování, jaký byste nasadili na jakýkoliv systém, kde poptávka najednou vyskočila o dva řády, aplikovaný na jeden zdroj, se kterým nikdo nepočítal, protože v roce 2023 byla CI kapacita fakticky zdarma vzhledem k tomu, kolik PR dokázali vygenerovat lidi. Ten předpoklad je mrtvý. Plánujte s frontou jako s produkční infrastrukturou, protože jí teď je.

Pokud jste engineering lead a sledujete, jak vám roste CI fronta, zatímco merge rate stagnuje, nesnažte se to vyřešit všechno naráz. Vyberte jednu plochu se silným test coverage, řekněme svou component library nebo interní admin nástroj, otierujte ji, zapněte auto-merge pro nízkorizikový pás a přidejte provenance trailery, abyste opravdu viděli revert rate. Dejte tomu měsíc. Pokud revert rate na auto-merge pásu zůstane na úrovni vašeho lidského baseline nebo pod ním, rozšiřte síť na další plochu. Pokud ne, přesně jste zjistili, kde vám test coverage lže, což je užitečná informace, kterou byste stejně dřív nebo později potřebovali. Ve steezru jsme tenhle rollout udělali už tolikrát, na pipelinách na zpracování dokumentů, na zákaznických portálech a na pár interních systémech, kde agentí objem potichu drtil review tým, že ten vzorec je nudně opakovatelný. Klienty přitom konzistentně překvapuje, kolik z toho zisku pochází ze změn v procesu, ne z něčeho chytrého v samotných agentech. Agenti nikdy nebyli brzda. Vaše pražská skepse je vůči většině pitchů o AI-in-the-loop na místě a sdílím ji, ale tenhle konkrétní posun je skutečný a měřitelný. Týmy, které kvůli němu předělají svůj review proces, budou shipovat, zatímco týmy, co pořád jedou svoje workflow z roku 2023, budou zírat na tři stovky otevřených PR a divit se, proč se nic nemerguje.