Hva TraceLab-forskningen avslører om hvordan kodeagenter faktisk fungerer

AI-kodende assistenter har kommet for å bli. Claude Code, Codex og Gemini CLI brukes nå av utviklere verden over, og spørsmålet er ikke lenger om disse verktøyene fungerer – det er hvordan vi skal skalere dem uten at budsjettene sprekker eller latensen får utviklere til å kaste tastaturet ut vinduet.

En fersk forskningsartikkel fra University of Washingtons SyFI-lab gir oss konkrete tall på hvordan virkelige kodeagent-arbeidsbelastninger ser ut. Spoiler: infrastrukturen din er sannsynligvis ikke optimalisert for dette.

Den autonome revolusjonen ingen forberedte seg på

Her er noe som virker åpenbart når det først blir sagt: kodeagenter svarer ikke bare på spørsmål. De utfører planer. Når du ber en AI-kodende assistent implementere en funksjon eller fikse en bug, starter du ikke en enkel forespørsel-svar-transaksjon. Du setter i gang en autonom arbeidsflyt der modellen resonnerer, kjører shell-kommandoer, leser og endrer filer, kjører tester og itererer til den er fornøyd – eller til du avbryter den.

Forskerne samlet inn over 4 300 virkelige sesjoner, tilsammen rundt 55 milliarder tokens, og mønstrene er slående. Hver brukerforespørsel utløser i gjennomsnitt 8,8 LLM-verktøy-sykler før fullføring. Tenk på det: for hvert spørsmål en utvikler stiller, er det nesten ni runder med modellgenerering fulgt av verktøyutførelse. Modellen snakker ikke bare – den handler.

Og her kommer poenget: 88% av all LLM-inferens skjer ikke som respons på brukerinput, men som respons på verktøyresultater.

Dette har enorme konsekvenser for throughput-planlegging. Tradisjonelle chatboter er i bunn og grunn forespørsel-svar-systemer med av og til oppfølginger. Kodeagenter er mer som langvarige, autonome prosesser med hyppig kontekstbytte mellom genererings- og kjøringsfaser. Din autoskalering, din request-køhåndtering, dine cachingstrategier – alt dette må tenkes på nytt med fokus på autonome, flerstegs arbeidsflyter, ikke enkle tilbakemeldingssamtaler.

Inntak-utaks-asymmetrien som ødelegger cachen din

Her er et tall som bør få enhver infrastruktur ingeniør til å se opp to ganger: input overstiger output med 294 til 1. I sporene som ble analysert, leste modellene 52,56 milliarder cachede input-tokens og prefillte 2,34 milliarder nye, men genererte bare 186,9 millioner output-tokens. En typisk runde sitter på et 32K til 256K token-prefix og legger bare til noen hundre til noen tusen tokens før den dekoder et par hundre ut.

Dette skaper et fundamentalt annet ytelsesprofil enn det de fleste LLM-serving-systemer er optimalisert for. Tradisjonell språkmodell-inferens fokuserer tungt på genereringsgjennomstrømning – hvor mange tokens per sekund kan vi produsere? Men for kodeagenter er flaskehalsen ofte ikke dekodingshastighet; det er tid-til-første-token (TTFT) etter at verktøyexecutering returnerer. Teamet fant at Codex sin TTFT for hvert steg ligger rundt 3,1 sekunder, som utgjør omtrent 25% av en rundes totale genereringstid. Når du gjør ni runder per forespørsel, skalerer denne overheaden fort.

Caching-historien er også mer nyansert enn den først virker. Ja, input-caching (prefill caching) hjelper med den massive konteksten kodeagenter bærer med seg. Men prefill-arbeidsbelastningen er delt mellom cachede tokens og nye tokens som trenger faktisk beregning. Korte, inkrementelle prefills etter verktøyexecutering har andre ytelsesegenskaper enn den initielle lange-kontekst-lasten. Serving-systemer må håndtere begge effektivt, og de optimale strategiene kan variere mellom disse tilfellene.

Shell-kommandoer tar over verden (fortsatt)

