AI-kodningsassistenterna har förändrat spelet – men infrastrukturen hänger inte med

De stora AI-kodningsassistenterna – Claude Code, Codex, Gemini CLI – är inte längre nyheter. De används dagligen av tusentals utvecklare världen över. Frågan vi nu måste ställa oss är inte om dessa verktyg fungerar, utan hur vi faktiskt bygger infrastruktur som kan köra dem i stor skala utan att antingen spränga budgeten eller introducera latens som får utvecklare att vilja kasta sina tangentbord genom fönstret.

Forskare vid University of Washingtons SyFI-lab har precis publicerat en studie som ger oss rejäla mängder data om hur verkliga kodningsagentarbetsbelastningar faktiskt ser ut. Och siffrorna överraskar.

Kodningsagenterna jobbar helt annorlunda än traditionella chatbotar

Det finns något som verkar självklart när man hör det, men som få faktiskt har tänkt igenom ordentligt: kodningsagenter svarar inte bara på frågor. De exekverar planer.

När du ber en AI-kodningsassistent implementera en funktion eller fixa en bugg så startar du inte en enkel fråga-svar-transaktion. Du aktiverar en autonom arbetsprocess där modellen resonerar, kör shellkommandon, läser och modifierar filer, kör tester och itererar tills den är nöjd – eller tills du avbryter den.

Forskarna samlade in data från över 4 300 verkliga sessioner, sammanlagt ungefär 55 miljarder tokens. Mönstren som framträder är slående. Varje användarförfrågan triggar i genomsnitt 8,8 LLM verktygs-cykler innan den är klar. Åtta komma åtta stycken. För varje fråga en utvecklare ställer så pågår alltså nästan nio rundor av modellgenerering följt av verktygskörning.

Och här kommer det verkligt intressanta: 88 procent av alla LLM-inferensrundor sker inte som svar på användarinput, utan som svar på resultat från verktyg. Modellen pratar inte bara – den gör.

Det här har enorma konsekvenser för hur vi planerar throughput. Traditionella chatbotar är i grunden request-response-system med ibland uppföljningsfrågor. Kodningsagenter däremot liknar mer långvariga autonoma processer med frekvent kontextväxling mellan generations- och exekveringsfaser. Din autoskalningspolicy, din requestkö, dina cachningsstrategier – allt behöver omprövas genom linsen av autonoma flerstegsarbetsflöden snarare än enkla turtagningskonversationer.

Den input-output-asymmetri som förstör din cache

Här kommer ett nummer som borde få varje infrastrukturingenjör att stanna upp: inputs överstiger outputs med 294 till 1.

I de studerade tracesen läste modellerna 52,56 miljarder cachade input-tokens och prefillade 2,34 miljarder nya sådana, men genererade endast 186,9 miljoner output-tokens. En typisk rundsession har en 32K till 256K token prefix och lägger bara till några hundra till några tusen tokens innan den avkodar ett par hundra ut.

Detta skapar en fundamentalt annorlunda prestandaprofil än vad de flesta LLM-serving-system är optimerade för. Traditionell språkmodellsinfrerence fokuserar tungt på generationsthroughput – hur många tokens per sekund kan vi producera? Men för kodningsagenter är flaskhalsen ofta inte dekodningshastighet; det är time-to-first-token (TTFT) efter att verktygsexekvering returnerar.

Forskarna fann att Codex TTFT för varje steg ligger runt 3,1 sekunder, vilket representerar ungefär 25 procent av en rundas totala generationstid. När du gör nio rundor per förfrågan så ackumuleras den här omkostnaden snabbt.

Cachningshistorien är också mer nyanserad än den först verkar. Jo, input-caching (prefill-caching) hjälper till med den massiva kontext som kodningsagenter bär på. Men prefill-arbetsbelastningen delas mellan cachade tokens och nya tokens som faktiskt behöver beräkning. Korta, inkrementella prefills efter verktygsexekvering har andra prestandaegenskaper än den initiala långkontextladdningen. Serving-system behöver hantera båda effektivt, och de optimala strategierna kan skilja sig mellan dessa fall.

Shell-kommandon dominerar fortfarande

