Slik feilsøker du en app bygget med AI: en praktisk metode

For å feilsøke en app bygget med AI må du først få feilen til å oppstå igjen med vilje, og så samle bevis — de nøyaktige stegene, feilmeldingen, og hva konsollen og nettverksfanen i nettleseren viser — og gi det til AI-en som «Jeg gjorde X, forventet Y, fikk Z». Hvis en rettelse gjør ting verre, rull tilbake til siste fungerende versjon i stedet for å legge flere rettelser oppå. Du trenger ikke å lese koden for å gjøre dette godt.

Denne guiden dekker hele løkken, inkludert en rask gjennomgang av nettleserens utviklerverktøy for folk uten teknisk bakgrunn.

Feilsøkingsløkken

Hver feilrettelse, enten den gjøres av en person eller en AI, følger den samme løkken:

1. Gjenskap — få feilen til å oppstå pålitelig.
2. Observer — samle feilmeldingen og hva appen gjorde.
3. Beskriv — gi AI-en presise steg, forventet resultat og faktisk resultat.
4. Rett — la AI-en endre én ting.
5. Verifiser — gjenta de nøyaktige stegene og bekreft at feilen er borte, og at ingenting i nærheten gikk i stykker.
6. Rull tilbake ved behov — hvis det ble verre, angre og prøv igjen med bedre informasjon.

Mesteparten av tiden som kastes bort på apper bygget med AI, kommer av at man hopper over steg 1, 2 og 5: å si «det er ødelagt», godta en endring uten å teste den, og så be om enda en rettelse oppå en ødelagt en.

Steg 1: Gjenskap feilen

En feil du kan utløse etter ønske er halvveis fikset. Prøv å finne det korteste settet med steg som forårsaker den.

Spør deg selv:

• Skjer det hver gang? Hvis bare noen ganger, hva er annerledes når det skjer — en bestemt post, en treg forbindelse, at du er logget ut?
• Skjer det for alle brukere? Logg inn med en annen konto. Mange feil vises bare for nye brukere uten data, eller for en bruker med en annen rolle.
• Skjer det på alle enheter? Prøv en skjerm i mobilbredde og en annen nettleser.
• Startet det etter en bestemt endring? Hvis det fungerte i går, er de siste endringene hovedmistenkte.

Skriv stegene ned som en kort nummerert liste. Du limer den inn i prompten senere.

Steg 2: Les feilmeldingen

Feilmeldinger virker skremmende, men du trenger bare noen få deler av dem.

Du trenger ikke forstå den; du må kopiere den nøyaktig. «Cannot read properties of undefined (reading 'name')» forteller AI-en at koden forventet data (sannsynligvis en booking eller en bruker) som ikke kom. En omskriving som «en undefined-feil» mister det.

Noen vanlige, grovt oversatt:

• undefined- / null-feil — koden forventet data som ikke kom fram. Ofte en lastetilstand eller en tom liste som koden ikke håndterte.
• 404 Not Found — siden eller API-adressen finnes ikke. Ofte en skrivefeil i en rute, eller en lenke til en side som ble omdøpt.
• 401 Unauthorized / 403 Forbidden — forespørselen var ikke innlogget, eller brukeren har ikke lov til å gjøre det.
• 500 Internal Server Error — koden på serveren krasjet. Den egentlige grunnen står i serverloggene, ikke i nettleseren.
• CORS-feil — nettleseren blokkerte en forespørsel til et annet domene. Vanligvis et konfigurasjonsproblem på serversiden.

Steg 3: Bruk nettleserens utviklerverktøy

Alle stasjonære nettlesere har innebygde utviklerverktøy («devtools»). De viser hva siden gjør bak kulissene. I Chrome, Edge og Firefox høyreklikker du hvor som helst på siden og velger Inspiser, eller trykker F12 (Cmd+Option+I på en Mac). I Safari må du først slå på Utvikler-menyen i Safaris innstillinger.

Du trenger bare tre faner.

Konsoll

Fanen Konsoll lister feil og meldinger fra sidens kode. Feil vises i rødt. Hvis en knapp ikke gjør noe når du klikker på den, viser konsollen veldig ofte en rød feil i det øyeblikket du klikker. Kopier hele feilteksten (høyreklikk for et kopialternativ i de fleste nettlesere).

Nettverk

Fanen Nettverk lister hver forespørsel siden gjør — laste inn data, lagre et skjema, logge inn. Åpne den, og gjenta stegene som forårsaker feilen.

• Se etter rader i rødt eller med status 400 eller høyere.
• Klikk på en feilende rad for å se Respons. En serverfeil inneholder ofte en melding der som er mer nyttig enn noe på skjermen.
• Noter forespørselens URL og statuskode — «POST til /api/bookings returnerte 500» er en svært nyttig setning å gi AI-en.

Skru på Behold logg hvis feilen involverer en sideinnlasting eller omdirigering, slik at forespørslene ikke forsvinner.

Elementer

