Het grootste nadeel van AI: debuggen zonder debugger

Je kent het gevoel. Er loopt iets fout in een proces, je opent de logs, je zet een breakpoint, en binnen de vijf minuten weet je exact welke regel code de verkeerde beslissing nam. Frustrerend soms, maar voorspelbaar. Software gedraagt zich zoals je het geschreven hebt, en als dat niet klopt, kan je het terugvolgen tot de bron.

Nu doe je diezelfde oefening met een proces waar een AI-agent een stap in uitvoert. De agent kreeg een prompt, maakte een analyse, en koos een actie. Die actie was fout. Waar ga je nu debuggen? Er is geen regel code die "fout" is. Er is geen stacktrace die naar het probleem wijst. Er is een taalmodel dat, op basis van een prompt en wat context, iets anders besliste dan wat jij verwachtte. En morgen, met exact dezelfde input, kan het resultaat er weer anders uitzien.

Dat is voor mij het grootste nadeel van AI in een productieomgeving. Niet de kost, niet de leercurve, maar het feit dat je een deel van je proces niet meer kan debuggen op de manier waarop je dat al twintig jaar gewoon bent.

Waarom klassiek debuggen hier stopt

Een normaal programma is deterministisch. Zelfde input, zelfde output, altijd. Daarom werkt debuggen: je kan het probleem isoleren, herhalen, en stap voor stap volgen tot je de oorzaak vindt.

Een taalmodel is dat niet. Het genereert een antwoord op basis van waarschijnlijkheden, en zelfs met dezelfde prompt kan de output lichtjes verschillen. Voeg daar een agent bovenop die zelf beslist welke tool hij aanroept, in welke volgorde, en met welke parameters, en je hebt een stap in je proces die zich gedraagt als een black box. Ze werkt in 95% van de gevallen perfect, en in de overige 5% doet ze iets wat je nooit had voorzien.

Dat is geen reden om AI-agents te mijden. Het is wel een reden om je manier van werken aan te passen. Je kan een taalmodel niet fixen zoals je een bug fixt. Je kan het gedrag alleen sturen: door betere prompts, door structuur op te leggen, en door delen van het proces bewust deterministisch te houden.

Vijf manieren om toch grip te houden

1. Observability: log elke stap

Tools zoals Langfuse of LangSmith loggen elke stap van een agent: de volledige prompt, het antwoord van het model, en elke tool call die eruit volgt. Dat is de dichtste benadering van een debugger die je momenteel hebt voor AI-agents. Zonder zo'n log sta je achteraf te gissen naar wat er precies gebeurd is. Met een log zie je exact welke prompt binnenkwam, wat het model besliste, en waar het fout liep.

2. Structured outputs: dwing het model in een vast formaat

Laat een agent niet vrije tekst teruggeven, maar een vast JSON-formaat met specifieke velden. Zo wordt het gedrag van het model veel voorspelbaarder, en kan je de output automatisch valideren voor je ze verder in je proces laat lopen. Een agent die vrij mag antwoorden is moeilijk te controleren. Een agent die verplicht is om binnen een schema te blijven, geeft je meteen een eerste vorm van validatie.

3. Kleinere agents met één duidelijke taak

Eén agent die alles beslist, van analyse tot actie tot opvolging, is bijna onmogelijk grondig te testen. Splits die verantwoordelijkheid op in kleinere agents die elk één ding doen. Hoe kleiner de scope van een agent, hoe kleiner de ruimte waarin het fout kan gaan, en hoe makkelijker het is om per stap te testen wat je verwacht.

4. Human-in-the-loop bij kritieke stappen

Zolang je een agent niet volledig vertrouwt, bouw je bij belangrijke beslissingen een menselijke goedkeuring in. Dat is geen zwaktebod, dat is gewoon goed engineeren. Een factuur die automatisch betaald wordt of een mail die automatisch verstuurd wordt, verdient een extra controle zolang je nog niet zeker weet hoe stabiel het gedrag van de agent is.

5. Evaluatie-datasets: test elke wijziging

Bouw een vaste set testcases met verwachte outputs op, en test daar elke wijziging aan een prompt tegen voor je ze deployt. Zonder zo'n set pas je een prompt aan, het lijkt beter te werken op je ene testvraag, en drie weken later merk je dat een ander scenario stukgevallen is. Een evaluatie-dataset geeft je hetzelfde soort zekerheid als een unit test: een wijziging mag pas door als de bestaande cases nog steeds correct beantwoord worden.

Deterministisch waar het kan, AI waar het moet

In de praktijk werkt het best als je niet je volledige proces aan een agent overlaat. Bepaal per stap of het écht om een beslissing gaat die AI moet nemen, of dat het gewoon vaste logica is die je perfect in code kan gieten. Elke stap die je deterministisch kan houden, is een stap die je wel nog op de klassieke manier kan debuggen. Wat overblijft voor de agent, houd je zo klein en goed getest mogelijk.

Dat is ook meteen waarom finetunen van je prompting geen eenmalige klus is. Een prompt die vandaag goed werkt, kan na een kleine wijziging elders in het proces plots anders reageren. Zonder logging, structured outputs en een evaluatie-dataset merk je dat pas als een klant of collega het probleem meldt, en dan sta je alsnog te gissen naar de oorzaak.

Conclusie

Het grootste nadeel van AI in een proces is niet dat het duur is of complex om op te zetten. Het is dat je, wanneer het misloopt, geen klassieke debugger hebt om de fout tot bij de bron te volgen. Die zekerheid moet je zelf opbouwen: door elke stap te loggen, door outputs in een vast formaat te dwingen, door agents klein en gefocust te houden, door mensen te laten meekijken bij kritieke beslissingen, en door elke wijziging te testen tegen een vaste set voorbeelden.

Geen enkele van deze technieken maakt een AI-agent volledig voorspelbaar. Samen zorgen ze er wel voor dat je, als er iets fout gaat, niet met lege handen staat.