De werkelijke impact van AI op het werk van ontwikkelaars meten, vereist een onderscheid tussen wat gebaseerd is op gevoel en wat gebaseerd is op verifieerbare gegevens. De tools voor codegeneratie nemen toe, net als de beloften van productiviteitswinst. Het DORA 2025-rapport en verschillende recente gecontroleerde proeven maken het mogelijk om deze beloften te confronteren met de resultaten die in de praktijk zijn waargenomen.
AI-productiviteit en softwarestabiliteit: wat het DORA 2025-rapport meet
Het DORA 2025-rapport legt een positieve relatie bloot tussen de adoptie van AI en de leveringssnelheid. Teams die code-assistenten gebruiken, leveren meer functionaliteiten in een bepaalde periode.
Ditzelfde rapport identificeert een blijvende negatieve relatie met de stabiliteit van producties. Met andere woorden, sneller produceren garandeert niet beter te produceren. Incidenten na implementatie nemen niet proportioneel af ten opzichte van de geleverde code.
Een vaak genegeerd punt in concurrerende analyses: AI heeft de neiging om bestaande praktijken binnen een team te versterken. Een team met goede review- en testpraktijken ziet zijn resultaten verbeteren. Een team met fragiele processen ziet zijn zwaktes verergeren. De tool is geen corrector, maar een versterker. Hulpbronnen zoals codyx.org maken het mogelijk om de verschillende benaderingen van codegeneratie in deze context te verkennen.
Gecontroleerde proeven over codegeneratie: tegenstrijdige resultaten
De beschikbare studies komen niet tot een eenduidige conclusie. De onderstaande tabel geeft een samenvatting van de waargenomen verschillen tussen twee soorten recente proeven.
| Type proef | Context | Waargenomen resultaat |
|---|---|---|
| Proef METR 2025 | Ervaren ontwikkelaars, vertrouwde open source-projecten | Gemeten taakduur neemt toe ondanks een gevoel van versnelling |
| Veldproeven (3 bedrijven) | Gewone ontwikkeltaken, toegang tot Copilot | Meer voltooide taken in de waargenomen periode |
De METR-proef belicht een opvallende discrepantie: ontwikkelaars dachten dat AI hen had versneld, terwijl de werkelijke duur was toegenomen. Deze perceptiebias vormt een methodologisch probleem voor elk bedrijf dat AI uitsluitend zou evalueren op basis van het gevoel van zijn teams.
De veldproeven tonen daarentegen een meetbare winst in het aantal voltooide taken. Deze resultaten meten niet hetzelfde en zijn niet generaliseerbaar naar alle contexten. Het type project, de vertrouwdheid met de codebase en het ervaringsniveau van de ontwikkelaar veranderen de situatie radicaal.
Veiligheid van door AI gegenereerde code: een ondergewaardeerd aspect
De meeste productiviteitsanalyses richten zich op de snelheid van schrijven. De veiligheid van de geproduceerde code blijft een operationeel aspect dat weinig aandacht krijgt.
Veiligheidsverificatie en menselijke review kunnen een deel van de tijd die gewonnen is bij het initiële schrijven absorberen. Een ontwikkelaar die een functie in enkele seconden genereert, maar vervolgens twintig minuten besteedt aan het controleren of deze geen injectiefouten of verkeerde permissiebeheer bevat, heeft niet noodzakelijkerwijs netto tijd gewonnen.
Dit fenomeen creëert een verschuiving van de belasting in plaats van een vermindering. De schrijftijd neemt af, de reviewtijd neemt toe. Voor teams die werken aan gevoelige applicaties (gezondheid, financiën, infrastructuur) verdient deze verschuiving het om gekwantificeerd te worden voordat er globale winsten worden uitgeroepen.
- Automatische generatie controleert niet op naleving van project-specifieke veiligheidsnormen
- Door AI gegenereerde unit tests dekken vaak de nominale gevallen, maar verwaarlozen randgevallen en aanvalsscenario’s
- Menselijke code-review blijft de laatste verdedigingslinie, en de tijd daarvoor neemt toe wanneer het volume van de geproduceerde code toeneemt
Veiligheid apart van snelheid meten
Een codegeneratietool alleen evalueren op basis van het aantal geproduceerde regels of afgesloten taken is als de snelheid van een voertuig meten zonder de remmen te controleren. Veiligheidsmetrics (gevonden kwetsbaarheden na generatie, correctiepercentage voor implementatie) zouden in elk dashboard voor AI-adoptie moeten worden opgenomen.
Ontwikkelaarsgevoel versus gemeten gegevens: hoe AI te evalueren
De discrepantie die door de METR-proef is vastgesteld tussen perceptie en meting roept een praktische vraag op voor technische verantwoordelijken. Op welke indicatoren moet een beslissing over adoptie of verlenging van een licentie worden gebaseerd?
- Het volume voltooide taken per sprint geeft een signaal over de doorvoer, maar niet over de kwaliteit van de geleverde code
- Het rollbackpercentage na implementatie (DORA-metric) vangt de werkelijke stabiliteit beter dan het gevoel van het team
- De tijd voor code-review per pull request, gemeten voor en na de adoptie van AI, onthult of de winst in schrijven zich omzet in een overbelasting van verificatie
Een betrouwbare evaluatie combineert minimaal drie indicatoren: doorvoer, stabiliteit en reviewtijd. Alleen vertrouwen op gevoel of het volume geproduceerde code leidt tot foutieve conclusies.
Het DORA 2025-rapport toont aan dat de teams die daadwerkelijk vooruitgang boeken, degenen zijn die al beschikten over solide praktijken voor geautomatiseerde tests en systematische review. AI heeft deze praktijken niet vervangen, maar ze productiever gemaakt. Voor de anderen heeft de tool vooral de productie van technische schuld versneld.
De uitdaging voor de komende maanden is niet of AI sneller code genereert. Dat doet het. De open vraag betreft de werkelijke kosten van deze code eenmaal geïmplementeerd, onderhouden en op lange termijn beveiligd.
