Van 7 jaar naar 7 dagen met agentische AI

Als u ooit naar een COCOMO II-spreadsheet hebt gestaard die 33 kalendermaanden voorspelde voor een project dat uw team in twee sprints opleverde, kent u het probleem al: elk schattingsmodel dat vandaag in gebruik is, werd gekalibreerd in een wereld waarin ontwikkelaars elke regel zelf typen, contextwisselingen tijd kosten en de kalender om 17.00 uur stopt. Die wereld bestaat niet meer. We hebben onlangs een applicatie van 286 KLOC met 672 bestanden en meerdere subsystemen vanaf nul ontwikkeld (protocollaag, datalaag, rendering-engine, platformintegratie) en in 7 dagen een alfaversie bereikt die klaar was om te testen. Het volledige panel van modellen (COCOMO Basic/Intermediate/Post-Architecture, Function Points, SLOC-basislijn, Putnam/SLIM) gaf een mediane voorspelling van 30,3 kalendermaanden. De mediane productiviteitsfactor: 4.240×. Zelfs de meest conservatieve basislijn (25 SLOC per ontwikkeldag voor complexe systemen) zat er 1.433× naast. De modellen zijn niet fout. Ze worden verkeerd toegepast. Hieronder vindt u de uitsplitsing per model, de empirische kalibratie bij dezelfde auteur, en wat de RCT-literatuur van 2024 tot en met 2026 werkelijk zegt over waar agentische AI de doorlooptijd verkort, en waar niet.

Het project dat de schattingen brak

Bij RIADVICE hebben we onlangs een complexe applicatie met veel functionaliteit ontwikkeld, van het soort dat meerdere subsystemen coördineert binnen een gedistribueerde architectuur. Het gaat om een native, platformonafhankelijke omgeving voor mobiel en desktop vanuit één codebase, gedreven door marktvereisten die om een nieuwe implementatie vroegen. De codebase laat de omvang zien:

• 286.662 SLOC (~286 KLOC), verdeeld over 672 bronbestanden
• 1.329.399 regels totale churn: 862.488 toevoegingen en 466.911 verwijderingen
• 700 commits in 7 actieve ontwikkeldagen tot de eerste alfaversie die klaar was om te testen
• Volledige internationalisering in tientallen locales
• Meerdere sterk uiteenlopende subsystemen (protocolafhandeling, gegevensbeheer, rendering en platformintegratie), allemaal vanaf nul gebouwd voor de doelomgeving

Dit was geen wrapper of dunne nieuwe skin. Het was een volledig nieuwe, native implementatie, gebouwd om te voldoen aan marktvereisten waaraan de bestaande oplossingen niet konden voldoen. Nog voordat ik één regel schreef, heb ik een eigen analysetool aan het project gekoppeld die het volledige panel van gangbare modellen voor het schatten van softwareontwikkelinspanning op de codebase loslaat terwijl die groeit. Het doel was eerlijk: de kloof meten tussen wat klassieke modellen voorspellen en wat een AI-ondersteunde oplevering werkelijk oplevert. De resultaten zijn geen afrondingsfout. Ze zijn een breuk in categorie.

Wat de schattingsmodellen voorspelden en wat er werkelijk gebeurde

De tool voert elk belangrijk schattingsmodel uit de literatuur over software engineering uit: COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached en Embedded, afgesteld), COCOMO II Post-Architecture (afgesteld), Function Points, de SLOC Productivity Baseline en Putnam/SLIM. Elk model is gekalibreerd op het projecttype met de gepubliceerde constanten uit de oorspronkelijke bronliteratuur.

Schattingsmodel	Voorspelde inspanning	Voorspelde doorlooptijd	Versnelling t.o.v. werkelijkheid
COCOMO Basic (Organic)	913 persoonsmaanden	33,3 maanden	2.282×
COCOMO Basic (Semi-Detached)	1.696 persoonsmaanden	33,7 maanden	4.240×
COCOMO Basic (Embedded)	3.200 persoonsmaanden	33,1 maanden	8.000×
COCOMO Intermediate (Semi-Det., afgesteld)	1.259 persoonsmaanden	30,4 maanden	3.148×
COCOMO Intermediate (Embedded, afgesteld)	2.376 persoonsmaanden	30,1 maanden	5.940×
COCOMO II Post-Architecture (afgesteld)	1.703 persoonsmaanden	30,3 maanden	4.257×
Function Points (ruwe schatting)	17,9 persoonsmaanden	7,5 maanden	45×
SLOC Productivity Baseline (25 SLOC/ontwikkeldag)	573 persoonsmaanden	573,3 maanden	1.433×
Putnam/SLIM	overgeslagen (duur < 30 dagen; T 4/3 explodeert)	n.v.t.	n.v.t.

