Stop med bare at copy/paste AI-kode – du snyder kun dig selv

Du bruger din AI-kodeassistent forkert

Mange begynder at lære programmering med en AI-kodeassistent åben i et faneblad ved siden af. Cursor, ChatGPT, Copilot. Du spørger, den spytter kode ud, du copy/paster. Det virker. Lige indtil det ikke gør.

Hvis du ikke forstår koden, har du ikke lært noget. Så har du bare fået en midlertidig tryllestav, der nogle gange eksploderer i hånden på dig.

Jeg vil vise dig en måde at bruge en AI kodeassistent til programmering, hvor du både får hjælp og faktisk lærer at kode. Og hvor du har en simpel QA-tjekliste til at fange de værste AI-fejl, inden de lander i din repo.

1. Vælg din rolle: Tutor-mode eller generator-mode

Hvis du vil have noget ud af AI som begynder, skal du bevidst skifte mellem to “modes” i hovedet, hver gang du åbner din AI-assistent:

1. AI som tutor – når du vil forstå et koncept eller et stykke kode.
2. AI som kode-generator – når du bare vil have et udkast, du selv kan arbejde videre på.

AI som tutor: Brug den som den tålmodige underviser, du aldrig fik

Tutor-mode er der, hvor du lærer mest. Her er opgaven ikke “skriv koden for mig”, men “forklar mig, hvad der foregår”.

Eksempel på tutor-prompt:

Jeg er begynder i JavaScript.
Forklar mig hvad følgende funktion gør, linje for linje:

function sum(arr) {
  return arr.reduce((total, value) => total + value, 0);
}

Brug et simpelt eksempel med et tal-array og vis hvert trin.

Her beder du ikke om ny kode. Du beder om en forklaring. Det er en helt anden måde at bruge AI på.

Du kan også bruge tutor-mode til at få omskrevet en alt-for-avanceret AI-løsning til noget, du faktisk kan læse:

Du skrev denne funktion til mig tidligere, men den er for avanceret til mit niveau.

1) Forklar kort hvad den gør.
2) Skriv en simplere version uden avancerede patterns.
3) Kommenter hver linje i den simple version.

AI som kode-generator: Acceptér at du skal rydde op bagefter

Nogle gange gider du bare ikke skrive boilerplate selv. Fair nok. Det gør jeg heller ikke.

Generator-mode er ok, hvis:

• Det handler om kedelig standardkode (CRUD-endpoints, simple formularer).
• Du allerede kender konceptet, men vil spare tid.
• Du er bevidst om, at koden kun er et udkast, ikke sandheden.

Problemet opstår, når generator-mode bliver standarden, også når du ikke forstår emnet.

En sund vane: Hver gang du får AI til at skrive et stykke kode, skal du mindst gøre tre ting:

1. Få det forklaret i sætninger, du kan forstå.
2. Få AI til at skrive 2-3 testcases.
3. Spørge: “Hvad kan gå galt med denne løsning?”

Resten af artiklen handler stort set om de tre ting.

2. Fem prompt-skabeloner der tvinger forklaring frem

Hvis du bare skriver “skriv en funktion der gør X”, får du oftest flot, men alt for smart kode, og en halv-løs forklaring bagefter.

Her er fem prompt-typer, der presser din AI til at undervise dig i stedet for at imponere dig.

1) “Forklar som til en begynder” med krav til format

Forklar dette som til en begynder, der kun kender helt basal Python.

1) Giv en kort overordnet forklaring (max 3 sætninger).
2) Forklar linje for linje.
3) Giv et konkret input-eksempel og vis output.

Det vigtige her er strukturen: du tvinger AI til at svare i trin, og ikke i én lang tekstklump.

2) “Vis en simplere version”

AI har en tendens til at bruge avancerede mønstre, frameworks og syntaks. Du kan bede om en nedskaleret version.

Din løsning er for avanceret til mit niveau.

Lav en ny version med følgende krav:
- Ingen arrow functions
- Ingen async/await
- Ingen eksterne biblioteker
- Maks 15 linjer

