Waarom AI-agents traditionele softwaretests breken in productie
Pilots met AI-agents slagen vaak onder toezicht, maar falen in productie. Drie klassieke aannames over softwaretests gaan bij agentic workloads direct onderuit.
👁 111 keer gelezen
Traditionele enterprise-systemen leunen op drie aannames: taken zijn snel klaar, een herhaalpoging kost niets en dezelfde invoer levert dezelfde uitvoer op. Agentic workloads doorbreken alle drie deze principes tegelijk. Dat verklaart meteen waarom pilots met AI-agents soepel verlopen onder menselijk toezicht, maar crashen zodra ze naar productie gaan.
Een grondige analyse van deze problematiek werd gepubliceerd op SiliconAngle door M. Touheed, die drie specifieke scheuren in de huidige softwarepraktijk blootlegt.
Drie eigenschappen die AI-agents niet bezitten
Ten eerste de uitvoeringstijd. Een agent-taak kan minuten duren in plaats van milliseconden - lang genoeg om timeouts te overschrijden die geen enkel onderdeel van de stack ooit eerder heeft gezien. Systemen die voorheen stabiel leken, beginnen plots op mysterieuze wijze te falen, totdat iemand de werkelijke doorlooptijd controleert.
Ten tweede de kosten van retries. In traditionele software is een herhaalpoging vrijwel gratis, waardoor engineeringteams ze royaal inzetten. Bij agents verbruikt elke herhaalpoging tegen een model met pay-per-use-tarieven rekenkracht, ongeacht of het resultaat bruikbaar is. Omdat facturen voor cloud-API’s en modellen asynchroon verlopen in maandelijkse cycli, stapelen de kosten van deze herhalingen zich geruisloos op en worden ze pas zichtbaar wanneer de factuur binnenkomt - weken later.
Ten derde de onmogelijkheid om fouten te reproduceren. Volgens Touheed is dit de grootste verandering. De standaardpraktijk na een foutief resultaat is het opnieuw uitvoeren en observeren van de bug. Bij agents werkt dat niet: zonder een gedetailleerd stappenplan van de beslissingen van de agent, de tool calls en API-aanroepen valt er niets te onderzoeken, en verzandt debugging in pure speculatie.
Google · Jouw bronnenHoger in Google - met één klikToevoegen aan voorkeursbronnen →Waarom een pilotproject deze problemen verbergt
Een evaluatie- of testomgeving maskeert al deze knelpunten, omdat een mens in een interactieve modus feitelijk fungeert als foutafhandeling. Iemand leest elk resultaat, ziet fouten en corrigeert die direct handmatig. De kosten blijven binnen de perken omdat pogingen met de hand worden gestart. Er is op dat moment nog geen noodzaak voor een auditspoor of een mechanisme om fouten te reproduceren.
Een geautomatiseerde agentic workflow werkt heel anders: die draait headless, zonder dat er iemand meekijkt in de console. Zoals de analyse aantoont, gedraagt een workflow die betrouwbaar werkte toen een medewerker met de AI chatte en elk antwoord controleerde, zich totaal anders wanneer een scheduler diezelfde workflow ’s nachts 400 keer zonder toezicht afvuurt. De fout zat er altijd al in, maar bleef onzichtbaar omdat de menselijke operator die telkens opving en corrigeerde.
De praktische conclusie voor engineering leads is helder: voordat je overstapt naar geautomatiseerde productie met agents, moet je elke handmatige taak van de operator inventariseren en bepalen welk geautomatiseerd mechanisme die verantwoordelijkheid overneemt. Touheed adviseert ook een concrete verschuiving in budgetgesprekken: vraag niet naar de kosten per API-call, maar naar de kosten per voltooide eenheid. Dat laatste cijfer filtert mislukte pogingen uit en schetst een realistisch beeld van de uitgaven.
Dit is typisch zo’n artikel dat je wilt doorsturen naar iedereen die net enthousiast verkondigt dat de pilot een groot succes was en plant om volgend kwartaal live te gaan.
More on this from HELDER
ai-tools·Google SynthID Detector openbaar: AI herkennen en de valkuilenGoogle stelt SynthID Detector open voor iedereen. Ontdek hoe je ermee controleert of een bestand door AI is gemaakt en wat een negatieve uitslag écht betekent.