Om du trodde att kodningsagenter mest skulle hålla på med sofistikerat resonerande och komplex refaktorisering så hade du inte fel – men verkligheten är rörigare. Av de 433 000 verktygsanrop som fångades i tracesen var 76 procent shell- eller kommandoexekveringar. Att köra byggen, tester, git-operationer, filmanipulation genom CLI-verktyg – det oinspirerade som utgör den faktiska dagliga arbetsflödet för mjukvaruutveckling.

Filredigeringar stod för 11 procent, filläsningar och sökningar för 9 procent, medan planering, sub-agent-delegering och webbsökningar tog resten.

Den här koncentrationen i shell-kommandon spelar roll av flera skäl. För det första är dessa långsvansade operationer: ett enkelt ls är snabbt, men att köra en fullständig testsvit eller kompilera en stor kodbas kan ta minuter. Latensfördelningen sträcker sig över fyra storleksordningar, vilket gör kapacitetsplanering till en mardröm.

För det andra varierar verktygsvokabulären signifikant mellan agenter. Claude Code använde 54 olika verktyg medan Codex använde 31, men båda koncentrerade den överväldigande majoriteten av sin volym i samma kärnset – shell, filredigeringar, filläsningar. Detta antyder att optimering för dessa högfrekventa verktyg skulle kunna ge oproportionerligt stora förbättringar, även utan att attackera hela verktygsekosystemet.

Vad det här betyder för din infrastruktur

Om du bygger eller driftar AI-powered utvecklarverktyg pekar den här forskningen mot flera konkreta slutsatser.

Tänk i arbetsflöden, inte förfrågningar. Din serving-infrastruktur behöver räkna med den autonoma, flerstegiga naturen hos kodningsagenter. Det betyder längre request-kontexter, mer sofistikerad statthantering och batch-schemaläggningsmöjligheter som grupperar relaterade verktygsanrop tillsammans.

Optimera för tomgångsglapp. Användare spenderar i genomsnitt 46,7 minuter mellan förfrågningar, trots en median-tid för "tänkande" på bara 1,4 minuter. Fördelningen är extremt tungsvansad – vissa utvecklare itererar snabbt medan andra startar en förfrågan och kommer tillbaka timmar senare. Smart prefetching och om-prefill-strategier under dessa tomgångsperioder skulle dramatiskt kunna minska upplevd latens utan att öka beräkningskostnaderna.

Separera dina prefill- och decode-banor. Input-output-kvoten på 294:1 betyder att din prefill-beräkning sannolikt är din dominerande kostnad. Inkrementella prefills efter verktygsexekvering behöver annorlunda optimering än initial kontextladdning. Överväg separata resurspooler eller schemaläggningspolicys för dessa olika arbetsbelastningstyper.

Glöm inte verktygsexekveringsinfrastrukturen. När 76 procent av agentaktiviteten är shell-kommandon blir din containerorkestrering, filsystemåtkomstmönster och byggverktygscachning förstklassiga bekymmer för AI-agent-serving. Modellinferensen är bara en del av pipelinen.

Vägen framåt

TraceLab-teamet har gjort sitt trace-insamlings- och analyspipelining projekt med öppen källkod, vilket gör det möjligt för infrastrukturteam att generera egna traces och optimera för faktiska användningsmönster snarare än syntetiska benchmarks. Den här typen av verklig data är precis vad AI-infrastrukturvärlden behöver när den mognar från "få det att fungera" till "få det att fungera i stor skala".

För NameOcean Vibe Hosting-communityn belyser de här insikterna varför vi investerar i infrastruktur som går bortom enkel GPU-allokering. Att servera AI-kodningsagenter handlar inte bara om rå beräkningskraft – det handlar om att förstå de unika egenskaperna hos agentiska arbetsbelastningar och bygga system som kan hantera den autonoma, flerstegiga, verktygstunga verkligheten i hur utvecklare faktiskt använder de här verktygen.

Ära av kodningsagenten har precis börjat, och de infrastrukturbeslut vi fattar idag kommer att forma hur effektivt de här verktygen betjänar utvecklare under år framöver.