Forklar bagefter, hvad du har gjort simplere.

3) “Vis en alternativ løsning”

Hvis du kun ser én løsning, lærer du meget lidt om valgmulighederne.

Skriv 2 forskellige måder at løse denne opgave på i JavaScript:

Opgave: En funktion, der tager en liste af tal og returnerer gennemsnittet.

1) En helt simpel, nybegynder-venlig version.
2) En mere "moderne" version med array-metoder.

Forklar forskellen på de to løsninger og hvornår du ville bruge hvilken.

4) “Peg på fejl” i din egen kode

En af de bedste måder at lære på er at få feedback på din egen kode, ikke bare få ny.

Her er min egen løsning på opgaven.

1) Find de fejl du kan.
2) Forklar hvad der går galt.
3) Foreslå konkrete ændringer, men forklar dem uden at skrive hele løsningen om.

Tricket her er punkt 3. Hvis du bare beder om en “rettet version”, lærer du mindre end hvis du kun får patches.

5) “Test og edge cases”

AI er ret god til at opfinde eksempler, og du kan bruge det til at træne din egen test-tænkning.

Du har skrevet denne funktion til mig:
[indsæt funktion]

1) Skriv 3 testcases: et typisk input, et kanttilfælde og et invalidt input.
2) Forklar hvorfor du har valgt netop de 3.
3) Peg på mindst 2 situationer, hvor funktionen kan fejle i praksis.

3. QA-tjekliste til AI-kode før du committer

Her kommer den del, jeg selv ville kopiere til min notes-app.

Forestil dig, at du har fået AI til at skrive en funktion, en komponent eller et lille API-endpoint. Inden du pusher det til GitHub, løber du denne tjekliste igennem.

Trin 1: Kør koden i små skridt og få AI til at forklare hver ændring

Hvis du bare smider hele AI-blokken ind i dit projekt og krydser fingre, bliver det svært at debugge bagefter.

Bed i stedet AI om at hjælpe dig med en step-by-step indføring.

Del din løsning op i 3-5 mindre trin.
For hvert trin:
- Forklar hvad der bliver tilføjet.
- Forklar hvordan jeg kan teste, at netop det trin virker.

Start med trin 1 nu.

Eksempel med en simpel form-handler i JavaScript:

1. Først kun hente input-værdi og logge den.
2. Sidenhen lave simpel validering.
3. Til sidst sende den til et API.

Du kan kopiere trin 1 ind i dit projekt, teste, forstå det, og så først derefter gå videre til trin 2.

Trin 2: Skriv 3 minimale testcases

Du behøver ikke et kæmpe test-setup for at tænke i test. Bare nogle simple input/forventet output-eksempler.

Eksempel: Du har en funktion i Python, der skal formatere et brugernavn:

def normalize_username(name: str) -> str:
    # AI-skrevet magi her
    ...

Spørg AI:

For funktionen normalize_username, skriv 3 konkrete eksempler:

1) Et typisk brugernavn.
2) Et kanttilfælde.
3) Et ugyldigt input.

Vis: input -> forventet output og kort begrundelse.

Du får noget i stil med:

1) "Lasse" -> "lasse"
   - Typisk input, skal bare gøres lowercase.

2) "  Lasse_123  " -> "lasse_123"
   - Kanttilfælde med whitespace og blandede tegn.

3) "!!!" -> ValueError / fejlbesked
   - Ugyldigt input uden gyldige tegn.

Når du ser dem, kan du:

• Manuelt teste dem i din REPL / browser-konsol.
• Begynde at omsætte dem til små automatiske tests senere.

Trin 3: Læs fejlbeskeder ordentligt og brug AI som debug-partner

En klassisk fælde: Du kører koden, får en fejl, kopierer hele fejlen ind i AI og skriver “fix det”.

Prøv i stedet denne struktur:

Jeg får denne fejl:
[indsæt fejl]

