Závod ve zbrojení AI asistentů pro programování: Co nám o nich prozradil výzkum

Claude Code, Codex, Gemini CLI – to už nejsou jen hudební názvy z konference. Tyto nástroje denně používají tisíce vývojářů a otázka už dávno není "fungují tyhle věci?", ale spíš "jak je provozovat ve velkém, aniž bychom přitom prodělali majetek nebo zavedli latenci, kvůli kterýmu budou programátoři házet klávesnice z okna?"

Na scénu teď přichází výzkumný paper z univerzity ve Washingtonu, konkrétně z laboratoře SyFI. A čísla, která přináší, jsou docela husarský.

Revoluce autonomie, na kterou nikdo nebyl připravený

Tady je ta věc ohledně coding agentů – pořád to vypadá banálně, ale najednou to řekne někdo nahlas a začne to dávat smysl: tyhle nástroje neodpovídají na otázky. Ony vykonávají plány. Když po AI asistentovi chcete, aby implementoval funkci nebo opravil bug, nezačínáte simple request-response transakci. Startujete autonomní workflow, kde model přemýšlí, spouští shell příkazy, čte a mění soubory, pouští testy a iteruje, dokud není spokojený (nebo dokud ho nepřerušíte).

Výzkumný tým zachytil přes 4 300 reálných session s celkovým objemem zhruba 55 miliard tokenů. Čísla jsou zajímavá. Každá uživatelská žádost v průměru spustí 8,8 LLM-tools cyklů před dokončením. Zamyslete se nad tím – na každou otázku vývojáře připadá skoro devět kol generování modelu následovaných exekucí nástroje. Model nesděluje, co udělat. On to dělá. A 88 % všech LLM inference kol vzniká nikoli jako odpověď na uživatelský vstup, ale jako reakce na výsledky z nástrojů.

To má pořádné důsledky pro plánování throughputu. Tradiční chatboty jsou v podstatě request-response systémy s občasným follow-up. Coding agenty jsou spíš dlouho běžící autonomní procesy s častým přepínáním kontextu mezi generováním a exekucí. Vaše autoscaling politiky, fronty požadavků, caching strategie – to všechno potřebujete předelat optikou autonomních multi-step workflow, ne simple konverzačního střídání.

Input-Output asymetrie, která ničí váš cache

Tady přichází číslo, které by mělo přimět každého infrastructure engineera k dvojí kontrole: inputy převažují outputy v poměru 294:1. V analyzovaných traces modely přečetly 52,56 miliard cached input tokenů a prefilled 2,34 miliardy nových, ale vygenerovaly jen 186,9 milionů output tokenů. Typické kolo sedí na 32K až 256K token prefixu a přidá jen pár stovek až pár tisíc tokenů před tím, než decodeuje pár stovek ven.

To vytváří fundamentálně odlišný výkonnostní profil, než na co je většina LLM serving systémů optimalizovaná. Tradiční language model inference se soustředí na generation throughput – kolik tokenů za sekundu dokážeme produkovat? U coding agentů ale často není bottleneckem rychlost decode. Je to time-to-first-token (TTFT) po návratu tool exekuce. Tým zjistil, že TTFT Codex pro každý step je zhruba 3,1 sekundy, což představuje asi 25 % celkového času generování v kole. Když děláte devět kol na request, ta režie se rychle nasčítá.

Caching příběh je taky nuancovanější, než se na první pohled zdá. Jasně, input caching (prefill caching) pomáhá s masivním kontextem, který coding agenty nesou. Ale prefill workload se dělí mezi cached tokeny a nové tokeny vyžadující skutečnou komputaci. Krátké, inkrementální prefills po tool exekuci mají jiné výkonnostní charakteristiky než initial long-context load. Serving systémy potřebují zvládat oboje efektivně a optimální strategie se mezi těmito případy můžou lišit.

Shell commands pořád vládnou

Kdybyste si mysleli, že coding agenty budou dělat sofistikované reasoningy a komplexní refaktoring, nebyli jste úplně vedle – ale realita je chaotičtější. Z 433 000 tool calls zachycených v traces bylo 76 % shell nebo command exekucí. Spouštění buildů, testů, git operací, manipulace se soubory přes CLI nástroje – nevděčná práce, která tvoří skutečnou denní rutinu software vývoje.

File edity přišly na 11 %, file reads a searches na 9 %, planning, sub-agent delegace a web lookupy zabírají zbytek. Tato koncentrace v shell commands je důležitá z několika důvodů. Zaprvé, tyto operace mají těžký tail: simple ls je rychlý, ale puštění full test suite nebo kompilace velký codebase může trvat minuty. Latency distribuce se rozkládá přes čtyři řády velikosti, což dělá z capacity planningu noční můru.

Zadruhé, tool vocabulary se mezi agenty dost liší. Claude Code využíval 54 různých nástrojů zatímco Codex 31, ale oba koncentrovali drtivou většinu volume do stejného jádra – shell, file edity, file reads. To naznačuje, že optimalizace pro tyto high-frequency tools by mohla přinést nadstandardní zlepšení, aniž byste museli řešit celý tool ekosystém.

Co to znamená pro vaši infrastrukturu

Pokud stavíte nebo provozujete AI-powered vývojářský nástroje, ten výzkum ukazuje několik konkrétních bodů k akci.

Přemýšlejte ve workflow, ne v requestech. Vaše serving infrastruktura potřebuje počítat s autonomní, multi-step povahou coding agentů. Znamená to delší běžící request kontexty, sofistikovanější state management a batch scheduling příležitosti, které seskupí související tool calls dohromady.

Optimalizujte pro idle gaps. Uživatelé průměrně tráví 46,7 minuty mezi requesty, přestože medián think time je jen 1,4 minuty. Distribuce je extrémně heavy-tailed – někteří vývojáři iterují rychle, zatímco jiní pošlou request a vrátí se za hodiny. Chytrý prefetching a re-prefill strategie během těchto idle period by mohly dramaticky snížit perceived latency bez navýšení nákladů na compute.

Oddělte prefill a decode cesty. Poměr 294:1 znamená, že vaše prefill computace je pravděpodobně dominantní náklad. Inkrementální prefills po tool exekuci potřebují jinou optimalizaci než initial context loading. Zvažte separátní resource pools nebo scheduling politiky pro tyto různé typy workloadů.

Nezapomínejte na tool exekuce infrastrukturu. Když 76 % agent activity jsou shell commands, vaše container orchestration, filesystem access patterns a build tool caching se stávají first-class concerns pro AI agent serving. Model inference je jen část pipeliny.

Cesta vpřed

TraceLab team open-sourcnul svůj trace collection a analysis pipeline, takže infrastructure týmy můžou generovat vlastní traces a optimalizovat pro skutečné usage patterns místo syntetických benchmarků. Tenhle typ real-world dat je přesně to, co AI infrastruktura potřebuje, až dospěje z "make it work" do "make it work at scale."

Pro komunitu kolem našeho hostingu tyto poznatky zdůrazňujou, proč investujeme do infrastruktury, která jde za simple GPU allocation. Serving AI coding agentů není jen o raw compute – jde o pochopení unikátních charakteristik agentic workloads a stavění systémů, které zvládnou autonomní, multi-step, tool-heavy realitu toho, jak vývojáři tyhle nástroje fakticky používají.

Era coding agentů teprve začíná a infrastruktura rozhodnutí, která uděláme dnes, budou formovat, jak efektivně tyto nástroje budou sloužit vývojářům v dalších letech.