AI-kodningsassistenter sætter infrastrukturen på prøve

AI-kodningsassistenter har udviklet sig hurtigt. Med værktøjer som Claude Code, Codex og Gemini CLI i hænderne på udviklere verden over, er spørgsmålet ikke længere, om disse værktøjer virker. Det handler om, hvordan man betjener dem i stor skala uden at sprænge budgettet eller introducere en latens, der får udviklere til at smide tastaturet ud af vinduet.

En ny forskningsartikel fra University of Washingtons SyFI-lab giver nogle hårde tal for, hvad virkelige kodningsagent-arbejdsbelastninger faktisk ser ud til. Og resultaterne kan overraske dig. Spoiler: din eksisterende LLM-infrastruktur er sandsynligvis ikke optimeret til dette.

Den autonome revolution, ingen forberedte sig på

Her er noget ved kodningsagenter, der virker indlysende, når først nogen siger det højt: De svarer ikke bare på spørgsmål. De udfører planer. Når du beder en AI-kodningsassistent om at implementere en funktion eller rette en fejl, starter du ikke en simpel forespørgsel-svar-transaktion. Du igangsætter en autonom arbejdsproces, hvor modellen vil ræsonnere, udføre shell-kommandoer, læse og redigere filer, køre tests og iterere, indtil den er tilfreds (eller indtil du afbryder den).

Forskerteamet indsamlede over 4.300 virkelige sessioner svarende til cirka 55 milliarder tokens, og mønstrene er slående. Hver brugerforespørgsel udløser i gennemsnit 8,8 LLM-værktøjscyklusser før afslutning. Tænk over det: for hvert spørgsmål en udvikler stiller, er der næsten ni runder med modelgenerering efterfulgt af værktøjsudførelse. Modellen taler ikke bare – den handler.

Og 88% af alle LLM-inferens-runder sker ikke som svar på brugerinput, men som svar på værktøjsresultater.

Dette har enorme konsekvenser for throughput-planlægning. Traditionelle chatbots er i bund og grund request-response-systemer med lejlighedsvise opfølgninger. Kodningsagenter minder mere om langvarige autonome processer med hyppig kontekstskift mellem generations- og udførelsesfaser. Din autoskalering, din request-kø, dine caching-strategier – alt dette skal gentænkes i lyset af autonome flersteps-arbejdsprocesser frem for simple dialoger.

Den input-output-asymmetri, der ødelægger din cache

Her er et tal, der burde få enhver infrastruktur-ingeniør til at spærre øjnene op: inputs overstiger outputs med 294 til 1. I de analyserede traces læste modellerne 52,56 milliarder cachede input-tokens og pre-fillede 2,34 milliarder nye, men genererede kun 186,9 millioner output-tokens. En typisk runde sidder på et 32K til 256K token-præfiks og tilføjer kun et par hundrede til et par tusinde tokens, før den afkoder et par hundrede ud.

Dette skaber et fundamentalt anderledes performance-profil end det, de fleste LLM-serving systemer er optimeret til. Traditionel sprogmodel-inferens fokuserer tungt på generations-throughput – hvor mange tokens per sekund kan vi producere? Men for kodningsagenter er flaskehalsen ofte ikke dekodningshastigheden; det er time-to-first-token (TTFT) efter værktøjsudførelse. Teamet fandt, at Codex's TTFT for hvert trin ligger omkring 3,1 sekunder, hvilket repræsenterer cirka 25% af en rundes samlede generations tid. Når du laver ni runder per request, vokser det overhead hurtigt.

Caching-historien er også mere nuanceret, end den først ser ud til. Ja, input-caching (prefill caching) hjælper med den massive kontekst, som kodningsagenter bærer rundt på. Men prefill-arbejdsbelastningen er delt mellem cachede tokens og nye tokens, der kræver faktisk beregning. Korte, inkrementelle prefills efter værktøjsudførelse har forskellige performance-karakteristika end den indledende lange-kontekst-belastning. Serving-systemer skal håndtere begge effektivt, og de optimale strategier kan variere mellem disse tilfælde.

Shell-kommandoer dominerer stadig

