Agentische AI heeft meer testers nodig, niet minder

Agentische AI verandert de manier waarop software wordt uitgebracht. Assistenten stellen pullrequests op, agents starten migraties en reviewbots beweren dat een wijziging veilig is voordat een mens zijn koffie op heeft. De sector ziet dit vaak als een ontwikkeling die leidt tot minder mensen in kwaliteitsfuncties. Dat is de omgekeerde redenering. Nu machines een groter deel van de codebase schrijven, is niet het genereren van code de schaarse vaardigheid. Dat is onafhankelijke verificatie.

Uit de ontwikkelaarsenquête van Stack Overflow uit 2025 bleek dat 84% van de respondenten AI-tools gebruikt of van plan is te gebruiken bij softwareontwikkeling, en dat 51% van de professionele ontwikkelaars ze dagelijks gebruikt. Het positieve sentiment daalde tot 60%, en meer ontwikkelaars wantrouwen de nauwkeurigheid van AI actief (46%) dan vertrouwen die (33%). De grootste frustratie, genoemd door 66%, was dat oplossingen bijna goed zijn, maar net niet helemaal. Uit het DORA-onderzoek van Google Cloud uit 2025 bleek dat 90% van de professionals in softwareontwikkeling AI gebruikte en dat meer dan 80% vond dat AI de productiviteit had verhoogd, terwijl slechts 24% aangaf veel of zeer veel vertrouwen in AI te hebben. Juist wanneer AI nuttig is, maar niet wordt vertrouwd, neemt het werk van testers toe in plaats van af.

Snelheid is geen bewijs

Ik werk als softwarekwaliteitsengineer en richt me op agentisch testen en CI-poorten voor code die door AI is geschreven. Binnen ons bedrijf hebben we een PR-beoordelaar en een generator van testgevallen uitgebracht. Beide zijn hulpmiddelen die concepten opleveren. Geen van beide beoordeelt zijn eigen werk. Die regel is belangrijk, omdat agents met zekerheid spreken. Zekerheid is geen bewijs van juistheid.

We hebben dat op de dure manier geleerd. Tijdens een pilot met een door AI gebouwde PR-beoordelaar passeerde een wijziging de CI-controle in minder dan 4 minuten. Twee dagen later toonde een downstreamdashboard onmogelijke temperaturen. Op één codepad dat de testsuite nooit uitvoerde, was de schaalfactor voor de omzetting van Celsius naar Fahrenheit omgekeerd. De pipeline stond op groen. Het product was fout. Een groene CI-controle die de moeilijke vraag nooit stelde, is alleen maar schijnvertoning.

Dat incident past in een breder patroon. In CodeRabbits rapport over AI- versus menselijke codegeneratie werden 470 open-sourcepullrequests op GitHub geanalyseerd (320 mede geschreven met AI, 150 uitsluitend door mensen geschreven). Wijzigingen die met AI waren geschreven, leidden in totaal tot ongeveer 1,7× zoveel problemen; problemen met logica en juistheid kwamen 75% vaker voor en het aantal beveiligingsproblemen lag tot 2,74× hoger. Veracode testte in het GenAI Code Security Report uit 2026 modellen voor uiteenlopende beveiligingstaken. Het gemiddelde slagingspercentage voor beveiligingstests was 56%, nauwelijks hoger dan de 55% in het vorige rapport, terwijl bij ongeveer 44% van de codegeneratietaken met AI een bekende kwetsbaarheid werd geïntroduceerd. De syntaxis is vrijwel een opgelost probleem. Veilig en correct gedrag is dat niet. Testers zijn degenen die weigeren die twee met elkaar te verwarren.

Gehallucineerde afhankelijkheden zijn een testprobleem

Bij het genereren van code worden ook pakketten verzonnen. In het onderzoek van USENIX Security 2025, We hebben een pakket voor u!, werden pakket-hallucinaties onderzocht aan de hand van 576.000 voorbeelden van 16 LLM’s die code genereren. Commerciële modellen hallucineerden gemiddeld minstens 5,2% van de tijd pakketten; bij opensourcemodellen lag het gemiddelde op 21,7%, met 205.474 unieke verzonnen pakketnamen. Zulke hardnekkige fantoompakketten vormen een uitgelezen doelwit voor slop-squatting: aanvallers registreren de verzonnen naam en wachten tot een ontwikkelaar of agent het pakket installeert.