Hvis du trodde kodeagenter ville holde på med sofistikert resonnemeng og komplekse refaktoreringer, hadde du rett – men virkeligheten er rotete. Av de 433 000 verktøykallene som ble fanget i sporene, var 76% shell- eller kommandoexecuceringer. Kjøre builds, tester, git-operasjoner, filmanipulasjoner gjennom CLI-verktøy – det kjedelige arbeidet som faktisk utgjør den daglige arbeidsflyten til programvareutvikling.

Filredigeringer stod for 11%, fillesing og søk for 9%, med planlegging, sub-agent delegering og nettoppslag som resten. Denne konsentrasjonen i shell-kommandoer betyr noe av flere grunner. For det første er dette langhalede operasjoner: en enkel ls er rask, men å kjøre en full testpakke eller kompilere en stor kodebase kan ta minutter. Latensfordelingen spenner over fire størrelsesordener, noe som gjør kapasitetsplanlegging til et mareritt.

For det andre varierer verktøyvokabularet betydelig mellom agenter. Claude Code brukte 54 forskjellige verktøy mens Codex brukte 31, men begge konsentrerte det store flertallet av volumet i det samme kjernesettet – shell, filredigeringer, fillesing. Dette antyder at optimalisering for disse høyfrekvente verktøyene kunne gi overvektsmessige forbedringer, selv uten å ta tak i hele verktøyøkosystemet.

Hva dette betyr for din infrastruktur

Hvis du bygger eller drifter AI-drevne utviklingsverktøy, peker denne forskningen på flere konkrete takeaways.

Tenk i arbeidsflyter, ikke forespørsler. Din serveringsinfrastruktur må ta hensyn til den autonome, flerstegs naturen til kodeagenter. Dette betyr lengre kjørende request-kontekster, mer sofistikert tilstandsstyring, og batch-planleggingsmuligheter som grupperer relaterte verktøykall sammen.

Optimaliser for tomgangsgapene. Brukere bruker i gjennomsnitt 46,7 minutter mellom forespørsler, til tross for en median tenketid på bare 1,4 minutter. Fordelingen er ekstremt tunghalede – noen utviklere itererer raskt mens andre starter en forespørsel og kommer tilbake timer senere. Smart prefetching og re-prefill strategier i løpet av disse tomgangsperiodene kan dramatisk redusere opplevd latens uten å øke beregningskostnadene.

Separer prefill- og decode-banedine. Den 294:1 input-output-raten betyr at din prefill-beregning sannsynligvis er din dominerende kostnad. Inkrementelle prefills etter verktøyexecutering trenger annen optimalisering enn initielle kontekstlasting. Vurder separate ressurspooler eller planleggingsregler for disse forskjellige arbeidsbelastningstypene.

Ikke glem verktøyexecuteringsinfrastrukturen. Når 76% av agentaktiviteten er shell-kommandoer, blir din containerorkestrering, filsystemaksessmønstre og build-verktøy-caching førsteklasses bekymringer for AI-agent-serving. Modellinferensen er bare en del av pipelinen.

Veien videre

TraceLab-teamet har open-sourcet sitt trace-samlings- og analysesystem, noe som gjør det mulig for infrastrukturteam å generere sine egne spor og optimalisere for faktiske bruksmønstre i stedet for syntetiske benchmarks. Denne typen virkelige data er akkurat det AI-infrastrukturfeltet trenger ettersom det modnes fra "få det til å virke" til "få det til å virke i skala."

Disse innsiktene understreker hvorfor vi investerer i infrastruktur som går utover enkel GPU-tildeling. Å servere AI-kodende agenter handler ikke bare om rå beregning – det handler om å forstå de unike egenskapene til agentiske arbeidsbelastninger og bygge systemer som kan håndtere den autonome, flerstegs, verktøytunge virkeligheten av hvordan utviklere faktisk bruker disse verktøyene.

Kodeagentenes æra er bare i startfasen, og infrastrukturavgjørelsene vi tar i dag vil forme hvor effektivt disse verktøyene betjener utviklere i årene som kommer.