Wat je doet als je met AI gebouwde app om 2 uur 's nachts breekt (en je geen ontwikkelaar bent)

Je bouwde een app zonder code te schrijven. Hij werkte de hele week. Toen stuurt een gebruiker je om 1:47 uur ‘s nachts een bericht dat de aanmeldknop niets doet, en je wordt wakker van je telefoon die op het nachtkastje gloeit.

Als je nog nooit een live app hebt moeten repareren, kan dit moment afschuwelijk voelen. Je leest geen code. Je weet niet wat “de database” echt betekent. Je weet niet zeker of het echt-kapot is of gewoon-vreemd, en de mensen die je normaal zouden helpen slapen.

Dit is een kalm, geordend draaiboek voor wat te doen wanneer een met AI gebouwde app breekt en je geen code kunt schrijven. Het gaat grotendeels over het niet erger maken, het deel waar niemand je voor waarschuwt.

Eerst: niet opnieuw deployen

Er is ergens in je AI-appbouwer een knop die iets zegt als “republiceren”, “redeployen” of “lanceren”. Je gaat hem zo willen indrukken. Doe het nog niet.

Op redeploy drukken bij een half-kapotte app kan de kapotte staat vastzetten, alle debug-informatie die rondhing wegblazen, en het moeilijker maken voor wie dan ook — inclusief de AI-bouwer zelf — om uit te zoeken wat er misging.

De eerste zet is altijd kijken, niet handelen. Je hebt nog niet eens bevestigd wat er kapot is.

Stap 1 — Reproduceer het probleem zelf

Open de app in een vers browservenster — incognito of privémodus is het best, want het verwijdert elke oude login of cache die dingen voor jou anders kan laten gedragen dan voor je gebruiker.

Probeer precies het ding te doen dat de gebruiker rapporteerde. Als ze zeiden dat de aanmeldknop niet werkt, probeer je aan te melden. Als ze zeiden dat het dashboard leeg is, probeer in te loggen en het dashboard te bekijken.

Je zoekt naar een van drie dingen:

Het is voor iedereen kapot. Je raakt hetzelfde probleem. Dat is eigenlijk het makkelijkste soort om te repareren, omdat het consistent is.
Het werkt voor jou. Dit is het moeilijkste scenario, omdat iets aan de specifieke situatie van de gebruiker (hun browser, hun account, hun data) het probleem is.
Het is wisselend. Het werkt één keer en breekt de volgende keer. Dit is het stressvolst maar ook het meest informatief — het betekent meestal dat iets een time-out krijgt of een hulpbron opraakt.

Schrijf op welk van de drie je zag. Je hebt het nodig wanneer je om hulp vraagt.

Stap 2 — Check de voor de hand liggende externe dingen voordat je je app de schuld geeft

Een verrassend aantal “mijn app is kapot”-momenten is niet je app. Voordat je in je AI-bouwer duikt, check:

Is het internet zelf in orde? Open een paar andere sites. Als je wifi haperend is, is je app misschien prima en ben jij misschien de kapotte.
Had de AI-bouwer zelf een storing? De meeste AI-appbouwers hebben een statuspagina (zoek de productnaam plus “status”). Als zij een slechte nacht hebben, hoef je niets anders uit te zoeken.
Ging een van je gekoppelde tools plat? Als je app Stripe gebruikt voor betalingen, een e-maildienst voor meldingen, of een databasedienst om data op te slaan, kan elk daarvan storingen hebben. Elk heeft zijn eigen statuspagina. Check degene waar je app van afhangt.

Ongeveer een op de vijf keer is het antwoord “het is eigenlijk niet mijn app”, en kun je weer gaan slapen.

Stap 3 — Kijk naar de foutmelding, ook al maakt hij je bang

Als je app een scherm met tekst erop toont — zelfs gibberish-achtige tekst — lees het. Maak een screenshot. Vooral als er een lange string letters en cijfers is (mensen noemen dit een “stack trace”; het ziet eruit als alfabetsoep maar het is het nuttigste dat je kunt hebben wanneer je om hulp vraagt).

De meeste AI-appbouwers hebben ook een plek om recent gebeurde fouten te zien. Het kan Logs, Activiteit, Fouten of Console heten. Open het. Je hoeft het meeste van wat je ziet niet te begrijpen — je zoekt de meest recente rode tekst of de meest recente fout, en het tijdstip waarop hij gebeurde. Tijd doet ertoe: een fout van gisterenochtend is waarschijnlijk niet waarom je gebruiker zich zojuist niet kon aanmelden.

Kopieer die fout. Je gaat hem zo ergens nuttigs plakken.

Stap 4 — Vraag de AI-bouwer wat er veranderde

Dit is de zet die de meeste niet-technische bouwers te weinig gebruiken. Open de chat met je AI-bouwer en zeg, in gewone taal:

