AI-app foutmelding debuggen als je app crasht zonder oorzaak

Een app waar ik aan werk gaf laatst alleen Unhandled promise rejection terug. Geen bestand, geen regel, nergens een hint. Na een halfuur met een AI-assistent de call stack van boven naar beneden te lopen, bleek een verkeerde import de boosdoener. Zo’n vage melding is precies waar AI-app foutmelding debuggen het verschil maakt.

De foutmelding zelf is zelden het probleem. Die vertelt je alleen dat er iets misging, niet waarom. Zeker bij apps die je deels met AI hebt gebouwd, kunnen lagen code van jou, de AI en een library door elkaar lopen. Dan helpt een strak debugproces beter dan eindeloos opnieuw bouwen.

AI-app foutmelding debuggen begint met een repro

Een fout die je niet zelf kunt oproepen, kun je niet oplossen. Schrijf de kleinst mogelijke actie op waarmee de fout verschijnt. Bijvoorbeeld open de app, klik op ‘Exporteren’, kies CSV, wacht twee seconden. Zonder die volgorde blijf je gokken.

Vaak is een formulier dat geen data verzendt de eerste plek waar een vage fout opduikt. Hetzelfde principe geldt, maak een vaste testcase, liefst in een losse omgeving.

Leg elke stap vast voordat je iets verandert

Neem de foutmelding letterlijk over, inclusief statuscode, timestamp en eventuele request-id. Plak die niet direct in ChatGPT en vraag ‘wat is dit’. De eerste prompt moet context bevatten, welk framework je gebruikt, welke actie de gebruiker deed en wat je al hebt uitgesloten. Daarna kun je AI pas gericht laten meedenken.

Zoek eerst in de laag die jij niet hebt aangeraakt

Bij AI-gegenereerde code is de verleiding groot om de prompt opnieuw te doen en te hopen dat de bug weggaat. Beter is het omgekeerde. Check eerst wat er tussen jouw code en de fout zit, environment variables, CORS-instellingen, importpaden, API-sleutels en versies van packages.

Een handige check is de kale versie van de functie. Haal de AI-functie even weg en roep alleen de onderliggende library aan. Werkt dat? Dan zit de fout in de AI-laag. Werkt dat niet? Dan is het een configuratie- of dataprobleem.

Maak een klein script dat alleen dat ene stukje test

In plaats van de hele app te starten, schrijf een los script van tien regels dat alleen de verdachte functie aanroept. Dit geeft sneller uitsluitsel dan telkens de volledige preview draaien. Bij een Next.js-app is dat bijvoorbeeld een los node-script dat dezelfde API-route aanroept. Als je daar dezelfde fout krijgt, heb je een behapbaar probleem.

Gebruik AI als tweede paar ogen, niet als orakel

Een van de nuttigste prompts die ik ken is niet ‘los dit op’, maar ‘lees deze stacktrace en vertel me welke mogelijke oorzaken je uitsluit en waarom’. Vraag de AI daarna om per mogelijke oorzaak één test te geven. Zo houd je zelf de regie over de volgorde.

Zet niet meerdere AI-oplossingen tegelijk in je code. Een bug die op die manier ontstaat, is daarna lastiger terug te brengen naar één verandering. Los het alleen met AI op als je de voorgestelde regel kunt uitleggen aan iemand naast je.

Kijk naar de vorige AI-sessie

Als je een AI-functie hebt gebouwd die steeds dezelfde bug terugbrengt, bewaar dan de chat of prompts. Vaak zit er een aanname in de eerste prompt die pas later breekt, bijvoorbeeld dat een veld altijd uit een bepaald type bestaat. Door de oude context erbij te pakken, vind je de mismatch sneller.

Check de input en output op de grens

Vage fouten ontstaan vaak bij lege arrays, ontbrekende velden of een waarde die undefined is terwijl de code een object verwacht. Laat je app expres verkeerde data verwerken. Bijvoorbeeld een gebruikersobject zonder name, een export met nul rijen, of een upload met een leeg bestand. De foutmelding wordt daardoor zelden duidelijker, maar het moment van crashen vertelt je welk veld de code als vanzelfsprekend ziet.

Voeg daarna tijdelijk wat console.log regels toe vlak voor de plek waar je vermoedt dat het misgaat. Doe dat in een aparte tak, niet in je hoofdversie. Je wilt de echte waarde zien, niet de waarde die je hoopt te zien.

Veelgestelde vragen

Waarom zegt de foutmelding alleen ‘Request failed’?

Veel servers en API’s geven bewust geen details terug, bijvoorbeeld om geen interne paden of query-informatie te lekken. Check de serverlogs of voeg tijdelijk een uitgebreide foutafhandeling toe in je eigen code.

Wat is een goede eerste prompt om een vage fout op te lossen?

Plak de foutmelding samen met drie stukjes context, de actie van de gebruiker, het framework en wat je al hebt uitgesloten. Vraag de AI om eerst drie mogelijke oorzaken te noemen, met per oorzaak een korte test.

Kan ik de AI gewoon vragen om de hele functie opnieuw te schrijven?

Dat kan, maar daarmee vervang je een onbegrepen fout door een nieuwe onbegrepen implementatie. Je verliest de kans om te zien wat er nu echt kapotging. Beter is een losse test schrijven die de fout vangt, voordat je code verandert.

Hoe vind ik een fout die alleen bij één gebruiker voorkomt?

Vraag die gebruiker om de exacte stappen en het tijdstip. Zoek in de logs rond dat moment. Zet daarna een kleine error-tracking in, zoals Sentry, zodat de volgende vage fout meer context oplevert dan een scherm met alleen ‘oeps’.

Wat als de fout alleen in productie verschijnt en lokaal niet?

Vergelijk de environment variables en dependencyversies. In veel gevallen wijst een productie-only fout naar een ontbrekende sleutel, een verkeerde URL of een build die stilletjes een oude cache gebruikt.

Het lastige aan een vage foutmelding is dat die je het gevoel geeft dat je iets over het hoofd ziet. Meestal is het saaier dan je denkt, een verkeerde import, een missende variabele, een veld dat net anders heet. Door klein te reproduceren, de juiste laag te isoleren en AI als sparringpartner te gebruiken, wordt debuggen weer een gewone klus.