Sådan gennemgår du AI-genereret kode

For at gennemgå AI-genereret kode skal du starte med, hvad der er ændret – hvilke filer og hvorfor – og derefter teste adfærden selv, før du læser en eneste kodelinje. Derefter tjekker du de områder, hvor AI-kode oftest går galt: manglende rettighedstjek på serveren, hemmeligheder eksponeret for browseren, ikke-validerede input, pakker eller funktioner der ikke findes, og redigeringer af ting, du aldrig bad den om at røre.

AI skriver kode, der typisk kører og ofte ser ryddelig ud. Det gør det let at godkende uden rigtigt at tjekke. Denne guide er en gennemgangsrutine, der virker, uanset om du læser kode flydende eller slet ikke.

Tilpas gennemgangen til risikoen

Ikke alle ændringer kræver lige meget opmærksomhed.

Trin 1: Se, hvad der er ændret

Før du vurderer koden, skal du få listen over ændringer:

• Hvis projektet ligger i Git, så kig på diffen: filerne og linjerne, der er ændret siden sidste commit. Se sådan bruger du Git med en AI-bygget app.
• Eller spørg AI'en direkte:

List hver fil, du ændrede i den sidste ændring, og forklar for hver enkelt med én sætning, hvad der ændrede sig, og hvorfor.

Røde flag på dette stadie: filer, der ikke har noget med anmodningen at gøre, slettede filer, ændringer i konfiguration eller afhængigheder, du ikke bad om.

Trin 2: Test adfærden først

At læse kode fortæller dig, hvad den skal gøre; at teste fortæller dig, hvad den gør. Før du læser:

• Prøv ændringen som en almindelig bruger, på desktop og på en skærm i telefonstørrelse.
• Prøv med forkert input: tomme felter, meget lang tekst, negative tal, en dato i fortiden.
• Prøv den uden at være logget ind, og som en anden bruger.
• Kør de vigtigste flows igen: tilmelding, login, hovedhandlingen, betaling.

Hvis testen fejler, har du sparet dig for læsetid – rapportér det tydeligt, og lad AI'en rette det. Se sådan skriver du en god fejlrapport.

Trin 3: Tjek rettigheder på serveren

Det vigtigste at tjekke. AI-værktøjer skjuler ofte en knap i siden, men lader serveren stadig udføre handlingen for enhver, der beder om det.

For hver rute eller funktion, der læser eller ændrer data, spørg:

• Tjekker den, at brugeren er logget ind?
• Tjekker den, at denne bruger har lov til at tilgå denne post?
• Sidder tjekket på serveren, ikke kun i siden?

For hver API-rute, du har tilføjet eller ændret, så fortæl mig, hvilket rettighedstjek den laver på serveren, og citér linjen. Markér enhver rute uden et.

Test derefter det: log ind som bruger A, notér en posts ID, log ind som bruger B og forespørg den. Sikkerhedstjeklisten for AI-byggede apps har den fulde test.

Trin 4: Led efter eksponerede hemmeligheder

• Søg i de ændrede filer efter alt, der ligner en nøgle eller adgangskode.
• Tjek, at hemmelige nøgler læses fra miljøvariabler og kun bruges i serverkode.
• Vær opmærksom på offentlige præfikser som VITE_ eller NEXT_PUBLIC_ på hemmelige variabler – de bliver bygget ind i browserkoden.

Se sådan holder du API-nøgler sikre.

Trin 5: Tjek input og fejl

• Validering på serveren. Tjek i browseren kan omgås. Påkrævede felter, længder, formater og tilladte værdier bør også tjekkes af serveren.
• Databaseforespørgsler bruger parametre, ikke tekst, der er bygget ved at sammensætte brugerinput i en forespørgsel.
• Fejl bliver ikke sluppet. En try/catch, der ikke gør noget, skjuler fejl. Fejl bør logges, og brugerne bør se en tydelig besked.
• Ingen interne detaljer vist til brugere – stack traces og databasefejl hører hjemme i logs.

Trin 6: Tjek, at det er ægte

AI-modeller producerer somme tider kode, der ser rigtig ud, men henviser til ting, der ikke findes.

• Pakker: hver ny afhængighed bør være en ægte, vedligeholdt pakke med det præcise navn. Vær på vagt over for navne, der ligner tastefejl af populære pakker.
• Funktioner og API-muligheder: hvis koden kalder en biblioteksfunktion eller en ekstern API-mulighed, du aldrig har set, så tjek den officielle dokumentation.
• Pladsholderkode: søg efter TODO, mock, fake, hårdkodede eksempeldata eller funktioner, der returnerer en fast værdi.

Har du tilføjet nye pakker? For hver enkelt: giv det præcise navn, hvad den bruges til, og om vi kunne klare os uden den.

Trin 7: Tjek, at det passer

Kode kan virke og stadig gøre appen sværere at ændre senere:

• Duplikering. Den samme logik kopieret til flere steder vil glide fra hinanden.
• Konsistens. Den bør følge de mønstre, resten af appen bruger.
• Størrelse. En anmodning på 20 linjer, der gav 600 linjer, fortjener et spørgsmål.
• Død kode. Gamle versioner, der er efterladt ved siden af nye.

Er der kode i projektet, der nu ikke bruges som følge af denne ændring, eller logik, der er duplikeret andre steder? Ændr ikke noget; list det blot.

Almindelige fejl

• At godkende, fordi det ser pænt ud. Ryddelig kode kan stadig springe et rettighedstjek over.
• At læse i stedet for at teste. Test først; læs bagefter.
• Kun at teste den glade sti. Prøv dårligt input, den forkerte bruger og ikke-logget-ind.
• At ignorere ændringer i urelaterede filer. Spørg, hvorfor hver fil er ændret.
• At stole helt på en selv-gennemgang. Brug AI'ens gennemgang som et første gennemsyn, og bekræft ved at teste.
• At gennemgå en uges ændringer på én gang. Gennemgå små ændringer, efterhånden som de sker.

Tjekliste

• Jeg ved, hvilke filer der er ændret, og hvorfor, og intet urelateret er ændret.
• Ændringen virker på desktop og telefon, med dårligt input, uden login og som anden bruger.
• Hver dataroute tjekker login og ejerskab på serveren.
• Ingen hemmeligheder i kode eller browser-bundles.
• Input valideres på serveren; forespørgsler bruger parametre.
• Fejl logges og slukkes ikke, og vises ikke i detaljer til brugere.
• Nye pakker er ægte og nødvendige; ingen opdigtede funktioner eller pladsholdere er tilbage.
• Ændringer med høj risiko er læst grundigt og, hvor det er nødvendigt, gennemgået af en anden person.

Gennemgå kode på Mythex

• Spørgetilstand besvarer spørgsmål om koden uden at redigere den – ideel til prompts som "forklar hver ændring" og "hvilke ruter mangler et rettighedstjek". Se Chat.
• Kodevisning viser filtræet, editoren og terminalen på alle planer (skrivebeskyttet på Free, redigerbar på Pro), så du selv kan læse, hvad der er ændret. Se Kodeeditor.
• /test lader agenten klikke sig igennem preview som en bruger og rapportere ødelagte flows.
• Checkpoints lader dig fortryde en ændring, der ikke består gennemgangen.

Hvis en udvikler gennemgår for dig, dækker sådan arbejder du med en udvikler på en AI-bygget app overleveringen; og hvis gennemgangen afslører en fejl, se sådan debugger du en AI-bygget app.

Spørgsmål