In het kort: een team dat met agentic coding begint, levert eerst minder features op. Agents zijn sterk in betrouwbaar wijzigen in een complex systeem, maar dat vraagt vangrails: testdekking, een releaseproces dat dagelijks naar productie kan en security op orde. Daarna de legacy. Reken op 6 tot 12 maanden voordat het team meer oplevert dan ervoor.

Voor wie? IT-managers, CTO’s en tech leads die met hun team aan agentic coding beginnen en op snelle versnelling rekenen.

"Met agentic coding zijn we binnenkort drie keer zo snel!" Dat hoor ik van managers als hun team ermee begint. Sommigen rekenen op nog veel meer.

Logisch. Thuis bouw je op zaterdagmiddag snel iets werkends, zonder één regel zelf te typen. Dat tempo wil je in je team.

Zo werkt het niet. De eerste maanden met agents lever je met een team eerder minder features op dan vroeger. Waar komt die vertraging vandaan en wanneer slaat hij om?

Cartoon: een manager plakt stickies in de Done-kolom van een vol kanban-bord en zegt dat het team met agentic coding binnenkort drie keer zo snel is; drie developers kijken bedenkelijk en een van hen houdt een sticky omhoog met Eerst de basis op orde
De Review-kolom staat vol en Done moet nog komen.

Waarom gaat het thuis zo veel sneller?

Een nieuw hobbyproject heeft geen geschiedenis. Vibecoden begint bij nul. Er zijn geen klanten die op bestaand gedrag rekenen en er is geen release die mis kan gaan. Wat de agent bouwt, hoeft alleen vandaag te werken.

De codebase van je team heeft die geschiedenis wel: tien jaar code, koppelingen die niemand meer helemaal overziet, een strikt releaseproces, security-eisen en integraties die draaien op gedrag dat nergens gedocumenteerd staat. Elke wijziging moet daar doorheen. Dat zorgt voor veel complexiteit.

In een team gaat de meeste tijd naar begrijpen wat je raakt en veilig uitrollen. Een agent die sneller typt, verandert daar weinig aan.

Voor dat verschil bestaat inmiddels een naam. Andrej Karpathy, de bedenker van de term vibe coding, noemt het professionele werk met agents sinds februari 2026 agentic engineering[1]. Agentic omdat je de code meestal niet meer zelf schrijft en agents aanstuurt, engineering omdat daar vakkennis voor nodig is. Simon Willison verzamelt de bijbehorende werkwijzen in een gids[2].

Waar zijn agents goed in bij complexe systemen?

Ook in zo’n systeem zijn agents goed in hun werk: een wijziging betrouwbaar opleveren, met het uitzoekwerk eromheen. Een agent leest een oude repo uit en vindt de reden achter een vaag if-statement in een commit uit 2017. Hoe dat gaat, beschreef ik in de repo waar niemand meer in durft.

Agents zijn ook sterk in migraties. Mijn Vue 2-frontend telde ruim honderd componenten. Agents zetten ze stuk voor stuk om naar Vue 3, in vijf werkdagen waar ik zonder agents vijf weken voor had gerekend. Dat verhaal staat in legacy: herbouwen of migreren.

Betrouwbaar wijzigen in een complex systeem kost wel meer tijd en voorbereiding dan thuis op zaterdag. De agent heeft context nodig over hoe het systeem in elkaar zit en hoe je bewijst dat het na de wijziging nog werkt. Die context opbouwen is werk dat eerst moet gebeuren.

Wat gebeurt er zonder vangrails?

Zet je een team zonder de juiste skills en context op agents, dan verdrinkt het in code die niemand meer kan beoordelen. Er komt meer binnen dan het team kan reviewen. Wat blijft liggen, heet verification debt: verificatiewerk dat doorschuift terwijl de tests groen staan.

DORA mat in 2024 wat er gebeurt als AI-adoptie toeneemt zonder die basis. Bij 25% meer AI-adoptie daalde de doorvoer van softwarelevering naar schatting met 1,5% en de stabiliteit met 7,2%[3]. Volgens de onderzoekers levert een beter ontwikkelproces niet vanzelf betere delivery op zolang kleine batches en robuuste tests ontbreken.

