Een AI-gebouwde app debuggen: een praktische methode

Om een met AI gebouwde app te debuggen, laat je eerst de bug opzettelijk opnieuw gebeuren. Verzamel daarna bewijs: de exacte stappen, de foutmelding, en wat de browserconsole en het netwerktabblad laten zien. Geef dat aan de AI als "ik deed X, verwachtte Y, kreeg Z". Als een fix het erger maakt, ga dan terug naar de laatste werkende versie in plaats van fixes op elkaar te stapelen. Je hoeft de code niet te lezen om dit goed te doen.

Deze gids behandelt de hele lus, inclusief een korte rondleiding door de ontwikkelaarstools van de browser, voor niet-ontwikkelaars.

De debuglus

Elke bugfix, of die nu door een persoon of een AI wordt gedaan, volgt dezelfde lus:

1. Reproduceren: laat de bug betrouwbaar gebeuren.
2. Observeren: verzamel de foutmelding en wat de app aan het doen was.
3. Beschrijven: geef de AI precieze stappen, het verwachte resultaat en het werkelijke resultaat.
4. Fixen: laat de AI één ding veranderen.
5. Verifiëren: herhaal de exacte stappen en bevestig dat het is opgelost, en dat er niets in de buurt kapot is gegaan.
6. Terugdraaien indien nodig: als het erger werd, maak het ongedaan en probeer opnieuw met betere informatie.

De meeste tijd die bij met AI gebouwde apps verloren gaat, komt door stap 1, 2 en 5 over te slaan: zeggen "het is kapot", een wijziging accepteren zonder die te testen, en daarna nog een fix vragen bovenop een kapotte.

Stap 1: Reproduceer de bug

Een bug die je op verzoek kunt uitlokken, is half opgelost. Probeer de kortst mogelijke reeks stappen te vinden die hem veroorzaakt.

Vraag jezelf af:

• Gebeurt het elke keer? Als het alleen soms gebeurt, wat is er dan anders als het gebeurt: een bepaald record, een trage verbinding, uitgelogd zijn?
• Gebeurt het voor elke gebruiker? Log in met een ander account. Veel bugs komen alleen voor nieuwe gebruikers zonder gegevens, of voor een gebruiker met een andere rol.
• Gebeurt het op elk apparaat? Probeer een telefoonbreed scherm en een andere browser.
• Begon het na een specifieke wijziging? Als het gisteren nog werkte, zijn de laatste paar wijzigingen de belangrijkste verdachten.

Schrijf de stappen op als korte genummerde lijst. Die plak je later in de prompt.

Stap 2: Lees de foutmelding

Foutmeldingen lijken angstaanjagend, maar je hebt maar een paar onderdelen nodig.

Je hoeft het niet te begrijpen; je moet het exact kopiëren. "Cannot read properties of undefined (reading 'name')" vertelt de AI dat de code gegevens verwachtte (waarschijnlijk een boeking of een gebruiker) die er niet waren. Een parafrase als "een undefined-fout" verliest die informatie.

Een paar veelvoorkomende, grofweg vertaald:

• undefined- / null-fouten: de code verwachtte gegevens die niet kwamen. Vaak een laadstatus of een lege lijst die de code niet afhandelde.
• 404 Not Found: de pagina of het API-adres bestaat niet. Vaak een typfout in een route of een link naar een pagina die is hernoemd.
• 401 Unauthorized / 403 Forbidden: het verzoek was niet ingelogd, of de gebruiker mag dat niet doen.
• 500 Internal Server Error: de servercode is gecrasht. De echte reden staat in de serverlogs, niet in de browser.
• CORS-fouten: de browser heeft een verzoek naar een ander domein geblokkeerd. Meestal een configuratieprobleem aan de serverkant.

Stap 3: Gebruik de ontwikkelaarstools van de browser

Elke desktopbrowser heeft ingebouwde ontwikkelaarstools ("devtools"). Die laten zien wat de pagina achter de schermen doet. In Chrome, Edge en Firefox klik je ergens op de pagina met de rechtermuisknop en kies je Inspecteren, of druk je op F12 (Cmd+Option+I op een Mac). In Safari zet je eerst het menu Ontwikkel aan in de instellingen van Safari.

Je hebt maar drie tabbladen nodig.

Console

Het tabblad Console toont fouten en berichten uit de code van de pagina. Fouten staan in rood. Als een knop niets doet wanneer je erop klikt, toont de console heel vaak een rode fout op het moment van klikken. Kopieer de volledige tekst van de fout (klik er met de rechtermuisknop op voor een kopieeroptie in de meeste browsers).

Netwerk

Het tabblad Netwerk toont elk verzoek dat de pagina doet: gegevens laden, een formulier opslaan, inloggen. Open het en herhaal de stappen die de bug veroorzaken.

• Kijk naar rijen in rood of met een status van 400 of hoger.
• Klik op een mislukte rij om de Response te zien. Een serverfout bevat daar vaak een bericht dat nuttiger is dan alles op het scherm.
• Let op de URL en statuscode van het verzoek. "De POST naar /api/bookings gaf een 500" is een zeer nuttige zin om aan de AI te geven.

Vink Preserve log aan als de bug een paginaherlaad of redirect betreft, zodat de verzoeken niet verdwijnen.

Elementen