Controles op de herkomst van afhankelijkheden horen op hetzelfde niveau te staan als functionele tests. Als een agent een NuGet- of npm-pakket verzint, moet de merge worden geblokkeerd voordat iemand kan discussiëren over de grondigheid van de unittests. Herkomst controleren is geen optionele hygiënemaatregel. Het is een kwaliteitspoort voor wijzigingen die door AI zijn geschreven.

Poorten die meegroeien met agents

Toen we met AI-ondersteunde automatisering in ongeveer twee weken tijd een organisatiebrede upgrade van .NET 8 naar .NET 10 uitvoerden, was ik verantwoordelijk voor de kwaliteitspoorten. De snelheidswinst was reëel. Dat gold ook voor de noodzaak van controles die de samenvatting van een agent niet zomaar geloven. Op gewijzigde code voer ik de volgende controles uit:

• Doelen voor de mutatiescore van 60% tot 70% voor gewijzigde logica, zodat de testsuite echte mutaties moet opsporen in plaats van alleen regels code af te dekken
• Property-based tests voor logica met een hoog risico, waarbij voorbeelden op zichzelf het gedrag niet volledig specificeren
• Controles op de herkomst van afhankelijkheden om slop-squatting en gehallucineerde pakketten tegen te gaan
• Signalen voor duplicatie en churn die aangeven dat agents code blijven kopiëren en aanpassen
• Onafhankelijke verificatie van beweringen van agents, zoals ‘migratie voltooid’, want zo’n bewering is een hypothese totdat er bewijs voor is

De mutatiescore is geen ijdelheidsmaatstaf. De score laat zien of je tests een opzettelijk geïntroduceerde fout opmerken. De dekking kan toenemen terwijl de testsuite het Celsius-codepad nog steeds mist. Property-based controles dwingen het systeemmodel af voor een hele reeks waarden, niet alleen voor één ideaal scenario. Controles op de herkomst sluiten de deur voor ongewenste pakketten. Churn en duplicatie brengen aan het licht dat agents hetzelfde idee op drie manieren herschrijven. Samen vormen deze controles een aanpak: ga ervan uit dat de agent het bij het verkeerde eind heeft totdat de testsuite het tegendeel bewijst. Die kalibratieregel houd ik aan tijdens reviews.

Dit alles vervangt API-tests, tests van authenticatie, rooktests of UI-automatisering niet. FlaUI en PowerShell brengen nog steeds problemen aan het licht die API’s missen. Ook voor het verpakken via NuGet, MSI en MSM blijven installatiecontroles en validatie van stille installaties nodig. Agentische workflows vergroten het volume. Ze maken deze disciplines niet overbodig.

Meer testers, ander werk

De angst is dat agents de tests schrijven en mensen overbodig worden. Agents kunnen testgevallen opstellen. Ze zouden hun eigen concepten niet mogen goedkeuren. Respondenten van Stack Overflow die van plan zijn AI in de toekomst voor tests te gebruiken, zien wantrouwen onder mensen nog altijd als een belangrijk punt: de belangrijkste reden om iemand anders om hulp te vragen, was dat ze de antwoorden van AI niet vertrouwden. Dat instinct is een kracht van het vak.

Het is hier belangrijk om mensen aan te nemen en kansen te bieden aan mensen met een niet-traditioneel carrièrepad. Na een loopbaan in HR-processen en data maakte ik de overstap naar kwaliteitsbewaking, behaalde ik in mei 2024 een masterdiploma in informatiesystemen aan UMBC en houd ik me nu dagelijks bezig met het praktisch toepasbaar maken van kwaliteitscontroles voor agentische AI. Agentische AI wacht niet tot iedereen hetzelfde opleidingstraject heeft gevolgd. Er zijn meer mensen nodig die bewijs kunnen opzetten, niet minder mensen die builds zonder meer goedkeuren zodra ze groen zijn.

De vraag over het product is eenvoudig. Als agents sneller worden uitgebracht dan je verificatie kan bijhouden, boek je geen productiviteitswinst. Je stelt een incident uit. Investeer in testers die elke bewering van een agent met argwaan bekijken, mutatietests en herkomstinformatie integreren in CI en hun onafhankelijke oordeel behouden wanneer het model het meest vloeiend en het minst betrouwbaar is. Agentische AI heeft meer testers nodig, niet minder.