AI Coding Agent: bottleneck verplaatsen, niet verwijderen

AI Coding Agent: de bottleneck wordt verplaatst, niet opgelost

Onze support queue werkte tickets af in negen minuten, maar dan zaten ze vier uur in wachtstand voordat een agent ze aanpakte. Exact dezelfde situatie zie je nu bij engineering teams met een AI coding agent: de code wordt in minuten geschreven, vervolgens wacht die. Als je een AI coding agent hebt geïntroduceerd en de throughput van je team nauwelijks is gestegen, heb je geen gebroken tool gevonden. Je hebt je werkelijke bottleneck gevonden, en die zit niet waar je dacht.

Dat is de bruikbare manier om te kijken wat er in 2026 gebeurt in engineering organisaties. Een AI coding agent (software die codewijzigingen plant, schrijft en vaak test met minimale menselijke invoer) verwijdert wrijving uit de schrijfstap. Maar schrijven was zelden het poste limitant (de beperkende stap, degene die de throughput van de hele lijn dicteert) op een softwarepipeline. Review, CI en deployment waren dat meestal. Versnel je een niet-bottleneck, en je krijgt niet meer afgewerkt werk. Je krijgt een grotere wachtrij voor wat erna komt.

Waar gaat de bottleneck heen na een AI coding agent?

Twee industrie datasets uit 2026 wijzen dezelfde kant uit. In het rapport State of Software Delivery van CircleCI steeg de feature-branch throughput van het mediane team 15% jaar-op-jaar, maar de main-branch throughput (het aantal wijzigingen dat werkelijk naar productie gaat) daalde 7% over dezelfde periode (CircleCI, 2026 State of Software Delivery). Meer werk komt de voorkant in, minder werk verlaat de achterkant.

Apart hiervan, in GitLab's developeronderzoek via InfoQ, was 85% het eens dat AI de bottleneck van codeschrijven naar review en validatie verplaatste, en zei 79% dat het totale delivery proces niet is meegekomen met codesnelheid (InfoQ, AI coding outpaces governance). Dat is geen tooling-gat. Dat is een bottleneck die verplaatste en niemand hermat de lijn.

Little's Law geeft niets om of code sneller geschreven wordt

Little's Law vertelt je waarom dit gebeurt, en het is niet specifiek voor software. Het is dezelfde wiskunde achter een fulfillment center's pick queue of een ziekenhuis's ontslagproces:

WIP = Throughput × Cycle Time

WIP is work-in-process, alles wat nu in je pipeline zit (open PRs, tickets in review, orders gepickt maar niet verpakt). Throughput is afgewerkte eenheden per tijd. Cycle Time is hoe lang één eenheid van start tot finish duurt.

Versnel code generatie zonder review-capaciteit aan te raken, en je duwt meer eenheden per uur in een fase waarvan de throughput onveranderd is. WIP moet ergens heen. Het stapelt op als een open-PR backlog, een groeiende merge queue, of reviewers die diffs sneller scannen en meer missen. Geen daarvan is gratis. Een pull request die drie extra dagen wacht kost geen niets: het kost context. De auteur is verder gegaan, de reviewer moet de hele wijziging opnieuw laden, en rework wordt duurder hoe langer het wacht.

"AI agent" verschijnt nu op meer plekken dan alleen de codestap

Waard om twee dingen uit elkaar te houden die onder "AI coding agent" worden samengegooid. Sommige tools zijn smal gebouwd om broncode in een repo te schrijven en aan te passen. Anderen zijn general-purpose agents met codeschrijven naast research, browsen en documentgeneratie.

Genspark is het tweede soort: een no-code "Super Agent" die kan browsen, slides of docs genereren en code schrijven en uitvoeren vanuit één prompt. Die breedte is handig voor een generalist, maar het is een ander tool voor een ander doel dan iets specifiek gebouwd om in je CI pipeline te leven en PRs tegen je echte codebase te openen. Match het tool's ontwerp met de pijplijn-stap die je wilt deblokkeren, niet andersom.

Manus gaat nog verder, opererend in een volledige virtuele computer (browser, terminal, bestandssysteem) om taken van begin tot eind te plannen en uit te voeren en een afgewerkt resultaat terug te geven. Voor een ops team is dat een nuttig mentaal model zelfs buiten code: een agent die een heel unit work afmaakt, niet alleen de snelste substap, is degene die werkelijk throughput beweegt.

PCE: het ene getal dat je vertelt of de agent helpt

Process Cycle Efficiency (PCE) is de verhouding van waarde-toevoegende tijd tot totale cyclustiijd, en het is de eerlijkste manier om te controleren of een AI coding agent je pipeline verbeterde of de bottleneck alleen verplaatste:

PCE = Value-Added Time / Total Cycle Time

Voordat je een AI coding agent aanneemt, meet de huidige verdeling: hoeveel van een typische wijziging's levensduur, van eerste commit tot merged in productie, wordt werkelijk besteed aan codeschrijven of review, versus wachten in queue. De meeste teams hebben dit getal nooit opgehaald en zijn verrast. PCE onder 25% is gangbaar op software pipelines, wat betekent dat drie kwart van een wijziging's totale levensduur wacht, niet wordt bewerkt.