De mediane productiviteitsfactor over alle modellen is 4.240×. Zelfs het meest conservatieve model voorspelt een doorlooptijd die ongeveer 1.400 keer langer is dan wat er werkelijk gebeurde. Het meest optimistische model, Function Points, voorspelde nog altijd 7,5 kalendermaanden: 45× langer dan de werkelijke 7 dagen. Volgens de modellen had dit project ergens tussen 7 maanden en 47 jaar moeten duren. Een alfaversie was in 7 dagen klaar om te testen.

De modellen spreken elkaar tegen, met een factor 50 tot 8.000

Deze modellen zijn het niet met elkaar eens. Op dezelfde codebase lopen de voorspellingen uiteen van 17,9 tot 3.200 persoonsmaanden: een spreiding van 178×. De SEAA 2013-benchmark van COCOMO II, SEER-SEM, SLIM en TruePlanning over 51 echte projecten vond een MMRE van 50 tot 100%. Een evaluatie uit 2023 op de NASA-dataset van COCOMO vond een MMRE van bijna 1,0 en een PRED(0,25) van 0,0: geen enkel project werd binnen de foutmarge van 25% geschat. De modellen zijn nooit ontworpen voor een AI-ondersteund project. Maar de omvang van de kloof, zelfs als we rekening houden met de onnauwkeurigheid van de modellen, vertelt ons dat er iets structureel is veranderd.

Wat het onderzoek werkelijk zegt over agentische AI en de productiviteit van ontwikkelaars

Het cijfer van 4.240× is extreem, en ik wil het niet overdrijven. Greenfield-scaffolding blaast de churn op, en SLOC is een zwakke graadmeter voor waarde. Laten we daarom naar de peer-reviewed literatuur kijken. Assistenten in de stijl van Copilot leveren bescheiden, maar echte winst op. Peng et al. (2023) stelden vast dat ontwikkelaars met een AI-pair-programmer een taak 55,8% sneller voltooiden (95%-BI: 21 tot 89%). De RCT van Microsoft, Accenture en een Fortune 100-bedrijf (2025), de grootste studie tot nu toe met n=4.867, vond een toename van 26% in voltooide taken. De interne RCT van Google (2024) vond een vermindering van ~21% in de tijd per taak. Het veldexperiment van BIS en Ant Group (2024) mat een toename van 55% in codeproductie bij junior medewerkers. De eerlijke samenvatting: 1,26× tot 1,56× bij geschikte taken. Echt, maar niet ingrijpend. Agentische AI werkt in een ander regime. De review van Cognition over Devin uit 2025 meldde klantresultaten van 10× bij ETL-migraties, 14× bij migraties van Java-versies en 20× bij beveiligingsfixes. Nubank meldde een efficiëntieverbetering van 12× en een kostenbesparing van 20× bij een refactoring van miljoenen regels die eerder was geschat op meerdere jaren werk voor duizend engineers. Ons project valt precies in dit bereik: het commithistogram toont dichte pieken om 22.00, 00.00 en 01.00 uur, het kenmerk van sessies die door agents worden aangestuurd. Het tegenbewijs is echt. De RCT van Metr.org uit 2025 (16 ervaren ontwikkelaars, 246 taken in volwassen projecten) stelde vast dat AI de voltooiingstijd met 19% verlengde: het vertraagde ervaren ontwikkelaars in codebases die ze kenden. Een difference-in-differences-studie uit 2026 van 807 GitHub-repository's die AI-tools hadden ingevoerd (He et al., MSR ’26) vond een “tijdelijke” snelheidswinst en een “blijvende” toename van codecomplexiteit die op lange termijn tot vertraging leidde. De titel zegt genoeg: Speed at the Cost of Quality. De consensus: AI helpt veel bij greenfield- en gestructureerde ontwikkeling, helpt bescheiden bij aanvultaken en kan de snelheid schaden in volwassen codebases. De kwaliteitsschuld is echt.

