De 'ziet er goed uit'-bug: hoe je stille fouten in je met AI gebouwde app herkent

Je AI-appbouwer produceerde een contactformulier. Je typte je naam, klikte op verzenden, zag het vriendelijke succesbericht, en ging verder. Een week later noem je de pagina tegen een vriend, die vraagt of iemand hem heeft ingevuld. Je gaat kijken. Drie inzendingen staan in een soort wachtstand. Geen ervan heeft ooit je inbox bereikt.

Dit is de meest voorkomende faalwijze voor een met AI gebouwde app, en het is niet degene waar de meeste mensen zich zorgen over maken. Bugs die een rode foutmelding tonen zijn makkelijk te vinden — je AI-bouwer repareert ze in twee minuten. De gevaarlijke bugs zijn die waarbij het scherm er goed uitziet, de gebruiker denkt dat ze klaar zijn, en jij er pas een maand later achter komt.

Deze post is een checklist om die te vangen. Niet “hoe je test als een QA-engineer” — gewoon de vijf plekken waar echte gebruikers worden gebrand door een met AI gebouwde app die eruitziet alsof hij werkt.

1. Dien iets in en check of het echt ergens heen ging

Wanneer je AI-bouwer een formulier maakt, stel één vraag: waar gaat de data heen? Niet abstract — letterlijk, waar kun je het bekijken nadat je hebt ingediend?

Een verrassend groot aantal van deze formulieren post naar een handler die “Bedankt!” teruggeeft zonder ooit de e-mail te versturen, op te slaan in een database, of iemand te informeren. Het formulier is een beleefde façade. Dus:

• Dien een testinvoer in met een nep- maar duidelijke naam als “ZZZ TEST”.
• Open het dashboard, de database, de inbox, de spreadsheet — waar inzendingen ook horen te landen.
• Vind je “ZZZ TEST”-invoer daar, met de juiste tijdstempel.

Als je hem niet binnen een minuut kunt vinden, is je formulier kapot, ook al feliciteerde het je met het indienen. Ik heb een “neem contact op”-formulier op een betaalde landingspagina drie weken lang nul leads zien verzamelen omdat de e-mailstap nooit was bedraad. De pagina zag er perfect uit.

2. Probeer het pad dat je nooit zou nemen

Je weet wat je app doet omdat je hem zag worden gebouwd. Je klikt elke keer op de knoppen in dezelfde volgorde. Echte gebruikers doen dat niet.

Kies het pad dat het vreemdst aanvoelt:

• Klik twee keer snel achter elkaar op verzenden.
• Ververs de pagina midden in het doen van iets.
• Open hem in een privévenster zonder login.
• Typ een naam met een apostrof (O’Brien is de klassieke vernietiger).
• Typ een getal in een veld dat erom vraagt, maar maak het negatief of nul.

Als er iets zichtbaar breekt, is dat een echte bug — maar het is in elk geval een luide. De “ziet er goed uit”-versie is wanneer de tweede klik een dubbel record maakte en er geen manier is om het van het scherm af te zien. Ga de database checken en zoek naar twee “ZZZ TEST”-rijen met tijdstempels twee seconden uit elkaar. Als je ze vindt, heeft het formulier een dubbelbeveiliging nodig.

3. Wacht een dag, kom dan terug

Veel door AI gegenereerde code gebruikt tijdelijk geheugen dat reset wanneer de app opnieuw deployt of opstart. De app houdt je data vast in iets dat een ontwikkelaar “in-memory state” zou noemen — prima voor een demo, vreselijk voor alles wat echt is.

De test is bruut en makkelijk: voer wat data in, sluit het tabblad, wacht vierentwintig uur, kom terug. Als je data weg is of door elkaar gehusseld, is de opslag niet echt. Je AI-bouwer moet waarschijnlijk in gewone taal worden verteld: “deze data moet een serverherstart overleven.” De meeste bouwers schakelen over naar een database wanneer je het vraagt; sommige niet tenzij je het vraagt.

Je kunt een snellere versie van deze test uitvoeren door je bouwer in de chat te vragen: “waar wordt de data voor dit formulier opgeslagen, en overleeft het een herdeploy?” Als het antwoord “in geheugen”, “sessie” of “voor deze run” noemt, heb je de bug gevonden voordat een gebruiker dat deed.

4. Laat het zien aan iemand die jij niet bent

Je weet wat je app betekent. Je ontwierp hem. Je noemde de knoppen. De labels zijn vanzelfsprekend voor jou omdat je ze schreef.

Laat hem aan een vriend zien zonder iets uit te leggen. Zeg: “Probeer X te doen.” Kijk naar ze. Help niet. Drie dingen zullen gebeuren:

• Ze klikken ergens waar je het niet verwachtte, en de app doet iets verrassends.
• Ze lopen vast op een label dat vanzelfsprekend leek toen je het schreef.
• Ze doen het ding dat je wilde dat ze deden, maar in de helft van de stappen die je je voorstelde, en slaan een scherm helemaal over — soms een scherm waar de app op rekende dat ze het zouden invullen.

Elk daarvan is een echte bug. Geen ervan geeft een fout. De vriend zal zeggen “Oh, schattig”, en de laptop teruggeven. Jij zult, door naar hun gezicht te kijken, weten dat ze dertig seconden verloren waren op een plek waarvan je dacht dat die geen naden had.

5. Lees de e-mail die hij stuurt, op een telefoon

Als je app e-mails stuurt — bevestigingen, wachtwoordresets, facturen — open er een op je telefoon, en een in een andere e-mailclient dan je gewoonlijk gebruikt. Met AI gebouwde apps neigen ernaar e-mails te genereren die er prachtig uitzien in Gmail op een desktop en eruitzien als ruis in Outlook op Android.

Dezelfde logica geldt voor pdf-bonnetjes, downloadbare exports, en “deel deze link”-knoppen. Het ding dat buiten je app gaat, de echte wereld in, is het meest ondergeteste deel van een AI-build. Het is ook het deel dat je gebruikers het meest zien. Een oprichter die ik ken lanceerde een prachtige checkout-flow waarvan het bon-pdf, op iPhone, een enkel zwart vierkant was. Niemand klaagde — ze stopten gewoon met kopen.

De ongemakkelijke waarheid over “het werkt”

Wanneer je met een AI-appbouwer bouwt, betekent “het werkt” “het draaide op mijn machine, in mijn browser, met mijn exacte kliks, op de dag dat ik het bouwde”. Dat is een veel kleinere bewering dan het klinkt.

Echte apps werken wanneer:

• Een andere persoon ze gebruikt.
• De data langer blijft dan de demo.
• Het pad door de app er een is dat je niet had verwacht.
• De uitvoer wordt gelezen op een apparaat dat je niet testte.

Je hoeft geen softwaretester te worden om iets goeds te lanceren. Je hoeft alleen deze vijf checks één keer te doen, de dag voordat je iemand vertelt dat de app bestaat. Ze kosten ongeveer twintig minuten. Ze vangen negen van de tien stille bugs die anders een betalende gebruiker zouden bereiken.

Als je maar tijd hebt voor één, doe de eerste. Dien iets in. Vind het aan de andere kant. De meeste met AI gebouwde apps zien er goed uit. De truc is ervoor zorgen dat ze het ook echt zijn.

Als dit aansloeg, is het volgende dat de moeite waard is om te doen, gaan zitten met een stuk papier en de drie dingen opschrijven waarop je app nooit stilletjes mag falen — het formulier, de e-mail, de betaling, wat het ook is bij jou — en elk ervan doorlopen met de checks hierboven. Twintig minuten nu koopt je later een hoop nachten slaap.