Slik kontrollerer du AI-generert kode når du ikke kan lese kode: 7 kontroller for ikke-programmerere i 2026

AI satte sammen et nettsted eller en bot for deg på en kveld. Alt åpnes, knappene fungerer, og det ser ut til å kjøre. Du viser prosjektet til folk — og en dag senere finner du ut at betalingsskjemaet belaster penger, men at bestillingene aldri kommer fram. Eller at databasen med kundenes telefonnumre er åpen for hele internett.

Jeg lanserte også de første prosjektene mine på den måten: Ting som så ut til å fungere, bød på overraskelser for ekte brukere. Nå går jeg gjennom den samme sjekklisten før jeg viser noe til folk. Jeg leser ikke en eneste kodelinje mens jeg gjør det — jeg kom ikke hit for det, og du gjorde sannsynligvis heller ikke det.

Og dette er ikke paranoia. Anthropic analyserte 400,000 Claude Code-økter: I løpet av sju måneder falt andelen arbeid som ble brukt på å rette ødelagt kode, fra 33% til 19%. Den falt, men forsvant ikke. Hver femte økt handler fortsatt om å «fikse det AI-en ødela».

Selve kodingen er ikke lenger flaskehalsen. Det som betyr noe nå, er hvor godt du forstår oppgaven, og hvor godt du kan kontrollere resultatet.

Du finner mer materiale om konfigurering av verktøy i Ailoot-dokumentasjonen.

Hvorfor bør du kontrollere AI-generert kode hvis den allerede fungerer?#

AI skriver kode som ser riktig ut ved første øyekast. Den kjører, skjermbildet vises, og demoen virker overbevisende. Men en lansering forteller deg ingenting om hvorvidt pengene beregnes riktig, om databasen din er tilgjengelig utenfra, eller om alt krasjer når bruker nummer hundre dukker opp.

Tallene bekrefter dette. Referansetesten FrontierCode undersøkte i juni 2026 hvor klar AI-generert kode var for reelt arbeid uten endringer. Selv for de beste modellene på de vanskeligste oppgavene var andelen omtrent 13%. Med andre ord må mesteparten av AI-generert kode på alvorlige oppgaver forbedres manuelt før du kan stole på den.

Den gode nyheten er at hvem som helst kan utføre kontrollen. Dette konkluderte Anthropic med etter å ha analysert de samme 400,000 øktene:

Fordelen din sammenlignet med en programmerer du henter inn, er at du forstår oppgaven din. Kontroll handler også om forståelse; du trenger ikke å lese kode. Kontrollene nedenfor er nettopp av den typen du kan utføre selv, uten noe styr.

Hva kan egentlig gå galt med AI-generert kode?#

Før du kontrollerer, er det nyttig å vite hva du ser etter. AI-generert kode har fem typiske problemer, og du kan oppdage alle fem uten å lese kode — ved å følge med på hvordan prosjektet oppfører seg.

Deretter følger sju kontroller i riktig rekkefølge. De første fanger opp at noe «ikke fungerer» eller «fungerer feil»; de midterste dekker sikkerhet og fabrikasjoner; de siste er sikkerhetstiltak før publisering. Det er best å gå gjennom dem i rekkefølge: Hver kontroll bygger på at den forrige er fullført.

Kontroll 1: Be AI forklare koden med vanlige ord#

Du beskrev oppgaven med ord. AI-en oversatte den til kode. Betydning kan gå tapt mellom disse to trinnene: AI-en kan ha forstått deg annerledes, fylt inn ting på dine vegne eller tatt snarveier. Du kan oppdage avviket uten å lese kode — bare be den beskrive hva den gjorde med vanlige ord.

Forklar nøyaktig hva du nettopp gjorde med vanlige ord, uten kode:

hvilken oppgave denne koden løser

hva som skjer når en bruker klikker på knappen eller sender inn skjemaet

hvor dataene lagres, og hvem som har tilgang til dem

hva som kan gå galt, og i hvilken situasjon

Skriv som om du forklarer det til noen som aldri har programmert. Hvis det er noe du ikke er sikker på om stemmer, skal du si det tydelig.