Hvis du troede, at kodningsagenter ville beskæftige sig med sofistikeret ræsonnering og kompleks refactoring, tog du ikke fejl – men virkeligheden er mere rodet. Af de 433.000 værktøjskald fanget i tracesene var 76% shell- eller kommandoudførelser. Køre builds, tests, git-operationer, filmanipulation gennem CLI-værktøjer – det upraktiske stof, der udgør den faktiske daglige arbejdsgang i softwareudvikling.

Filredigeringer stod for 11%, fillæsning og søgninger for 9%, med planlægning, sub-agent-delegation og websøgninger som resten. Denne koncentration i shell-kommandoer betyder noget af flere grunde. For det første er disse langhalede operationer: en simpel ls er hurtig, men at køre et fuldt testsuite eller kompilere en stor kodebase kan tage minutter. Latensfordelingen spænder over fire størrelsesordener, hvilket gør kapacitetsplanlægning til et mareridt.

For det andet varierer værktøjsvokabularet markant mellem agenter. Claude Code brugte 54 forskellige værktøjer, mens Codex brugte 31, men begge koncentrerede langt størstedelen af deres volumen i det samme kerne-sæt – shell, filredigeringer, fillæsning. Dette tyder på, at optimering til disse high-frequency værktøjer kunne give uforholdsmæssigt store forbedringer, selv uden at tackle det fulde værktøjsøkosystem.

Hvad dette betyder for din infrastruktur

Hvis du bygger eller driver AI-drevne udviklingsværktøjer, peger denne forskning på flere konkrete takeaways.

Tænk i arbejdsprocesser, ikke forespørgsler. Din serving-infrastruktur skal tage højde for den autonome, flersteps-natur af kodningsagenter. Det betyder længerevarende request-kontekster, mere sofistikeret state management og batch-scheduling-muligheder, der grupperer relaterede værktøjskald sammen.

Optimer for de tomme huller. Brugere bruger i gennemsnit 46,7 minutter mellem forespørgsler, på trods af en median tænketid på kun 1,4 minutter. Fordelingen er ekstremt tungt-haled – nogle udviklere itererer hurtigt, mens andre starter en forespørgsel og kommer tilbage timer senere. Smart prefetching og re-prefill strategier i disse tomme perioder kunne dramatisk reducere oplevet latens uden at øge compute-omkostningerne.

Adskil dine prefill og decode-stier. Den 294:1 input-output-ratio betyder, at din prefill-beregning sandsynligvis er din dominerende omkostning. Inkrementelle prefills efter værktøjsudførelse kræver forskellig optimering end indledende kontekstindlæsning. Overvej separate resource pools eller scheduling-politikker for disse forskellige arbejdsbelastningstyper.

Glem ikke værktøjsudførelses-infrastrukturen. Når 76% af agentaktivitet er shell-kommandoer, bliver din container-orchestration, dine filsystem-adgangsmønstre og dine build-tool-caches førsteklasses bekymringer for AI-agent-serving. Model-inferensen er kun en del af pipeline.

Vejen fremad

TraceLab-teamet har open-sourced deres trace-samling og analyse-pipeline, hvilket gør det muligt for infrastrukturteams at generere deres egne traces og optimere til faktiske brugsmønstre frem for syntetiske benchmarks. Den slags virkelighedsnære data er præcis, hvad AI-infrastrukturrummet har brug for, efterhånden som det modnes fra "få det til at virke" til "få det til at virke i stor skala."

For NameOcean Vibe Hosting-fællesskabet fremhæver disse indsigter, hvorfor vi investerer i infrastruktur, der går ud over simpel GPU-allokering. At betjene AI-kodningsagenter handler ikke kun om rå compute – det handler om at forstå de unikke karakteristika ved agentiske arbejdsbelastninger og bygge systemer, der kan håndtere den autonome, flersteps, værktøjstunge virkelighed af, hvordan udviklere faktisk bruger disse værktøjer.

Æraen for kodningsagenter er lige begyndt, og de infrastrukturbeslutninger, vi træffer i dag, vil forme, hvor effektivt disse værktøjer betjener udviklere i årene fremover.