De Infrastructuur-Wedloop achter AI Coding Assistants: Wat TraceLab Onthult

De strijd om de beste AI coding assistant is definitief in een nieuwe fase beland. Nu Claude Code, Codex en Gemini CLI volop door ontwikkelaars worden gebruikt, verschuift de vraag: het gaat niet meer om of deze tools werken, maar om hoe je ze schaalbaar kunt serveren zonder dat je kosten exploderen of de latency zo erg wordt dat developers hun toetsenbord door het raam gooien.

Een boeiend onderzoekspaper van de SyFI lab van de University of Washington heeft harde cijfers vrijgegeven over hoe echte coding agent workloads er daadwerkelijk uitzien. En de resultaten zijn verrassend: je huidige LLM serving infrastructuur is waarschijnlijk niet geoptimaliseerd voor dit type werk.

De Autonome Revolutie Waar Niemand Op Was Voorbereid

Het gekke aan coding agents is dat het logisch klinkt zodra iemand het hardop zegt: ze beantwoorden niet zomaar vragen. Ze voeren plannen uit. Wanneer je een AI coding assistant vraagt om een feature te implementeren of een bug te fixen, start je geen eenvoudige vraag-antwoord transactie—je activeert een autonoom workflow waarbij het model redeneert, shell commando's uitvoert, bestanden leest en aanpast, tests draait en itereert tot het tevreden is (of tot jij ingrijpt).

Het onderzoeksteam verzamelde meer dan 4.300 echte gebruikerssessies, goed voor zo'n 55 miljard tokens, en de patronen zijn opvallend. Elke gebruikersverzoek triggert gemiddeld 8,8 LLM-tools cycli voordat het klaar is. Laat dat even bezinken: voor elke vraag die een developer stelt, zijn er bijna negen rondes van modelgeneratie gevolgd door tooluitvoering. Het model praat niet alleen—het doet dingen. En 88% van alle LLM inference rondes vindt niet plaats als reactie op gebruikersinvoer, maar als reactie op toolresultaten.

Dit heeft enorme gevolgen voor throughput planning. Traditionele chatbots zijn in wezen request-response systemen met af en toe een follow-up. Coding agents lijken meer op langlopende autonome processen met frequente context-switches tussen generatie- en executiefasen. Je autoscaling policies, je request queuing, je caching strategieën—dit alles moet je heroverwegen vanuit het perspectief van autonome multi-step workflows, niet van simple turn-taking gesprekken.

De Input-Output Asymmetrie Die Je Cache Kraakt

Hier is een cijfer dat elke infrastructuur-engineer aan het denken zou moeten zetten: inputs overtreffen outputs met een ratio van 294 op 1. In de geanalyseerde traces lazen modellen 52,56 miljard gecachete input tokens en prefilden 2,34 miljard nieuwe tokens, maar genereerden slechts 186,9 miljoen output tokens. Een typische ronde zit op een 32K tot 256K token prefix en voegt maar een paar honderd tot een paar duizend tokens toe voordat er een paar honderd worden gedecodeerd.

Dit creëert een fundamenteel ander performanceprofiel dan waar de meeste LLM serving systemen op zijn geoptimaliseerd. Traditionele taalmodel-inferentie richt zich sterk op generatiedoorvoer—hoeveel tokens per seconde kunnen we produceren? Maar bij coding agents ligt de bottleneck vaak niet bij decodeersnelheid; het is time-to-first-token (TTFT) nadat tooluitvoering terugkeert. Het team ontdekte dat Codex' TTFT voor elke stap rond de 3,1 seconden ligt, wat goed is voor zo'n 25% van de totale generatietijd van een ronde. Wanneer je negen rondes per request doet, stapelt die overhead zich snel op.

Het caching-verhaal is ook genuanceerder dan het op het eerste gezicht lijkt. Ja, input caching (prefill caching) helpt met de enorme context die coding agents meedragen. Maar de prefill workload is verdeeld tussen gecachete tokens en nieuwe tokens die echte berekening nodig hebben. Korte, incrementele prefills na tooluitvoering hebben andere performancekarakteristieken dan de initiële long-context load. Serving systemen moeten beide efficiënt afhandelen, en de optimale strategieën kunnen verschillen tussen deze gevallen.