Voer dezelfde meting uit 30 tot 60 dagen na rollout. Als PCE omhoog ging, bevrijdde de agent echte capaciteit en je team gebruikt die. Als PCE plat bleef of daalde, versnelde de agent een al-snelle stap en de extra output zit in queue, onzichtbaar totdat iemand open PRs op een vrijdagavond telt. Dit is exact het soort lezing waar een AI analyse-laag zijn plaats verdient: het is niet genoeg om PCE te zien bewegen, je hebt het verdict nodig op welke stap het verschil absorbeert, en dat leest sneller van een geautomatiseerde uitsplitsing dan van iemand met een Kanban bord.

Drie signalen dat review, niet de agent, je beperking is

Een paar patronen verschijnen consistent zodra teams meten in plaats van aannemen:

• Open PR aantal stijgt terwijl merge aantal plat blijft. Meer eenheden de lijn in, zelfde aantal eruit. Klassiek WIP opbouw voor een onveranderde bottleneck.

• Gemiddelde PR-grootte groeit. Een AI coding agent die een compleet feature in één keer genereert produceert grotere diffs dan een human die incrementeel typt. Grotere diffs duren langer per PR, wat reviewer throughput krimpt zelfs als headcount en review-snelheid per regel constant zijn.

• Tijd tot eerste review stijgt sneller dan tijd tot merge-na-approval. Als het wachten vooral voordat iemand kijkt, dat's een queueing probleem (niet genoeg review-capaciteit, of reviews niet geprioriseerd), niet een review-kwaliteitsprobleem.

Niets hiervan vereist exotische tooling om bij te houden. Een weekelijks pull van je git host's API, geplot tegen de week je agent rollout, is genoeg om de vorm van de verschuiving te zien.

Wat een support queue goed doet dat engineering pipelines missen

Support en fulfillment operaties vechten dit exacte probleem langer dan AI coding agents bestaan, en de fix generaliseert schoon. Een queue die first-contact tickets in negen minuten beantwoordt maar vier uur neemt om een specialist tier te bereiken is geen staffing verhaal over de specialists die traag zijn. Het's een signaal dat de snelle tier over-resourced is relatief tot wat stroomafwaarts is, en dat meer tickets in de voorkant trekken niet helpt totdat de achter tier's capaciteit verandert.

Engineering teams slaan deze stap constant over omdat code review niet op een dashboard lijkt als een tickettelling. Het's PRs stil zittend in "wachttend op review" staat, makkelijk niet op te merken totdat iemand vraagt waarom een twee-weken-oud feature nog niet gebouwd. Theory of Constraints (het idee dat een systeem's output gelimiteerd is door zijn enige beperkende stap, niet de som van elke stap's individuele snelheid) zegt de fix is nooit "maak het snelle deel sneller." Het's vind de werkelijke beperkende stap, bescherm haar capaciteit, en besluit dan pas of het snelle deel meer snelheid nodig heeft.

Er's een tweede, stille beperking die een paar maanden na een AI coding agent meer code, sneller verstuurt: documentatie drift. Niemand merkt totdat een nieuwe engineer's onboarding twee keer zo lang duurt omdat de docs een systeem beschrijven dat drie sprints geleden veranderde. Een docs-as-code platform als GitBook, die synchroniseert met dezelfde repo waar de agent naar commit, houdt in ieder geval het papierpad niet verder achter dan de code zelf. Het lost de review bottleneck niet op, maar het voorkomt dat er een tweede in het donker vormt.

Moet je je AI coding agent opzettelijk vertragen?

Soms ja, en dat's niet populair om te zeggen over een tool waar iedereen opgewonden over is. Als je review capaciteit voor de komende twee kwartalen vast is (headcount bevroren, reviewers al op capaciteit), laat een agent de PR-inkomsnelheid verdrievoudigen: het creëert niet meer afgewerkte, geimplementeerde features. Het creëert een langere queue en, per CircleCI data hierboven, een lagere main-branch success rate, omdat reviewers onder volume druk meer missen.

De eerlijke zet in dat geval is begrenzen hoeveel een agent per cyclus genereert, of gating haar output achter een pre-review pass (linting, automated test coverage checks, een kleinere-diff beleid) voordat het ooit een menselijke reviewer bereikt. Dat's geen anti-AI positie. Het's dezelfde logica als niet meer eenheden op een lijn inplannen dan je traagste station kan absorderen.

Als de werkelijke beperking reviewer aandacht in plaats van reviewer headcount blijkt te zijn, workflow agents gebouwd voor triage en routing, als Lindy AI inbox en notificatie overhead rond een team's dag aan het handelen, kunnen echte review uren bevrijden zonder je codebase direct aan te raken. Waard testen voordat je aanneemt de fix moet "meer reviewers huren" of "meer agent seats kopen" zijn.

Waar je werkelijk volgende moet investeren

Voer de PCE berekening uit voordat je agent gebruik verder uitbreidt, niet daarna. Als value-added tijd als aandeel van totale cyclustiijd niet is bewogen sinds rollout, koop nog niet meer agent seats. Zet de volgende budgetregel in review capaciteit, CI throughput, of merge-queue automation, wat de data wijst, en herrun het getal in 30 dagen.

Als PCE wel verbeterd en review houdt gelijke tred, dat's het signaal om het agent's bereik uit te breiden, niet eerder. Meet eerst. De teams echte throughput winsten krijgen van een AI coding agent zijn niet degenen die het het snelst hebben aangenomen. Ze zijn degenen die hun werkelijke beperkende stap hebben gevonden en capaciteit daar hebben gerepareerd voordat ze de snelle stap nog sneller laten lopen.