Tjek AI-genereret kode: 7 kontroller for ikke-programmører i 2026

AI satte en hjemmeside eller bot sammen til dig på en aften. Alt åbner, knapperne virker, og det ser ud til at køre. Du viser projektet til andre – og en dag senere finder du ud af, at betalingsformularen trækker penge, men at ordrerne aldrig kommer igennem. Eller at databasen med kundernes telefonnumre er åben for hele internettet.

Jeg lancerede også mine første projekter på den måde: ting, der så ud til at virke, kom med overraskelser for rigtige brugere. Nu gennemgår jeg projektet med den samme tjekliste, før jeg viser noget til andre. Jeg læser ikke en eneste linje kode imens – jeg kom ikke for at gøre det, og det gjorde du sikkert heller ikke.

Og det er ikke paranoia. Anthropic analyserede 400.000 Claude Code-sessioner: I løbet af syv måneder faldt andelen af arbejdet, der blev brugt på at rette ødelagt kode, fra 33 % til 19 %. Den faldt – men forsvandt ikke. Hver femte session handler stadig om at ”rette det, AI ødelagde”.

Det er ikke længere selve kodningen, der er flaskehalsen. Det afgørende nu er, hvor godt du forstår opgaven, og hvor godt du kan kontrollere resultatet.

Yderligere materiale om opsætning af værktøjer findes i Ailoot-dokumentationen.

Hvorfor kontrollere AI-genereret kode, hvis den allerede virker?#

AI skriver kode, der består det første blik. Den kører, skærmen vises, og demoen ser overbevisende ud. Men en lancering fortæller dig ikke, om pengene beregnes korrekt, om databasen er eksponeret mod omverdenen, eller om det hele bryder sammen, når bruger nummer hundrede dukker op.

Tallene underbygger det. Benchmarken FrontierCode undersøgte i juni 2026, hvor klar AI-genereret kode var til virkeligt arbejde uden ændringer. Selv for de bedste modeller på de sværeste opgaver lå andelen på omkring 13 %. Med andre ord skal det meste AI-genererede kode på alvorlige opgaver finpudses manuelt, før du kan stole på den.

Den gode nyhed er, at alle kan udføre kontrollen. Her er Anthropics konklusion fra de samme 400.000 sessioner:

Din fordel i forhold til enhver programmør, du hyrer, er, at du forstår din opgave. Kontrol handler også om forståelse; du behøver ikke læse kode for at gøre det. Kontrollerne nedenfor er præcis den slags, du kan udføre selv uden besvær.

Hvad kan faktisk gå galt med AI-genereret kode?#

Før du kontrollerer, er det en hjælp at vide, hvad du leder efter. AI-genereret kode har fem typiske problemer, og du kan opdage dem alle uden at læse kode – ved at se på, hvordan projektet opfører sig.

Næste punkt er syv kontroller i rækkefølge. De første fanger problemer med, at det ikke virker, eller virker forkert; de midterste dækker sikkerhed og opdigtede ting; de sidste er sikkerhedsforanstaltninger før offentliggørelse. Gå dem helst igennem i rækkefølge: Hver kontrol bygger på, at den foregående er gennemført.

Kontrol 1: Bed AI forklare sin kode med almindelige ord#

Du beskrev opgaven med ord. AI oversatte den til kode. Betydning kan gå tabt mellem de to trin: AI kan have forstået dig anderledes, udfyldt ting på dine vegne eller sprunget over, hvor gærdet er lavest. Du kan fange uoverensstemmelsen uden at læse kode – bed den blot beskrive med almindelige ord, hvad den gjorde.

Forklar præcist med almindelige ord, uden kode, hvad du lige har gjort:

hvilken opgave denne kode løser

hvad der sker, når en bruger klikker på knappen eller sender formularen

hvor dataene gemmes, og hvem der har adgang til dem

hvad der kan gå galt, og i hvilken situation

Skriv, som om du forklarede det til en person, der aldrig har programmeret. Hvis der er noget, du ikke er sikker på er korrekt, så sig det tydeligt.

