AI-code debuggen: wat controleer je als code niet meer werkt?

Een functie die wekenlang goed werkte, stopt plotseling zonder duidelijke reden — niemand heeft dat deel van de app aangeraakt. Dit is een van de verwarrendste momenten bij het beheren van een door AI gebouwd product. De instinctieve vraag ‘wat heb ik kapotgemaakt?’ past namelijk niet bij een situatie waarin bewust niets is veranderd. Voor het debuggen van AI-code in deze situatie bestaat een specifieke volgorde van controles. Die in volgorde doorlopen is sneller dan gokken.

Begin met wat er werkelijk is veranderd

Stel voordat je de code zelf aanraakt vast wat er daadwerkelijk anders is sinds de functie voor het laatst werkte. Veelvoorkomende antwoorden zijn: een dependency is bijgewerkt, zelfs automatisch; een grens in de hoeveelheid gegevens is overschreden; een externe API die door de code wordt aangeroepen heeft zijn gedrag veranderd; of een verwante functie is aangepast op een manier die onverwacht dezelfde gegevens raakt. Door AI gegenereerde code is vooral gevoelig voor dat laatste, omdat functies die via afzonderlijke prompts zijn gebouwd hun gedeelde dependencies niet altijd expliciet maken. Een wijziging op de ene plaats kan dan stilzwijgend iets anders beïnvloeden.

Controle 1: is een dependency onder de code veranderd?

Als het project automatische of ruim vastgezette dependencyversies gebruikt, kan een package-update gedrag veranderen zonder dat iemand één regel applicatiecode aanraakt. Vergelijk de geschiedenis van het dependencylockbestand met het moment waarop de functie uitviel. Dit is een snelle controle waarmee je een hele categorie gevallen van ‘er veranderde niets, maar het ging stuk’ kunt uitsluiten.

Controle 2: hebben de gegevens een grens overschreden?

Code die ervan uitging dat een lijst kort, een getal klein of een tekenreeks onder een bepaalde lengte zou blijven, kan lange tijd goed werken en precies uitvallen wanneer het werkelijke gebruik een grens overschrijdt die niemand heeft getest. Dit komt vaak voor in door AI gegenereerde code, omdat aannames over schaal zelden expliciet in de oorspronkelijke prompt staan. De AI heeft dan geen aanleiding om zich ertegen te beschermen.

Controle 3: heeft een externe dienst zijn gedrag veranderd?

Als de functie afhankelijk is van een externe API, controleer dan de statuspagina of changelog van die dienst. Door AI gegenereerde integratiecode steunt soms op ongedocumenteerd of standaardgedrag van een externe dienst, in plaats van op een expliciet gegarandeerd contract. Het kan volkomen redelijk zijn dat de dienst dit gedrag aan zijn kant wijzigt, maar voor jou verschijnt het als een onverklaarbare storing.

Controle 4: raakte een wijziging aan een verwante functie gedeelde logica?

Als onlangs een andere functie is aangepast, controleer dan of die een functie, datamodel of validatieregel deelt met de defecte functie. Dit is het risico op inconsistentie in een codebase die met veel afzonderlijke AI-prompts is gebouwd: een wijziging voor de ene functie kan een andere functie beïnvloeden die ongemerkt van dezelfde onderliggende logica afhankelijk was.

Controle 5: is de fout echt nieuw of pas net zichtbaar?

Soms was de bug er altijd al: een stille fout zonder zichtbare melding. Deze wordt pas merkbaar bij voldoende volume of een specifieke combinatie van invoerwaarden. Controleer de logs, als die bestaan, op de werkelijke fout en niet alleen op het symptoom dat een gebruiker meldde, voordat je aanneemt dat de bug nieuw is.

Controle 6: is een configuratie- of omgevingswaarde veranderd?

Omgevingsvariabelen, feature flags en configuratiewaarden worden gemakkelijk over het hoofd gezien omdat ze buiten de code zelf staan. Een waarde die tijdens tests handmatig werd ingesteld en nooit is opgeslagen, of een flag die na een nieuwe implementatie stilzwijgend naar de standaardwaarde terugkeerde, kan een functie zonder enige codewijziging laten uitvallen. Deze controle is snel en wordt vaak als laatste uitgevoerd, terwijl ze meestal vroeg aan bod hoort te komen.

Documenteer de oorzaak, niet alleen de oplossing

Zodra je de werkelijke oorzaak hebt gevonden, leg je kort vast wat die was en waarom die ontstond, niet alleen welke code is gewijzigd om het probleem op te lossen. Dit is vooral belangrijk bij het debuggen van AI-code, omdat dezelfde categorie oorzaken — een bijgewerkte dependency, een gegevensgrens of een wijziging in gedeelde logica — vaak terugkeert in verschillende functies van dezelfde codebase. Een korte notitie dat ‘dit type probleem ons eerder heeft geraakt’ is bij het volgende incident vaak nuttiger dan de specifieke regel code die deze keer is gewijzigd.