Les svaret og sammenlign det med det du hadde sett for deg. Hvis det stemmer, går du videre. Hvis AI-en «snakker rundt grøten», roter seg bort i sin egen forklaring eller beskriver noe annet enn det du ba om, betyr det at den ikke helt forstår hva den har laget. Be den revidere med en presisering i stedet for å ta den på ordet.

Forresten: Hvis AI-en jevnlig gjør noe annet enn det du ber om, skyldes problemet ofte hvordan oppgaven ble formulert, ikke selve modellen. Jeg har en egen gjennomgang av hvorfor Claude ikke gjør det du ber om.

Kontroll av AI-resultater er en del av kontekstutvikling: Du styrer både hva du gir AI-en som inndata, og hvordan du vurderer resultatet som utdata.

Kontroll 2: Gå gjennom scenarioene slik en ekte bruker ville gjort#

En AI-demo følger alltid den problemfrie veien: riktige data, ett klikk, og alt går som det skal. En ekte bruker oppfører seg ikke slik. De gjør feil, klikker på feil ting eller skriver inn en emoji i telefonfeltet. Jobben din er å gå gjennom prosjektet slik de ville gjort.

1. Gjennomfør hovedscenarioet fra start til slutt

   Gjør det prosjektet er laget for: registrer deg, legg inn en bestilling, send inn en forespørsel. Gå helt til slutten, ikke bare halvveis.

2. Kontroller betalingen separat og på ordentlig

   Hvis prosjektet tar imot penger, gjør selv en betaling på minimumsbeløpet i testmodus. Kontroller at bestillingen opprettes, statusen endres, og at en e-post sendes til deg og kunden. En betaling som «går gjennom» uten å opprette en bestilling, er en klassisk stille feil.

3. Prøv bevisst å få ting til å gå galt

   La felter stå tomme. Skriv bokstaver der det forventes tall. Klikk på «Send inn» to ganger på rad. Last opp en fil med feil format. Et godt prosjekt sier høflig «det kan du ikke gjøre»; et dårlig prosjekt krasjer eller sluker dataene uten å si fra.

4. Åpne det på en telefon

   Halvparten av brukerne dine kommer fra en telefon. Kontroller at oppsettet ikke har falt fra hverandre, og at de samme knappene fungerer der.

Gi AI-en alt du fant, i én liste: «Dette gikk galt i disse trinnene; rett det og forklar hvorfor det skjedde.» Ikke håndter ett problem om gangen — gi AI-en hele listen, så den kan se helheten og har mindre risiko for å ødelegge én ting mens den retter en annen.

Kontroll 3: Spør AI om sikkerhet — her er en ledetekst#

En ødelagt knapp er umiddelbart synlig. Et sikkerhetshull er ikke det: Prosjektet fortsetter å fungere som om ingenting er galt helt til noen utnytter det. De vanligste problemene i vibe-coded prosjekter er hemmelige nøkler skrevet direkte i koden, en database som er eksponert mot internett, og skjemaer som lar noen sende inn skadelige data. AI kan finne alt dette hvis du spør direkte.

Gjør en sikkerhetsrevisjon av dette prosjektet, og forklar hvert funn med vanlige ord, uten fagsjargong. Gå gjennom denne listen:

Sjekk om hemmelige nøkler, passord eller tokens er skrevet direkte i koden. Private hemmeligheter må bare brukes på serveren, med lokal hemmelighetskonfigurasjon som .env utelukket fra Git. .env og .gitignore hindrer ikke at frontend-/offentlige variabler havner i nettleserbygget. Undersøk faktisk JavaScript, source maps, HTML og nettverkssvar sendt til klienten, og verifiser at private nøkler mangler.

Sjekk om databasen er eksponert mot internett, og hvem som har tilgang til den.

Sjekk om inndata kan ødelegge skjemaene: injeksjoner i databasespørringer eller ekstra kode i tekstfelter.

Hva skjer hvis en bruker sender inn skadelige data?