Læs svaret, og sammenlign det med det, du havde i tankerne. Hvis det stemmer, går du videre. Hvis AI ”vrøvler”, bliver forvirret i sin egen forklaring eller beskriver noget andet end det, du bad om, betyder det, at den ikke helt forstår, hvad den har bygget. Bed den om at revidere det med en præcisering i stedet for at stole på dens ord.

Hvis AI jævnligt gør noget andet end det, du bad om, skyldes problemet ofte, hvordan opgaven blev formuleret, ikke selve modellen. Jeg har en separat gennemgang af hvorfor Claude ikke gør det, du bad om.

Kontrol af AI's output er en del af kontekstteknik: Du styrer både det, du giver AI som input, og hvordan du evaluerer resultatet som output. Værktøjskassen omfatter en AI-klon, en Second Brain og Context Engineering. Derefter holder Claude op med at være en ”hallucinerende assistent” og bliver et værktøj, du faktisk kan betro et projekt.

Kontrol 2: Gennemgå scenarierne, som en rigtig bruger ville gøre#

En AI-demo følger altid den perfekte vej: korrekte data, ét klik, alt går godt. En rigtig bruger opfører sig ikke sådan. Brugeren laver fejl, klikker på det forkerte eller indtaster en emoji i telefonfeltet. Din opgave er at gennemgå projektet, som brugeren ville gøre.

1. Gennemfør hovedscenariet fra start til slut

   Gør det, projektet er lavet til: registrér dig, bestil noget, send en forespørgsel. Gå hele vejen til slutningen, ikke kun halvvejs.

2. Kontrollér betalingen separat og i praksis

   Hvis projektet modtager penge, skal du selv foretage en betaling på minimumsbeløbet i testtilstand. Kontrollér, at ordren oprettes, status ændres, og der sendes en e-mail til dig og kunden. En betaling, der ”går igennem”, uden at der oprettes en ordre, er en klassisk, skjult fejl.

3. Prøv bevidst at få tingene til at gå galt

   Lad felter stå tomme. Indtast bogstaver, hvor der forventes tal. Klik på ”Send” to gange i træk. Upload en fil i forkert format. Et godt projekt siger høfligt ”det kan du ikke”; et dårligt projekt går ned eller sluger dataene uden at sige noget.

4. Åbn det på en telefon

   Halvdelen af dine brugere kommer fra en telefon. Kontrollér, at layoutet ikke er faldet fra hinanden, og at de samme knapper virker dér.

Giv AI alt det, du fandt, i én samlet liste: ”Her er det, der gik galt i disse trin; ret det, og forklar, hvorfor det skete.” Tag ikke ét problem ad gangen – giv den listen, så AI kan se helheden og har mindre risiko for at ødelægge én ting, mens den retter en anden.

Kontrol 3: Spørg AI om sikkerhed – her er en prompt#

En ødelagt knap er straks synlig. Et sikkerhedshul er det ikke: Projektet fortsætter, som om intet er galt, indtil nogen udnytter det. De mest almindelige problemer i vibe-coded projekter er hemmelige nøgler skrevet direkte i koden, en database eksponeret på internettet og formularer, der lader nogen indsende skadeligt input. AI kan finde alt dette, hvis du spørger direkte.

Gennemgå dette projekt for sikkerhedsproblemer, og forklar hvert fund med almindelige ord uden fagsprog. Gennemgå denne liste:

Undersøg, om hemmelige nøgler, adgangskoder eller tokens er skrevet direkte i koden. Private hemmeligheder må kun bruges på serveren med lokal hemmelighedskonfiguration som .env udelukket fra git. En .env-fil og .gitignore forhindrer ikke frontend-/public-variabler i at indgå i et browserbuild. Undersøg faktisk JavaScript, sourcemaps, HTML og netværkssvar leveret til klienten, og verificér, at private nøgler mangler.

Undersøg, om databasen er eksponeret på internettet, og hvem der har adgang til den.

Undersøg, om input kan ødelægge formularerne: injektioner i databaseforespørgsler eller ekstra kode i tekstfelter.