In het DORA-rapport van 2025, onder bijna 5.000 respondenten, was de doorvoer omgeslagen naar positief. De stabiliteit bleef negatief[4]. De kern van dat rapport is dat AI versterkt wat er al is.

In datzelfde rapport zagen teams met snelle feedback en een los gekoppelde architectuur winst. Wie vastzat in strak gekoppelde systemen en trage processen, zag weinig tot geen voordeel.

Dat het anders voelt dan het is, beschreef ik in gevoel versus de cijfers. In het METR-onderzoek van 2025 dachten ervaren developers 20% sneller te zijn, terwijl ze 19% trager waren[5]. De vervolgmeting van februari 2026 geeft nog geen harde versnelling. METR verwacht dat developers inmiddels sneller zijn dan begin 2025, maar noemt het eigen bewijs daarvoor zwak[6].

Snelheid maken kan pas als er goede vangrails staan.

In welke volgorde bouw je het op?

Dit is de volgorde die ik aanraad. Elke stap maakt de volgende mogelijk.

  1. Kwaliteit, releaseproces en security. Uitgebreide testdekking die verificatiebewijs levert, een pipeline die elke dag kan deployen naar productie, review op de plekken waar het risico zit en afspraken over wat genoeg bewijs is. Agents helpen hier al mee: een testagent die de kritieke flows doorklikt is zo’n vangrail. Security hoort in deze stap, want kwetsbaarheden in oude dependencies worden steeds sneller gevonden.
  2. Legacy uitbouwen. De migraties die al jaren doorschuiven. Met vangrails durf je ze aan. Agents doen het herhalende werk en elke opgeruimde afhankelijkheid maakt de volgende wijziging voorspelbaarder.
  3. Het gas erop. Pas nu kan meer parallel werk ook meer features opleveren, omdat het systeem de extra wijzigingen aankan.

Hoe lang duurt het voordat het meer oplevert?

Ik schat dat het 6 tot 12 maanden duurt voordat een team meer oplevert dan ervoor. De basis op orde brengen kost eerst capaciteit. Daarna gaat het steeds een beetje sneller. Een team dat tests en pipeline al op orde heeft, zit aan de korte kant van die schatting.

Bij mijn eigen SaaS, die ik zeven jaar geleden bouwde, hield ik die volgorde aan toen ik het overzette naar AI-native softwareontwikkeling. Eerst kwaliteit en security op orde, met testagents en reviewstappen. Toen de legacy: .NET Core 2.1 naar .NET 10, Vue 2 naar Vue 3 en oude rommel opruimen.

Sinds ongeveer 2 maanden pas merk ik dat er meer nieuwe features komen dan vroeger. Dat versnelt nog steeds.

Eerlijk erbij: dit is één developer met agents op eigen producten. Bij een team is de volgorde dezelfde. De doorlooptijd hangt af van waar je begint.

Wat betekent dit voor jullie planning?

Ik zou het management beloven wat die eerste maanden opleveren: testdekking die bewijs levert en een pipeline die dagelijks naar productie kan. Daarna legacy die verdwijnt. Versnelling in het eerste kwartaal hoort daar nog niet bij. Dat zijn meetbare resultaten, ook als er minder features op de sprintdemo staan.

Snelheid maken met agents vraagt eerst een investering in de basis. Pas daarna levert het meer features op. En kom je over twee jaar op drie keer zo snel uit met je team? Dan heb je het geweldig gedaan.

Daarom praat ik vanaf nu liever over agentic engineering dan over agentic coding. Het coderen gaat snel. Het engineeren eromheen is de investering.

Wat moet er bij jullie eerst op orde zijn voordat het gas erop kan?

Bronnen
  1. Andrej Karpathy op X (februari 2026): van vibe coding naar agentic engineering ↩
  2. Simon Willison, "Writing about Agentic Engineering Patterns" (23 februari 2026) ↩
  3. Google Cloud, "Announcing the 2024 DORA report" (23 oktober 2024): 25% meer AI-adoptie gaat samen met 1,5% minder doorvoer en 7,2% minder stabiliteit ↩
  4. Google Cloud, "Announcing the 2025 DORA Report" (23 september 2025): AI als versterker, bijna 5.000 respondenten ↩
  5. METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (juli 2025) ↩
  6. METR, "We are Changing our Developer Productivity Experiment Design" (februari 2026) ↩