1) Forklar hvad fejlen betyder med dine egne ord.
2) Peg på den mest sandsynlige årsag i min kode.
3) Giv mig 2-3 mulige debug-trin jeg selv kan prøve.
4) Hvis du foreslår kodeændringer, så forklar præcis hvorfor.

Hvis du stiller det sådan op, træner du din egen fejllæsnings-muskel, i stedet for bare at være en menneskelig copy/paste-robot.

4. Typiske AI-fælder i webprojekter

Webprojekter er et sted, hvor AI-løsninger tit ser flotte ud på overfladen, men vælter ved første møde med virkeligheden.

Her er nogle mønstre, jeg ser igen og igen.

CORS: Når browseren siger nej

CORS-fejl (Cross-Origin Resource Sharing) er nærmest en rite of passage i webudvikling.

AI giver tit svar i stil med “bare slå CORS fra” eller “tillad *”. Det er sjældent en god idé.

Hvis du får en CORS-fejl i konsollen, så gør følgende:

1. Læs fejlbeskeden i browserens devtools.
2. Tjek dokumentationen for CORS, for eksempel på MDN om CORS-fejl.
3. Spørg AI specifikt: “Jeg vil løse denne CORS-fejl på serversiden, ikke ved at slå sikkerhed fra. Hvad er en sikker løsning i [dit framework]?”

Det vigtige: Løs det ved kilde (server) i stedet for at smøre en omvej på i frontend.

Auth og tokens: AI elsker at lække hemmeligheder

Hvis du beder AI om hjælp til login, JWT tokens eller API-nøgler, får du ofte kodeeksempler, hvor hemmeligheder ligger direkte i frontend-koden eller i repoet.

Et par simple huskeregler:

• API-nøgler og tokens skal som udgangspunkt ikke ligge i JavaScript på klientsiden.
• Brug miljøvariabler (env vars) på serveren, og hent dem derfra.
• Hvis AI foreslår at “gemme token i localStorage”, så spørg: “Hvilke sikkerhedsrisici er der ved det, og hvad er alternativerne?”

Du kan også søge mere struktureret viden i stedet for kun at stole på AI. For eksempel på artikler om sikkerhed og deployment på Coding Class eller andre faglige blogs.

Env vars: “Bare lav en .env-fil” er ikke hele historien

AI er glad for sætninger som:

Just store your API key in a .env file and you're good to go.

Problemet er, at den sjældent forklarer:

• Hvordan .env-filen ikke skal committes (gitignore).
• Hvordan miljøvariabler håndteres i dit konkrete hosting-setup.
• At frontend-builds typisk ikke kan læse server-side env vars direkte.

Når du får sådan et svar, så spørg specifikt:

Jeg bruger [din hosting, fx Vercel, Netlify, Railway].

Forklar trin for trin:
1) Hvor jeg skal konfigurere miljøvariabler.
2) Hvordan jeg læser dem i backend-koden.
3) Hvordan jeg sikrer, at de ikke ender i frontend-koden.

Build/deploy: “It works on my machine” med AI-twist

AI kan fint skrive kode, der kører lokalt, men glemmer ofte detaljer om build-scripts, versionskrav og runtime-miljø.

Når du beder AI om hjælp til et projekt, så inkludér altid:

• Hvilket framework (React, Svelte, Django, Flask osv.).
• Hvordan du kører projektet nu (npm run dev, python main.py osv.).
• Hvor du vil deploye det (Vercel, Netlify, en VPS osv.).

Og stil et eksplicit spørgsmål:

Hvilke ekstra trin skal jeg tage for at få denne løsning til at virke på [min hosting], ikke kun lokalt?

Inkludér:
- Build-scripts
- Miljøvariabler
- Eventuelle konfigurationsfiler

5. Sådan dokumenterer du AI-hjælp uden at det virker suspekt

Flere uddannelser og arbejdspladser spørger nu direkte: “Har du brugt AI til denne opgave?”.

Det behøver ikke være pinligt at sige ja. Det bliver først et problem, hvis du ikke kan forklare din egen kode.