Waarom de modellen breken: drie structurele verschuivingen

Geen van de kostenfactoren in klassieke modellen heeft een instelling voor “de ontwikkelaar beschikt over een autonome agent die nooit slaapt en de hele codebase in zijn context houdt”. Drie verschuivingen laten de doorlooptijdcurve ineenstorten:

1. Het typknelpunt is verdwenen.

Modellen gaan ervan uit dat een aanzienlijk deel van de inspanning mechanisch is: boilerplate, scaffolding, repetitieve refactorings, lokalisatiebestanden en andere gestructureerde gegevens. In dit project bestaat een groot deel van het volume uit zeer regelmatige tekst en koppelcode die een agent in bulk kan genereren of omzetten. Zelfs de handgeschreven code (scaffolding, constructors, platformlijm) wordt nu in golven gegenereerd, niet regel voor regel getypt.

2. De kosten van contextwisselingen storten in.

Een mens die wisselt tussen de protocollaag, de datalaag en de rendering-engine betaalt telkens een prijs om de context opnieuw te laden. Een agent die de hele repository van 672 bestanden heeft gelezen, betaalt die prijs één keer. Die asymmetrie stapelt zich bij een codebase van deze omvang snel op.

3. De kalender is niet langer het knelpunt.

Modellen rekenen persoonsmaanden om naar kalendermaanden met een bezettingsformule die uitgaat van een menselijke werkdag. Agentsessies lopen 's nachts door. Het commithistogram toont aanhoudende productie van 07.00 tot 01.00 uur: 18 actieve uren, geen 8.

De empirische kalibratie bij dezelfde auteur

Parametrische modellen verschillen ordes van grootte van elkaar, dus heb ik ook een empirische kalibratie over projecten heen uitgevoerd. Daarin vergelijk ik mijn eigen code-churn per persoonsdag vóór en na de invoering van een agentische AI-tool, in drie andere productierepository's binnen hetzelfde ecosysteem:

Project	Churn/ontwikkeldag vóór AI	Churn/ontwikkeldag met AI	Factor
Project A (load balancer)	673	2.056	3,1×
Project B (rapportagedienst)	239	2.127	8,9×
Project C (verwerkingsdienst)	1.322	982	0,7×
Totaal (gemiddelde / mediaan)	n.v.t.	n.v.t.	4,2× / 3,1×

Dezelfde auteur, hetzelfde domein, echt onderhoudswerk. De empirische factor is 3 tot 9×: veel conservatiever dan het greenfield-cijfer van 4.240×, en in lijn met de bovenkant van het gepubliceerde onderzoek naar agentische AI. Eén project werd zelfs trager: de winst hangt af van de taak en is niet universeel.

Wat dit betekent voor projectplanning

Als u softwareprojecten nog steeds schat met ongekalibreerde modellen en een basislijn van 25 SLOC per dag, zit u bij AI-ondersteund werk een tot drie ordes van grootte naast. Dit doen wij bij RIADVICE:

1. Kalibreer op uw eigen historie. Vergelijk uw eigen codeproductie per persoonsdag met en zonder AI. Dat is goedkoper en eerlijker, en levert een bereik van 3 tot 9× op dat u in een projectplan kunt verdedigen.
2. Maak onderscheid tussen greenfield en onderhoud. De factor van agentische AI is het grootst bij greenfield- en gestructureerde ontwikkeling en het kleinst (soms negatief) bij onderhoud van volwassen codebases. Pas niet één getal op beide toe.
3. Reserveer budget voor kwaliteitsschuld. AI-snelheid gaat gepaard met een blijvende toename van complexiteit. Plan een stabilisatiefase en meet die: volg de cyclomatische complexiteit en voer bij elke release copy-paste-detectie uit.
4. Schat de hele curve, niet alleen het begin. Een snelheidswinst van 10× die uw defectdichtheid verdubbelt, is geen winst van 10×: het is een planning die naar voren is gehaald ten koste van een langere stabilisatiestaart.

Kortom