Hvad sker der, hvis en bruger sender ondsindede data?

Undersøg, om interne sider eller administrationspanelet er tilgængelige uden en adgangskode.

For hvert punkt skal du sige, om der er et problem, give et tydeligt eksempel på risikoen og forklare, hvordan det løses. Start med det farligste problem.

Kontrollér også, at dit projekt ikke blindt gør, hvad det end modtager udefra. Det kaldes indirekte prompt injection: En kommando skjules i en e-mail, en kommentar eller en andens fil, og din AI-agent følger den, fordi den forveksler den med en opgave. Hvis projektet læser eksterne data og handler på dem, så spørg AI, hvad der ville ske, hvis dataene indeholdt en skjult instruktion.

Det er et omfattende emne, og én prompt kan ikke dække det fuldstændigt. Hvis projektet håndterer penge eller kunders personoplysninger, så læs den separate guide om sikkerhed ved vibe-coding.

Kontrol 4: Fandt AI på biblioteker eller data?#

AI skriver selvsikkert ting, der ikke findes. Den kan tilføje et bibliotek med et plausibelt navn, som faktisk ikke findes. Den kan efterlade testpladsholdere i projektet: et produkt kaldet ”Example”, e-mailadressen example@example.com eller fyldtekst i stedet for rigtigt indhold. Det er let at overse i en demo, men pinligt eller ødelæggende for en rigtig bruger.

Du kan fange det i to trin. Spørg først direkte:

Gennemgå projektet, og kontrollér ærligt:

Findes alle de eksterne værktøjer og biblioteker, du har tilføjet, faktisk, og kan de installeres korrekt? Har du fundet på noget?

Er der stadig testpladsholdere, eksempler eller fyldtekst i stedet for rigtige data?

Er alle links, adresser og kontaktoplysninger i projektet ægte og ikke pladsholdere?

Lav en liste over det, du fandt, og foreslå, hvad det skal erstattes med.

Kør derefter bare projektet, og se det igennem. Et opdigtet bibliotek giver næsten altid en fejl ved opstart. Og pladsholdere er lette at få øje på: Hvis siden siger ”Product 1”, har du ikke erstattet dem.

Opdigtede biblioteker udgør en særlig fare, fordi angribere bevidst registrerer værktøjer med navne, som AI kan finde på. Installerer du et af dem, kommer andres kode ind i dit projekt. Derfor bør du tage spørgsmålet ”findes dette bibliotek overhovedet?” alvorligt – det handler direkte om sikkerheden i dit projekt.

Kontrol 5: Få en anden model til at kontrollere den første#

AI har en ubehagelig egenskab: Den er enig. Spørg ”er alt i orden her?”, så bekræfter den, at alt er i orden, fordi den tilpasser sig det svar, den forventer. Det kaldes AI-sycophancy, og jeg har skrevet om det særskilt. En samtalepartner af den slags er næppe kritisk over for sit eget arbejde.

Løsningen er enkel: Få en ny vurdering. Åbn en ny session, eller brug en anden model, og giv den projektet til kontrol med den samme prompt fra kontrol 3, tilføjet: ”En anden AI har skrevet denne kode; find dens svage punkter.” En frisk model er ikke bundet til den tidligere samtale og er mere tilbøjelig til at påpege problemer.

1. Åbn en ren session, eller brug en anden model

   Brug en anden model eller den samme i et nyt vindue uden opgavehistorik.

2. Giv den projektet og den rette indramning

   Sig tydeligt: ”En anden AI har skrevet denne kode; din opgave er at finde fejl og risici, ikke at rose den.” Det dæmper tendensen til at give brugeren ret.

3. Sammenlign de to vurderinger

   Hvis begge er enige, har de sandsynligvis ret. Hvis de er uenige, så undersøg det punkt – det er dér, det bliver interessant.

Det er præcis det, der sker i branchen lige nu: AI skriver, AI kontrollerer, og den endelige beslutning forbliver hos et menneske. Du kan ikke overlade det til modellen – det er dit job.

Kontrol 6: Hvordan kan du rulle tilbage, hvis en ændring ødelægger noget?#