Fanen Elementer (eller Inspektør) viser sidens struktur og stiler. Den er mest nyttig for layoutfeil: hold musepekeren over et element for å se størrelse og avstand markert. Du trenger ikke redigere noe her; det er nok å si «footeren er 2000 piksler bred på mobil og dytter siden sideveis».

Steg 4: Sjekk serverloggene

Noen feil skjer på serveren, der nettleseren ikke ser dem. En 500-feil i nettverksfanen er det klassiske tegnet. Serverlogger — tekstutdata fra backend mens den kjører — inneholder vanligvis den egentlige feilen med en stack trace (en liste over funksjonene som kjørte da det feilet).

Hvor du finner dem, avhenger av verktøyet. I de fleste KI-appbyggere kan du åpne en terminal eller loggvisning for prosjektet, eller du kan bare spørre AI-en: «Sjekk serverloggene for feil fra den siste forespørselen, og fortell meg hva som feilet.»

Steg 5: Beskriv feilen for AI-en

Sett det du har samlet i denne formen:

På bookingsiden, innlogget som medlem: Jeg klikket Avbestill på morgendagens 9:00-time. Forventet: bookingen forsvinner og timen viser én ledig plass til. Faktisk: ingenting endrer seg på skjermen. Konsollen viser TypeError: Cannot read properties of undefined (reading 'id') i BookingCard.tsx:31, og nettverksfanen viser at DELETE /api/bookings/123 returnerte 500. Finn årsaken, fiks den, og sjekk at avbestilling fungerer for et medlem med én booking og for et med flere.

Hvorfor hver del betyr noe:

• Hvor og som hvem avgrenser det til én skjerm og én rolle.
• Nøyaktige steg lar AI-en gjenskape feilen.
• Forventet mot faktisk definerer hva «fikset» betyr.
• Feilteksten og den feilende forespørselen peker rett på årsaken.
• «Sjekk at …» ber AI-en verifisere, ikke bare endre.

Hvis AI-en har forsøkt en rettelse to ganger uten hell, be den forklare før den endrer noe:

Ikke endre koden ennå. Hva tror du forårsaker dette, og hvilke bevis støtter det?

En feil teori er lett å oppdage når den er skrevet ut, og mye billigere å korrigere enn en feil rettelse.

Steg 6: Verifiser, og sjekk nabolaget

Når AI-en sier at det er fikset, gjenta de nøyaktige stegene fra steg 1. Sjekk så det som er rundt:

• Samme handling for en annen brukerrolle
• Samme handling uten data, og med mye data
• Sider som deler komponenter med den du fikset
• En skjerm i mobilbredde, hvis rettelsen berørte layouten

KI-endringer fikser noen ganger én sti og ødelegger en annen i stillhet. En to minutter lang sjekk nå sparer en forvirret time senere.

Steg 7: Rull tilbake i stedet for å stable på

Hvis en rettelse gjorde ting verre, eller du har gått tre runder uten fremdrift, gå tilbake. Å rulle tilbake til siste versjon som fungerte og formulere på nytt med bedre bevis slår nesten alltid å be om en fjerde rettelse oppå tre feil. Hvert mislykket forsøk etterlater kode, og den koden forvirrer neste forsøk.

Gode vaner som gjør tilbakerulling enkel:

• Test etter hver endring, slik at du vet hvilken endring som ødela.
• Hold endringene små — én funksjon eller rettelse per melding.
• Noter den siste gode versjonen før du gjør noe risikabelt.
• Hvis koden er i Git, commit fungerende versjoner slik at du kan gå tilbake til dem.

Vanlige feilmønstre i apper bygget med AI

Når problemet ikke er en feil

Noen «feil» er at AI-en bygger nøyaktig det den fikk beskjed om, og beskrivelsen var tvetydig. Hvis rettelsen du ber om egentlig er en endring i oppførsel, si det tydelig: «Endre det slik at …». Hvis du merker at du er usikker på hva den riktige oppførselen egentlig er, bestem det først. Vår guide om å skrive prompter til KI-appbyggere dekker hvordan du spesifiserer regler tydelig. Og hvis du forbereder en app for ekte brukere, dekker å ta en KI-prototype til produksjon sjekkene som er verdt å gjøre før lansering.

Feilsøking i Mythex

Mythex har verktøy for hvert steg i løkken:

• Forhåndsvisning for å gjenskape feilen, inkludert en ramme i telefonstørrelse.
• /test får agenten til å klikke seg gjennom den live forhåndsvisningen din som en bruker, og melde om ødelagte flyter.
• /fix peker agenten mot brudd spesifikt.
• Plan-modus lar agenten undersøke og forklare før den redigerer noe.
• Kode → terminal viser serverloggene for appen din.
• Gå tilbake til dette punktet på et hvilket som helst svar ruller prosjektet tilbake til det sjekkpunktet.

Hvis en publisering feiler, tilbyr publiseringsdialogen vanligvis Fiks med AI, som leser bygg-utdataene eller appens logger. Se Feilsøk appen din og Feilsøking ved publisering i dokumentasjonen.

Spørsmål