Een storingsvolgorde voor het debuggen van AI-code

Volgorde	Wat je controleert	Waarom je dit nu controleert
1	Wat recent is veranderd (implementaties, prompts, dependencies)	De snelste manier om het zoekgebied te verkleinen
2	Dependencyversies en de geschiedenis van het lockbestand	Kunnen gedrag breken zonder wijzigingen in de applicatiecode
3	Grenzen voor gegevensvolume of waarden	Een veelvoorkomende blinde vlek in door AI gegenereerde logica
4	Veranderingen in het gedrag van externe diensten	Buiten je controle, maar de storing komt wel bij jou terecht
5	Gedeelde logica die door een andere functie is geraakt	Een symptoom van inconsistentie tussen functies
6	Configuratie- en omgevingswaarden	Gemakkelijk te missen en er is geen codewijziging nodig om iets te breken
7	Of de fout nieuw of pas net zichtbaar is	Onderscheidt een regressie van een langdurige stille bug

Wanneer je niet langer alleen moet debuggen

Heb je deze lijst doorlopen en houdt de oplossing niet stand — hetzelfde symptoom keert terug nadat het ‘gerepareerd’ is — dan wijst dat meestal op een onderliggend patroon dat op meerdere plaatsen in de codebase voorkomt, niet op een verkeerde oplossing. Waarom door AI gegenereerde code werkt en toch steeds kapotgaat gaat dieper in op dit patroon van terugkerende storingen. Raakt het probleem authenticatie, betalingen of gebruikersgegevens, laat dan een onafhankelijke beoordeling uitvoeren in plaats van zelf te blijven bijwerken. Lees waarom voor het debuggen van door AI gegenereerde code nog steeds software-engineeringexpertise nodig is om te begrijpen waarom die stap ook belangrijk is als je kunt programmeren.

Voor de uitgebreidere lijst met bugcategorieën waarop deze storingsvolgorde is gebaseerd, behandelt bugs in AI-code: waarom door AI gegenereerde software in een demo kan werken maar in productie faalt elk type afzonderlijk.

De kern

Wanneer door AI gegenereerde code die eerder werkte plotseling uitvalt, weersta dan de neiging om meteen code te herschrijven voordat je hebt vastgesteld wat er werkelijk is veranderd. Door dependencywijzigingen, gegevensgrenzen, externe diensten en gedeelde logica in volgorde te controleren, vind je de werkelijke oorzaak sneller dan door te gokken. Blijft hetzelfde symptoom terugkeren, dan is dat het signaal om een tweede paar ogen in te schakelen in plaats van voor de vijfde keer dezelfde oplossing te proberen.

Veelgestelde vragen

Wat controleer ik eerst als een door AI gemaakte functie plotseling niet meer werkt?

Begin met wat er daadwerkelijk is veranderd: een recente prompt, een bijgewerkte dependency of een nieuwe gegevenssituatie. Het debuggen van AI-code gaat sneller als je eerst bepaalt wat er anders is sinds de laatste keer dat het werkte, voordat je de hele codebase doorzoekt.

Is het mijn schuld als door AI gegenereerde code na weken goed werken uitvalt?

Niet noodzakelijk. Vaak doet zich gewoon een nieuwe situatie voor, zoals een grens in de hoeveelheid gegevens, een ongebruikelijke invoerwaarde of een dependency die onder de code is veranderd. Behandel het als een debuggingvraagstuk, niet als een schuldvraag.

Moet ik de AI vragen zijn eigen defecte code te repareren?

Dat is een bruikbare eerste stap, maar een AI die zijn eigen output debugt, heeft dezelfde blinde vlekken die het oorspronkelijke hiaat veroorzaakten. Als de eerste oplossing niet standhoudt, laat dan een onafhankelijke beoordeling uitvoeren in plaats van dezelfde prompt met kleine variaties te herhalen.

Hoe weet ik of een bug op zichzelf staat of een symptoom is van een breder patroon?

Zoek in de rest van de codebase naar hetzelfde soort logica: hetzelfde gegevenstype, dezelfde validatiestap of dezelfde externe aanroep. Vind je hetzelfde patroon elders, beschouw dan alle gevallen als verdacht en niet alleen het geval dat zichtbaar werd.

Wanneer moet ik stoppen met zelf debuggen en een professionele beoordeling inschakelen?

Raakt de bug authenticatie, betalingen of gebruikersgegevens, of heb je hetzelfde symptoom meermaals gerepareerd zonder blijvend resultaat, schakel dan een onafhankelijke reviewer met professionele ervaring in in plaats van alleen te blijven bijwerken.