Kontrollerne på denne liste fører ofte til ændringer, og ændringer ødelægger nogle gange det, der virkede. For at undgå, at det bliver en katastrofe, skal du gemme den fungerende version i git før hver runde med rettelser. Det er som at gemme et spil: Hvis du ødelægger noget, indlæser du det seneste gemte punkt.

Du behøver ikke læse kode for at gøre dette. Bed blot AI: ”Gem den nuværende fungerende version i git med en tydelig etiket, før du ændrer noget.” Og hvis alt går galt efter ændringerne: ”Gendan projektet til den tidligere gemte version.”

Hvis git stadig er ukendt territorium, har jeg to guider til dig: sådan ruller du ændringer tilbage i Claude Code og hvad du skal gøre, hvis AI slettede din database. Den anden er til, når det allerede er for sent at rulle tilbage, men du stadig kan gendanne dataene.

Kontrol 7: Hvad skal du kontrollere til sidst før offentliggørelse?#

De første seks kontroller handler om, hvad koden gør. Den syvende handler om, hvorvidt projektet er klar til at møde mennesker. Det er her, folk oftest snubler: Projektet virker, men de glemte at skifte betaling fra testnøglen til live-nøglen, så de første kunder betaler ”for sjov”.

1. Betaling: fra test til live

   Hvis du tager imod betalinger, skal du kontrollere, at betalingssystemets live-nøgle er tilsluttet og ikke testnøglen. Foretag én rigtig betaling på minimumsbeløbet, og refundér den til dig selv.

2. Hemmelighederne ligger, hvor de skal

   Spørg AI: “Bruges private nøgler kun på serveren med .env udelukket fra git? Indeholder det faktiske browserbuild eller et klientsvar en privat nøgle, også gennem frontend-/public-variabler eller sourcemaps?” Kontrollér byggede filer og browserens netværkssvar, ikke kun kildefilen .env. Git-udelukkelse holder ikke en værdi ude af en frontendpakke.

3. Tag sikkerhedskopi af dataene

   Sørg for, at databasen automatisk gemmes et sted. Hvis dit projekt kører på din egen server, forklarer jeg, hvad du skal gøre ved offentliggørelsen i Coolify-guiden.

4. Offentliggørelsen virker på andre enheder end din egen

   Åbn projektet på din telefon via et eksternt link, ikke kun på din egen computer. Noget, der virker lokalt, virker ikke altid efter offentliggørelsen.

Gå alle fire punkter igennem, så kan du vise projektet til andre med ro i sindet. Hvis noget ikke holder, er det bedre at bruge en halv time nu end at håndtere utilfredse kunder senere.

Hvad hvis kontrollen tager for lang tid – skal du bare stole på AI?#

Jeg forstår fristelsen. Kontrol føles kedeligt og ”ikke det, jeg fik AI til”. Men det er dig, ikke modellen, der er ansvarlig for resultatet. AI har intet omdømme og mærker ingen konsekvenser: Den producerede koden og glemte alt om den. Det bliver dig, der skal svare en kunde, hvis betaling ikke gik igennem.

Skaberen af Claude Code anlægger et endnu bredere perspektiv:

Kodning er ikke længere flaskehalsen – AI tog sig af den. Værdien ligger nu et andet sted: i at forstå opgaven og kontrollere resultatet. Det er din styrke – du ved bedre end nogen ekstern udvikler, hvad resultatet skal være for din kunde.

Hvorfor er kontrol en færdighed og ikke en engangsopgave?#

Disse syv kontroller er minimumskravet for at skelne mellem ”jeg lancerede det og håber” og ”jeg lancerede det og ved, at det virker”. Gå dem igennem én gang, så fanger du allerede de fleste overraskelser, før dine kunder gør det.

Derefter bliver det en vane. Giv AI den rette kontekst som input, og kontrollér resultatet som output, så bliver hvert nyt projekt færdigt hurtigere, fordi du ikke starter fra bunden.

Find yderligere materiale om at arbejde med værktøjer i Ailoot-dokumentationen.