Het tabblad Elementen (of Inspector) toont de structuur en stijlen van de pagina. Het is het nuttigst voor lay-outbugs: beweeg over een element om de grootte en afstanden gemarkeerd te zien. Je hoeft hier niets te bewerken; het is genoeg om te zeggen "de voettekst is op mobiel 2.000 pixels breed en duwt de pagina opzij".

Stap 4: Controleer de serverlogs

Sommige bugs gebeuren op de server, waar de browser ze niet kan zien. Een 500-fout in het netwerktabblad is het klassieke teken. Serverlogs, de tekstuitvoer van je backend terwijl die draait, bevatten meestal de echte fout met een stack trace (een lijst van de functies die liepen toen het misging).

Waar je die vindt, hangt af van je tool. In de meeste AI-appbouwers kun je een terminal- of logweergave voor het project openen, of je vraagt de AI simpelweg: "Controleer de serverlogs op fouten van het laatste verzoek en vertel me wat er mislukte."

Stap 5: Beschrijf de bug aan de AI

Zet wat je hebt verzameld in deze vorm:

Op de pagina Boekingen, ingelogd als lid: ik klikte op Annuleren bij de les van morgen om 9:00. Verwacht: de boeking verdwijnt en de les heeft één vrije plek erbij. Werkelijk: er verandert niets op het scherm. De console toont TypeError: Cannot read properties of undefined (reading 'id') bij BookingCard.tsx:31, en het netwerktabblad toont dat DELETE /api/bookings/123 een 500 gaf. Zoek de oorzaak, los hem op, en controleer of annuleren werkt voor een lid met één boeking en met meerdere.

Waarom elk onderdeel belangrijk is:

• Waar en als wie beperkt het tot één scherm en één rol.
• Exacte stappen laten de AI de bug reproduceren.
• Verwacht vs werkelijk definieert wat "opgelost" betekent.
• De fouttekst en het mislukte verzoek wijzen rechtstreeks naar de oorzaak.
• "Controleer dat..." vraagt de AI om te verifiëren, niet alleen te bewerken.

Als de AI twee keer een fix heeft geprobeerd en gefaald, vraag hem dan uit te leggen voordat hij iets verandert:

Wijzig nog geen code. Wat denk je dat de oorzaak is, en welk bewijs ondersteunt dat?

Een verkeerde theorie is makkelijk te herkennen als ze op papier staat, en veel goedkoper te corrigeren dan een verkeerde fix.

Stap 6: Verifieer en controleer de omgeving

Wanneer de AI zegt dat het is opgelost, herhaal je de exacte stappen uit stap 1. Controleer daarna de dingen eromheen:

• Dezelfde actie voor een andere gebruikersrol
• Dezelfde actie zonder gegevens, en met veel gegevens
• Pagina's die componenten delen met de pagina die je hebt gefixt
• Een telefoonbreed scherm, als de fix de lay-out raakte

AI-wijzigingen repareren soms het ene pad en breken stilletjes een ander. Een controle van twee minuten nu bespaart een verwarrend uur later.

Stap 7: Draai terug in plaats van stapelen

Als een fix het erger maakte, of je drie rondes zonder vooruitgang hebt gehad, ga dan terug. Terugdraaien naar de laatste werkende versie en het probleem opnieuw beschrijven met betere bewijzen werkt bijna altijd beter dan een vierde fix bovenop drie foute. Elke mislukte poging laat code achter, en die code verwart de volgende poging.

Goede gewoonten die terugdraaien makkelijk maken:

• Test na elke wijziging, zodat je weet welke wijziging iets heeft gebroken.
• Houd wijzigingen klein: één functie of fix per bericht.
• Noteer de laatste goede versie voordat je iets riskants begint.
• Als de code in Git staat, commit je werkende versies zodat je ernaar terug kunt.

Veelvoorkomende bugpatronen in met AI gebouwde apps

Wanneer het probleem geen bug is

Sommige "bugs" zijn de AI die precies bouwt wat hem is verteld, terwijl de beschrijving dubbelzinnig was. Als de fix die je vraagt eigenlijk een wijziging in gedrag is, zeg dat dan duidelijk: "Verander het zo dat...". Als je niet zeker weet wat het juiste gedrag is, bepaal dat eerst. Onze gids over prompts schrijven voor AI-appbouwers laat zien hoe je regels duidelijk specificeert. En als je een app voor echte gebruikers voorbereidt, behandelt een AI-prototype naar productie brengen de controles die de moeite waard zijn voor de lancering.

Debuggen in Mythex

Mythex heeft hulpmiddelen voor elke stap van de lus:

• Preview om de bug te reproduceren, inclusief een telefoonformaat.
• /test laat de agent je live preview doorklikken als een gebruiker en kapotte flows melden.
• /fix richt de agent specifiek op kapotte onderdelen.
• Planmodus laat de agent onderzoeken en uitleggen voordat hij iets bewerkt.
• Code → terminal toont de serverlogs van je app.
• Terug naar dit punt bij elk antwoord zet het project terug naar dat checkpoint.

Als een publicatie mislukt, biedt het publicatievenster meestal Fix met AI aan, die de buildoutput of de logs van de app leest. Zie Debug je app en Publicatie-problemen oplossen in de docs.

Veelgestelde vragen