Sjekk om interne sider eller administrasjonspanelet er tilgjengelig uten passord.

For hvert punkt skal du si om det er et problem, gi et tydelig eksempel på risikoen og forklare hvordan den kan rettes. Start med det farligste problemet.

Sjekk også at prosjektet ikke blindt gjør hva som helst det mottar utenfra. Dette kalles indirekte prompt-injeksjon: En kommando skjules i en e-post, kommentar eller fil fra noen andre, og AI-agenten følger den fordi den tror det er en oppgave. Hvis prosjektet leser eksterne data og handler ut fra dem, bør du spørre AI-en hva som ville skje hvis dataene inneholdt en skjult instruksjon.

Dette er et omfattende tema, og én ledetekst kan ikke dekke det fullt ut. Hvis prosjektet håndterer penger eller kundenes personopplysninger, bør du lese den separate veiledningen om sikkerhet ved vibe-coding.

Kontroll 4: Fant AI opp biblioteker eller data?#

AI skriver selvsikkert ting som ikke finnes. Den kan legge til et bibliotek med et troverdig navn, selv om biblioteket ikke eksisterer. Den kan la testplassholdere stå igjen i prosjektet: et produkt som heter «Example», e-postadressen example@example.com eller fylltekst i stedet for ekte innhold. Det er lett å overse i en demo, men pinlig eller ødeleggende for en ekte bruker.

Du kan oppdage dette i to trinn. Først spør du direkte:

Gå gjennom prosjektet og kontroller ærlig:

Finnes alle eksterne verktøy og biblioteker du har lagt til, og installeres de riktig? Har du diktet opp noe?

Er det fortsatt testplassholdere, eksempler eller fylltekst i stedet for ekte data?

Er alle lenker, adresser og kontaktopplysninger i prosjektet ekte, og ikke plassholdere?

List opp det du fant, og foreslå hva det kan erstattes med.

Deretter kjører du bare prosjektet og ser gjennom det. Et oppdiktet bibliotek fører nesten alltid til en feil ved oppstart. Plassholdere er også lette å få øye på: Hvis siden sier «Product 1», har du ikke erstattet dem.

Oppdiktede biblioteker innebærer en egen fare fordi angripere bevisst registrerer verktøy med navn AI liker å finne på. Installerer du et slikt verktøy, kommer andres kode inn i prosjektet ditt. Derfor bør du ta spørsmålet «finnes dette biblioteket egentlig?» på alvor — det handler direkte om sikkerheten i prosjektet ditt.

Kontroll 5: La en annen modell kontrollere den første#

AI har en ubehagelig egenskap: Den sier seg enig. Spør du «ser alt greit ut her?», bekrefter den at alt er i orden fordi den tilpasser seg svaret den forventer. Dette kalles AI-sykofanti, og jeg har skrevet om det separat. En samtalepartner som dette vil være mild mot sitt eget arbeid.

Løsningen er enkel: Be om en second opinion. Åpne en ny økt eller bruk en annen modell, og be den kontrollere prosjektet med samme ledetekst som i Kontroll 3, med ett tillegg: «En annen AI skrev denne koden; finn svakhetene.» En ny modell er ikke bundet til den forrige samtalen og vil lettere påpeke problemer.

1. Åpne en ren økt eller bruk en annen modell

   Bruk en annen modell, eller den samme i et nytt vindu uten oppgavehistorikk.

2. Gi den prosjektet og en tydelig ramme

   Si rett ut: «En annen AI skrev denne koden; din jobb er å finne feil og risikoer, ikke å rose den.» Det demper sykofantien.

3. Sammenlign de to vurderingene

   Hvis begge er enige, har de sannsynligvis rett. Hvis de er uenige, bør du undersøke det punktet — det er der det blir interessant.

Dette er akkurat det som skjer i bransjen nå: AI skriver, AI kontrollerer, og den endelige avgjørelsen ligger hos et menneske. Du kan ikke overlate den til modellen — det er din jobb.

Kontroll 6: Hvordan kan du rulle tilbake hvis en endring ødelegger noe?#