“Mijn app is kapot. Gebruikers kunnen zich niet aanmelden — de knop doet niets. Hier is de fout uit de logs: [plak hem]. Wat veranderde er in de laatste 24 uur, en wat zou dit kunnen veroorzaken?”

Een goede AI-bouwer vertelt je welke recente wijziging het meest waarschijnlijk verantwoordelijk is. Soms herken je het meteen (“oh, ik vroeg hem gisteren om het formulier mooier te maken en dat brak waarschijnlijk de indienlogica”). Soms wijst hij naar iets dat je je niet herinnert te hebben aangeraakt, wat ook nuttig is — het betekent dat er iets automatisch veranderde, zoals een gekoppelde tool die bijwerkte.

Laat de AI-bouwer nog geen fixes maken. Je bent nog in diagnosemodus. De meest voorkomende manier waarop ik mensen een klein probleem erger heb zien maken, is door een AI dingen te laten “repareren” voordat iemand begrijpt wat er kapot is.

Stap 5 — Beslis of je terugrolt

Bijna elke AI-appbouwer laat je teruggaan naar een eerdere versie van je app. Soms heet het “geschiedenis”, “versies”, “checkpoints” of “rollback”.

Als je je duidelijk een uur of een dag kunt herinneren waarop de app werkte, is teruggaan naar die versie de meest betrouwbare zet. Het kost je welke wijzigingen je ertussen ook maakte (die je misschien niet eens meer wilt), en het geeft je een werkende app om wakker bij te worden.

Een goede regel: als het kapotte ding iets is dat gebruikers elke dag doen (aanmelden, inloggen, betaling), rol dan eerst terug en repareer later vooruit. Werkend-maar-oud verslaat kapot-en-actueel elke keer.

Als het kapotte ding een functie is die je vandaag toevoegde en waar nog niemand op rekent, kun je hem kapot laten tot de ochtend en hem met een helder hoofd repareren.

Stap 6 — Als je de AI-bouwer het wel moet laten repareren

Als rollback niet mogelijk is, of je hebt besloten dat niet te doen, laat dan de AI-bouwer een fix voorstellen. Twee dingen om in gedachten te houden terwijl hij dat doet:

Lees wat hij van plan is te veranderen voordat je het goedkeurt. Je begrijpt niet alles ervan, maar je kunt zien of hij één gefocust ding bewerkt of de helft van de app herschrijft. Kleine, gefocuste wijzigingen zijn veel veiliger dan ingrijpende om 2 uur ‘s nachts.

Test de fix op de meest saaie manier mogelijk. Vraag niet gewoon “is het gerepareerd?” en vertrouw het antwoord. Ga echt zelf naar de app in een incognitovenster en doe het ding dat kapot was. Als de fix werkte, werkt het kapotte ding nu. Zo niet, accepteer de wijziging dan niet alleen omdat de AI-bouwer zei dat het werkte.

Stap 7 — Schrijf de gebruiker terug, ook als je het niet repareerde

De gebruiker die je om 1:47 uur ‘s nachts een bericht stuurde, verwacht niet dat je online bent. Maar als je dat bent, doet een kort antwoord er meer toe dan een fix:

“Bedankt voor het laten weten — ik kijk er nu naar. Ik stuur je een berichtje zodra het weer werkt.”

Als ze een betalende gebruiker zijn, is dat ene bericht het verschil tussen hen die mensen vertellen dat je snel reageert en hen die mensen vertellen dat je ze negeerde. De fix kan wachten tot de ochtend. Het antwoord niet.

De grotere les: bouw je app alsof hij kan breken

Als je dit stressvol vond, is de zilveren rand dat de ervaring zal hervormen hoe je bouwt. Na je eerste 2-uur-’s-nachts-incident ga je dingen anders doen:

Je voegt een statuscheck toe. Een simpele pagina die je vertelt of de belangrijke delen van je app werken, zodat je niet hoeft in te loggen om erachter te komen.
Je houdt een back-up van de gebruikersdata bij. De meeste AI-bouwers exporteren je data op verzoek. Dit eens per week doen kost 30 seconden en redt je in een worstcasescenario.
Je schrijft op waar je app van afhangt. Een korte lijst van elke gekoppelde tool (betalingen, e-mail, database, opslag), zodat je, wanneer er om 2 uur ‘s nachts iets breekt, een checklist hebt in plaats van gissingen.
Je verandert één ding tegelijk. Wanneer je 10 wijzigingen tegelijk maakt en de app breekt, heb je geen idee welke wijziging hem brak. Wanneer je één ding tegelijk verandert, weet je het wel.

Je kunt een app bouwen zonder code. Je kunt er ook een draaiende houden zonder ontwikkelaar te zijn — maar de vaardigheden zijn anders dan de bouwvaardigheden. Je leert ze meestal op de harde manier, meestal op een ongelegen uur.

Het goede nieuws: elke keer dat het gebeurt, wordt het minder eng. Tegen de derde keer is het vervelend in plaats van angstaanjagend. Tegen de tiende is het gewoon dinsdag.