Een project dat volgens elk schattingsmodel 7 maanden tot 47 jaar had moeten duren, bereikte in 7 dagen een alfaversie die klaar was om te testen. De mediane factor van 4.240× hoort in niemands projectplan thuis. Maar het is een duidelijk signaal dat de doorlooptijd van complexe softwareontwikkeling opnieuw wordt samengeperst door dezelfde kracht die de inspanning samenperst. Het gepubliceerde onderzoek laat zien dat AI alles oplevert van een duwtje van 1,26× tot een sprong van 20×, met een reëel risico op negatief rendement in volwassen codebases en een meetbare prijs in kwaliteit. De modellen die ons vertelden dat dit project decennia zou duren, zijn dezelfde modellen die vandaag nog in de schattingsspreadsheets van grote organisaties draaien. De vraag is niet of agentische AI de doorlooptijd van projecten verandert: het onderzoek heeft die vraag beantwoord. De vraag is of uw schattingspraktijk het bewijs heeft bijgehouden. Als uw cijfers nog altijd uit een model uit 1981 komen dat op COBOL en assembly is gekalibreerd, is het tijd om opnieuw te kalibreren, of op zijn minst om niet langer te geloven in de kalender die het uitdraait.

“Er is nog veel ruimte voor verbetering om de voorspellingsuitdagingen uit de praktijk beter aan te pakken.”

Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013

🏆 Betrouwbare engineering- en cloudexpertise

RIADVICE, uw vertrouwde partner in software engineering

Wij ontwerpen, bouwen en implementeren complexe softwaresystemen met de engineeringdiscipline en de tooling om in het AI-tijdperk te leveren: op tijd, binnen budget en met kwaliteit.

Meer over onze diensten →

📚 Bronnen en verder lezen

Dit artikel steunt op peer-reviewed onderzoek, gerandomiseerde gecontroleerde studies en praktijkrapporten uit de industrie over de productiviteit van AI-ondersteunde softwareontwikkeling en het schatten van softwareontwikkelinspanning:

• Studies naar AI-productiviteit (RCT's en veldexperimenten)
• Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590: 55,8% kortere voltooiingstijd per taak
• Cui, R., et al. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers Microsoft Research: n=4.867, +26,08% voltooide taken
• Dam, S., et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv:2410.12944: RCT van Google, n=96, ~21% minder tijd per taak
• Becker, B., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity Metr.org: RCT, n=16, 246 taken; AI verlengde de voltooiingstijd met 19%
• He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects, arXiv:2511.04427: DiD-studie van 807 GitHub-repository's; MSR ’26
• Evolver Business Solutions (2026). For a few tokens more: The productivity effect of AI tools on software development tasks Replicatie met een resultaat van +13% (niet significant)
• Industrierapporten over agentische AI
• Cognition AI (2025). Devin’s 2025 Performance Review: Learnings From 18 Months of Agents At Work 10× bij ETL-migraties, 14× bij Java-migraties, 20× bij beveiligingsfixes
• Nubank / Cognition. How Nubank refactors millions of lines of code to improve engineering efficiency with Devin 12× in engineeringuren, 20× kostenbesparing bij een refactoring van miljoenen regels
• BIS / Ant Group (2024). Veldexperiment; +55% codeproductie, vooral bij junior medewerkers
• Schatten van softwareontwikkelinspanning: grondslagen en nauwkeurigheid
• Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall: het oorspronkelijke COCOMO
• Boehm, B. W., Abts, C., & Chulani, S. (2000). Software Cost Estimation with COCOMO II. Prentice Hall: gekalibreerd op 161 projecten
• SEAA 2013. Accuracy of Contemporary Parametric Software Estimation Models COCOMO II, SEER-SEM, SLIM en TruePlanning over 51 projecten; MMRE 50 tot 100%
• Kemerer, C. F. (1993). An empirical validation of software cost estimation models, Communications of the ACM
• Nguyen, V., et al. (2019). Determining relevant training data for effort estimation using window-based COCOMO calibration Kalibratie op basis van tijdvensters over 341 + 93 projecten
• Ahmad, M., & Wani, M. A. (2023). Evaluation of COCOMO Model Accuracy in Software Effort Estimation MMRE ~1,0, PRED(0,25) = 0,0
• Putnam, L. H. (1978). A general empirical solution to the macro software sizing and estimation problem. IEEE TSE: het Putnam/SLIM-model

⚡ RIADVICE.com levert betrouwbare engineering, cloudexpertise en softwareoplossingen van enterpriseniveau: op tijd, binnen budget en met kwaliteit.