Kontrollene på denne listen fører ofte til endringer, og endringer kan noen ganger ødelegge noe som fungerte. For å hindre at det blir en katastrofe, lagrer du den fungerende versjonen i git før hver runde med rettinger. Det er som å lagre et spill: Hvis du ødelegger noe, laster du inn det siste lagringspunktet.

Du trenger ikke å lese kode for å gjøre dette. Bare be AI-en: «Lagre den nåværende fungerende versjonen i git med en tydelig etikett før du endrer noe.» Og hvis alt går galt etter endringene: «Gjenopprett prosjektet til den tidligere lagrede versjonen.»

Hvis git fortsatt er ukjent terreng, har jeg to veiledninger til deg: slik ruller du tilbake endringer i Claude Code og hva du gjør hvis AI slettet databasen din. Den siste er for situasjoner der det allerede er for sent å rulle tilbake, men du fortsatt kan gjenopprette dataene.

Kontroll 7: Hva bør du kontrollere til slutt før publisering?#

De første seks kontrollene handler om hva koden gjør. Den sjuende handler om hvorvidt prosjektet er klart til å møte folk. Det er her folk oftest snubler: Prosjektet fungerer, men de glemte å bytte betalingen fra testnøkkelen til den aktive nøkkelen, slik at de første kundene betaler «på liksom».

1. Betaling: fra test til live

   Hvis du tar imot betalinger, må du kontrollere at betalingssystemets live-nøkkel er koblet til, ikke testnøkkelen. Gjør én ekte betaling på minimumsbeløpet, og refunder den til deg selv.

2. Hemmeligheter ligger der de skal

   Spør KI-en: «Brukes private nøkler bare på serveren, med .env utelukket fra Git? Inneholder faktisk nettleserbygg eller klientsvar en privat nøkkel, inkludert gjennom frontend-/offentlige variabler eller source maps?» Kontroller bygde filer og nettleserens nettverkssvar, ikke bare .env-kilden. Git-utelukkelse holder ikke en verdi utenfor frontendpakken.

3. Ta sikkerhetskopi av dataene

   Sørg for at databasen lagres automatisk et sted. Hvis prosjektet kjører på din egen server, forklarer jeg hva du skal gjøre med publisering i Coolify-veiledningen.

4. Publisering fungerer også utenfor din egen enhet

   Åpne prosjektet på telefonen via en ekstern lenke, ikke bare på din egen datamaskin. Noe som fungerer lokalt, fungerer ikke alltid etter publisering.

Gå gjennom alle fire punktene, så kan du vise prosjektet til folk med ro i sinnet. Hvis noe ikke stemmer, er det bedre å bruke en halvtime nå enn å håndtere misfornøyde kunder senere.

Hva om kontrollen tar for lang tid — bør du bare stole på AI?#

Jeg forstår fristelsen. Kontroll føles kjedelig og «ikke grunnen til at jeg skaffet meg AI». Men det er du, ikke modellen, som er ansvarlig for resultatet. AI har ikke noe omdømme og møter ingen konsekvenser: Den produserte koden og glemte alt sammen. Det er du som må svare en kunde når betalingen ikke gikk gjennom.

Skaperen av Claude Code har et enda bredere perspektiv:

Koding er ikke lenger flaskehalsen — AI tok seg av den. Nå ligger verdien et annet sted: i å forstå oppgaven og kontrollere resultatet. Det er din styrke — du vet bedre enn en utvikler utenfra hva resultatet bør være for kunden din.

Hvorfor er kontroll en ferdighet og ikke en engangsoppgave?#

Disse sju kontrollene er minimumet som skiller «jeg lanserte det og håper» fra «jeg lanserte det og vet at det fungerer». Gå gjennom dem én gang, så fanger du allerede opp de fleste overraskelsene før kundene gjør det.

Derfra blir det en vane. Gi AI-en riktig kontekst som inndata, og kontroller resultatet som utdata. Da blir hvert nytt prosjekt ferdig raskere fordi du ikke begynner fra bunnen av.

Finn mer materiale om bruk av verktøy i Ailoot-dokumentasjonen.