Shell Commando's Heersen Nog Steeds

Als je dacht dat coding agents bezig zouden zijn met ingewikkelde redeneringen en complexe refactoring, had je niet helemaal ongelijk—maar de realiteit is rommeliger. Van de 433.000 tool calls in de traces was 76% shell of commando-uitvoering. Builds draaien, tests uitvoeren, git operaties, bestandsmanipulatie via CLI-tools—het onglamoureuze werk dat de dagelijkse praktijk van softwareontwikkeling vormt.

Bestandsedits kwamen op 11%, bestandslezingen en zoekopdrachten op 9%, met planning, sub-agent delegatie en web-lookups als remainder. Deze concentratie in shell commando's is om verschillende redenen belangrijk. Ten eerste zijn dit langstaartige operaties: een simpel ls is snel, maar een volledige test suite draaien of een groot codebase compileren kan minuten duren. De latency-verdeling strekt zich uit over vier ordes van grootte, wat capaciteitsplanning tot een nachtmerrie maakt.

Ten tweede varieert de toolvocabulaire significant tussen agents. Claude Code gebruikte 54 verschillende tools terwijl Codex er 31 gebruikte, maar beide concentrateerden het overgrote deel van hun volume in dezelfde kernset—shell, bestandsedits, bestandslezingen. Dit suggereert dat optimaliseren voor deze high-frequency tools buitenproportionele verbeteringen kan opleveren, zelfs zonder het volledige tool-ecosysteem aan te pakken.

Wat Dit Betekent voor Jouw Infrastructuur

Als je AI-powered development tools bouwt of beheert, wijst dit onderzoek op verschillende concrete punten.

Denk in workflows, niet in requests. Je serving infrastructuur moet rekening houden met het autonome, multi-step karakter van coding agents. Dit betekent langlopende request contexts, meer geavanceerd statemanagement, en batch scheduling mogelijkheden die gerelateerde tool calls groeperen.

Optimaliseer voor de idle gaps. Gebruikers besteden gemiddeld 46,7 minuten tussen requests, ondanks een mediane think time van slechts 1,4 minuten. De verdeling is extreem heavy-tailed—sommige developers itereren snel terwijl anderen een request starten en uren later terugkomen. Slim prefetching en re-prefill strategieën tijdens deze idle periodes kunnen perceptuele latency drastisch verminderen zonder de compute-kosten te verhogen.

Scheid je prefill en decode paths. De 294:1 input-output ratio betekent dat je prefill berekening waarschijnlijk je dominante kostenpost is. Incrementele prefills na tooluitvoering hebben andere optimalisaties nodig dan initiële context loading. Overweeg aparte resource pools of scheduling policies voor deze verschillende workload types.

Vergeet de tool execution infrastructuur niet. Wanneer 76% van agent-activiteit shell commando's betreft, worden je container orchestration, filesystem access patterns en build tool caching first-class concerns voor AI agent serving. De model inference is slechts onderdeel van de pijplijn.

De Weg Vooruit

Het TraceLab team heeft hun trace collection en analysis pipeline open source gemaakt, waardoor infrastructuurteams hun eigen traces kunnen genereren en optimaliseren voor echte gebruikspatronen in plaats van synthetische benchmarks. Dit soort real-world data is precies wat de AI infrastructuurruimte nodig heeft nu het volwassener wordt—van "maak het werkend" naar "maak het schaalbaar."

Voor de NameOcean Vibe Hosting community onderstrepen deze inzichten waarom we investeren in infrastructuur die verder gaat dan eenvoudige GPU-toewijzing. AI coding agents serveren draait niet alleen om pure compute—het gaat om het begrijpen van de unieke eigenschappen van agentic workloads en het bouwen van systemen die de autonome, multi-step, tool-heavy realiteit aankunnen van hoe developers deze tools daadwerkelijk gebruiken.

Het tijdperk van de coding agent staat nog maar aan het begin, en de infrastructuurkeuzes die we vandaag maken zullen bepalen hoe efficiënt deze tools ontwikkelaars de komende jaren gaan bedienen.