En simpel måde at være transparent på er at skrive en kort note i dit README.

Eksempel på README-afsnit om AI-brug

Du kan lave en sektion som:

## Brug af AI-værktøjer

I dette projekt har jeg brugt en AI-kodeassistent til:
- At få forslag til struktur for API-endpoints.
- At omskrive kode til et simplere niveau.
- At generere forslag til testcases.

Alt AI-genereret kode er blevet gennemgået, tilpasset og testet manuelt.
Kommentarer i koden afspejler min egen forståelse.

Hvis du vil være ekstra tydelig, kan du tilføje små kommentarer i koden som:

// Inspireret af AI-forslag, tilpasset og forenklet

Det vigtige er ikke at pege fingre af AI, men at vise, at du har været aktiv udvikler, ikke bare mellemstation.

6. Mini-øvelse: Brug AI som assistent, ikke som autopilot

Nu tager vi en lille øvelse, du faktisk kan lave på 10-15 minutter med din egen AI-assistent.

Målet: Få AI til at skrive en funktion, og brug så QA-tjeklisten til at gøre koden til din kode.

Step 1: Bed om en simpel funktion

Brug fx Python og skriv:

Skriv en Python-funktion `format_price`, der tager et tal i kroner
og returnerer en tekststreng med to decimaler og " kr" bagefter.

Eksempel: 12 -> "12,00 kr".

1) Skriv funktionen.
2) Forklar den linje for linje.

Step 2: Tving simplificering

Hvis svaret bliver for smart, så følg op:

Simplificer funktionen så meget som muligt.

Ingen avancerede biblioteker, ingen unødvendige trin.
Forklar forskellen på den første og denne version.

Step 3: Bed om testcases

Skriv 3 testcases for `format_price`:

1) Et helt tal.
2) Et tal med decimaler.
3) Et invalidt input (fx tekst).

Vis: input -> forventet output eller fejl.

Kør dem selv i din Python-REPL eller i et lille script. Justér funktionen, hvis noget ikke opfører sig, som du vil.

Step 4: Spørg efter fejl og risici

Peg på mindst 3 begrænsninger eller potentielle fejl ved denne `format_price` funktion.

Foreslå forbedringer, men forklar hvorfor, før du viser koden.

Nu begynder du at tænke mere som en udvikler: Hvad kan gå galt, hvad sker der med meget store tal, hvad med negative priser osv.

Step 5: Skriv din egen kommentar

Til sidst skriver du en kommentar over funktionen med dine egne ord:

def format_price(amount: float) -> str:
    """
    Min egen forklaring:
    - Tager et tal (kroner)
    - Runder til 2 decimaler
    - Bruger komma som decimalseparator
    - Tilføjer " kr" bagefter
    """
    ...

Hvis du kan skrive den kommentar uden at kigge på AI-svaret, har du forstået mere end 90 % af begyndere, der bare trykker copy/paste.

7. En hurtig arbejdsgang du kan bruge på alle AI-svar

Til sidst får du en destilleret 10-minutters arbejdsgang, du kan køre hver gang du bruger en AI kodeassistent til programmering.

1. Bed om løsning + forklaring
   Ikke kun “skriv funktionen”, men også “forklar linje for linje”.
2. Simplificér
   Bed om en simplere version, tilpasset dit niveau.
3. Testcases
   Få AI til at skrive 3 input/output-eksempler og kør dem selv.
4. Risici
   Spørg: “Hvad kan gå galt, og hvilke edge cases overser denne løsning?”.
5. Din egen note
   Skriv en kort kommentar eller README-tekst med din forståelse.

Hvis du vil bygge videre på det her, kan du udforske flere artikler om webudvikling og tests på Coding Class og for eksempel læse om forskellen på axios vs fetch for at forstå, hvad AI egentlig foreslår, når den smider HTTP-klienter i hovedet på dig.

Mit vigtigste råd: Brug AI som den kloge makker ved siden af, ikke som autopilot. Hvis du ikke kan forklare din egen kode, er den ikke din endnu.