Slik gjennomgår du AI-generert kode

For å gjennomgå AI-generert kode, start med hva som endret seg — hvilke filer og hvorfor — og test oppførselen selv før du leser noen linjer kode. Deretter sjekker du områdene der AI-kode oftest går galt: manglende tillatelsessjekker på serversiden, hemmeligheter eksponert for nettleseren, uvalidert input, pakker eller funksjoner som ikke finnes, og endringer i ting du aldri ba den røre.

AI skriver kode som vanligvis kjører og ofte ser ryddig ut. Det gjør den lett å godkjenne uten å sjekke skikkelig. Denne guiden er en gjennomgangsrutine som fungerer enten du leser kode flytende eller ikke i det hele tatt.

Tilpass gjennomgangen til risikoen

Ikke alle endringer trenger like mye oppmerksomhet.

Steg 1: Se hva som endret seg

Før du vurderer koden, hent listen over endringer:

• Hvis prosjektet er i Git, se på diffen: filene og linjene som er endret siden forrige commit. Se slik bruker du Git med en AI-bygd app.
• Eller spør AI-en direkte:

List opp hver fil du endret i den siste endringen, og forklar for hver én med én setning hva som endret seg og hvorfor.

Røde flagg på dette stadiet: filer som ikke har med forespørselen å gjøre, slettede filer, endringer i konfigurasjon eller avhengigheter du ikke ba om.

Steg 2: Test oppførselen først

Å lese koden forteller deg hva den er ment å gjøre; å teste den forteller deg hva den faktisk gjør. Før du leser:

• Prøv endringen som en vanlig bruker, på desktop og på et skjermbilde i telefonstørrelse.
• Prøv med feil input: tomme felt, svært lang tekst, negative tall, en dato i fortiden.
• Prøv den uten å være logget inn, og som en annen bruker.
• Kjør på nytt de flytene som betyr mest: registrering, innlogging, hovedhandlingen, betaling.

Hvis testingen feiler, har du spart lesetid — meld fra tydelig og la AI-en fikse det. Se slik skriver du en god feilrapport.

Steg 3: Sjekk tillatelser på serveren

Dette er det viktigste å sjekke. AI-verktøy skjuler ofte en knapp i siden, men lar serveren fortsatt utføre handlingen for hvem som helst som spør.

For hver rute eller funksjon som leser eller endrer data, spør:

• Sjekker den at brukeren er innlogget?
• Sjekker den at denne brukeren har lov til å få tilgang til denne posten?
• Ligger sjekken på serveren, ikke bare i siden?

For hver API-rute du har lagt til eller endret, fortell meg hvilken tillatelsessjekk den gjør på serveren, og siter linjen. Flagg enhver rute uten en.

Test det deretter: logg inn som bruker A, noter ID-en til en post, logg inn som bruker B og be om den. Sikkerhetssjekklisten for AI-bygde apper har hele testen.

Steg 4: Se etter eksponerte hemmeligheter

• Søk i de endrede filene etter alt som ser ut som en nøkkel eller et passord.
• Sjekk at hemmelige nøkler leses fra miljøvariabler og bare brukes i serverkode.
• Se etter offentlige prefikser som VITE_ eller NEXT_PUBLIC_ på hemmelige variabler — de bygges inn i kode i nettleseren.

Se slik holder du API-nøkler trygge.

Steg 5: Sjekk input og feil

• Validering på serveren. Sjekker i nettleseren kan hoppes over. Påkrevde felt, lengder, formater og tillatte verdier bør også sjekkes av serveren.
• Databasespørringer bruker parametere, ikke tekst bygget ved å sette brukerinput sammen i en spørring.
• Feil svelges ikke. En try/catch som ikke gjør noe skjuler feil. Feil bør logges, og brukere bør se en enkel melding.
• Ingen interne detaljer vises til brukere — stacktraces og databasefeil hører hjemme i logger.

Steg 6: Sjekk at det er ekte

AI-modeller lager noen ganger kode som ser riktig ut, men viser til ting som ikke finnes.

• Pakker: hver ny avhengighet bør være en ekte, vedlikeholdt pakke med det nøyaktige navnet. Vær skeptisk til navn som ligner skrivefeil av populære pakker.
• Funksjoner og API-valg: hvis koden kaller en bibliotekfunksjon eller et eksternt API-valg du aldri har sett, sjekk den offisielle dokumentasjonen.
• Plassholderkode: søk etter TODO, mock, fake, hardkodede eksempeldata, eller funksjoner som returnerer en fast verdi.

Har du lagt til nye pakker? For hver én, gi meg det nøyaktige navnet, hva den er til for, og om vi kunne klart oss uten den.

Steg 7: Sjekk at det passer

Kode kan fungere og likevel gjøre appen vanskeligere å endre senere:

• Duplisering. Samme logikk kopiert til flere steder vil gli fra hverandre.
• Konsistens. Den bør følge mønstrene resten av appen bruker.
• Størrelse. En forespørsel på 20 linjer som ga 600 linjer fortjener et spørsmål.
• Død kode. Gamle versjoner som ble liggende ved siden av nye.

Finnes det kode i prosjektet som nå er ubrukt på grunn av denne endringen, eller logikk som er duplisert et annet sted? Ikke endre noe; bare list det opp.

Vanlige feil

• Å godkjenne fordi det ser ryddig ut. Pen kode kan likevel hoppe over en tillatelsessjekk.
• Å lese i stedet for å teste. Test først; les etterpå.
• Bare å teste den lykkelige veien. Prøv dårlig input, feil bruker og uten innlogging.
• Å ignorere endringer i urelaterte filer. Spør hvorfor hver fil endret seg.
• Å stole helt på AI-ens egen gjennomgang. Bruk den som en første gjennomgang og bekreft ved å teste.
• Å gå gjennom en ukes endringer på en gang. Gjennomgå små endringer etter hvert som de skjer.

Sjekkliste

• Jeg vet hvilke filer som endret seg og hvorfor, og ingenting urelatert endret seg.
• Endringen fungerer på desktop og telefon, med dårlig input, uten innlogging og som en annen bruker.
• Hver datarute sjekker innlogging og eierskap på serveren.
• Ingen hemmeligheter i kode eller nettleserpakker.
• Input valideres på serveren; spørringer bruker parametere.
• Feil logges, svelges ikke, og vises ikke i detalj til brukere.
• Nye pakker er ekte og nødvendige; ingen oppfunnede funksjoner eller plassholdere gjenstår.
• Endringer med høy risiko har fått en grundig lesning og, der det trengs, en andre gjennomgåer.

Gjennomgå kode på Mythex

• Ask-modus svarer på spørsmål om koden uten å redigere den — ideelt for ledetekster som «forklar hver endring» og «hvilke ruter mangler en tillatelsessjekk». Se Chat.
• Kodevisning viser filtreet, editoren og terminalen på alle planer (skrivebeskyttet på Free, redigerbar på Pro), slik at du kan lese selv hva som endret seg. Se Kodeeditor.
• /test lar agenten klikke seg gjennom forhåndsvisningen som en bruker og melde fra om ødelagte flyter.
• Sjekkpunkter lar deg tilbakestille en endring som ikke består gjennomgangen.

Hvis en utvikler gjennomgår for deg, dekker slik jobber du med en utvikler på en AI-bygd app overleveringen; hvis gjennomgangen avdekker en feil, se slik feilsøker du en AI-bygd app.

Spørsmål