Forstå den kode AI skriver for dig — ellers er du ikke en udvikler

At bygge en app med AI tager 20 minutter. Jeg ved det — jeg har gjort det. At forstå hvad den byggede tager længere. Og det er præcis den forskel, der afgør om du er en udvikler — eller bare en person med adgang til en chatbot.

Her er den hårde sandhed: kodegenerering er i praksis blevet gratis. Enhver person med en browser kan prompte sig til noget der ligner en fungerende webapp. Det er ikke længere en kompetence.

Det der er en kompetence: at læse outputtet, forstå arkitekturen, vurdere kvaliteten, og vide hvornår AI'en tager fejl.

Hvorfor "det virker" ikke er godt nok

Forestil dig dette scenarie: Du beder AI'en om at bygge en login-flow. Den giver dig 200 linjer kode. Du kører det. Det virker.

Men:

Hashes den passwords korrekt, eller bruger den MD5?
Validerer den input på serversiden, eller kun i browseren?
Håndterer den race conditions i sessions?
Er der SQL injection-muligheder i queries?

Hvis du ikke kan svare på de spørgsmål uden at spørge AI'en igen, har du et problem. Ikke i dag — men den dag noget går galt i produktion, og du skal debugge kode du aldrig forstod.

Teknik 1: Bed AI'en om at forklare sit eget output

Det vigtigste prompt du kan skrive efter kodegenereringen:

Forklar den kode du lige genererede. For hver funktion og hvert arkitekturvalg:
1. Hvad gør den præcist?
2. Hvorfor valgte du denne tilgang frem for alternativer?
3. Hvilke trade-offs er der?
4. Hvad ville gå galt hvis vi fjernede eller ændrede denne del?

Det er ikke et spørgsmål om tillid. Det er en læringsproces. Jeg gør det selv — også når jeg er 90% sikker på at koden er korrekt. De 10% af gangene hvor forklaringen afslører noget jeg ikke havde tænkt over, er det hele værd.

Teknik 2: Brug AI som arkitektur-reviewer

Før du accepterer et stykke genereret kode, kør dette prompt:

Gennemgå denne kode som en senior arkitekt. Besvar:

1. ARKITEKTUR: Er strukturen skalerbar? Følger den etablerede patterns?
2. SIKKERHED: Er der input validation, auth-huller, eller injection-risici?
3. PERFORMANCE: Er der N+1 queries, unødvendige re-renders, eller memory leaks?
4. VEDLIGEHOLDELSE: Vil en ny udvikler forstå denne kode om 6 måneder?
5. ALTERNATIVER: Hvilke andre tilgange ville du overveje, og hvorfor fravalgte du dem?

<kode>
[indsæt den genererede kode]
</kode>

Du får en code review der tager 30 sekunder — og som tvinger dig til at forholde dig til kvalitet, ikke bare funktionalitet.

Teknik 3: "Dokumentér som om jeg er ny på teamet"

Bed AI'en om at generere dokumentation der forklarer koden til en ny teammedlem:

Skriv dokumentation for denne kode som om den skal onboarde en ny udvikler på teamet.
Inkluder:
- Overordnet arkitekturoverblik (hvad er ansvarsfordelingen?)
- Dataflow (hvad sker der fra request til response?)
- Vigtige designbeslutninger og hvorfor de er taget
- Kendte begrænsninger og teknisk gæld
- Afhængigheder og deres formål

Skriv det som intern dokumentation, ikke som en tutorial.

Resultatet er ikke bare dokumentation — det er en forståelsestest. Hvis forklaringen afslører noget du ikke vidste, har du lige fundet et videnshul.

Teknik 4: Linjeannotationer — den dybeste forståelse

For kritisk kode, bed om inline-kommentarer der forklarer hvorfor, ikke hvad:

Tilføj kommentarer til denne kode. Ikke "hvad" den gør (det kan jeg læse),
men "hvorfor" den gør det. Forklar:
- Hvorfor denne datastruktur?
- Hvorfor denne rækkefølge af operationer?
- Hvorfor dette error handling pattern?
- Er der edge cases der ikke er håndteret?

Det tvinger dig til at læse koden linje for linje. Det er langsomt. Det er meningen.

Teknik 5: "Bryd den" — adversarial testing med AI

Den mest undervurderede teknik: Bed AI'en om at angribe sin egen kode.

Du har lige genereret denne kode. Skift nu rolle: Du er en erfaren pentester og
code reviewer. Find:
1. Mindst 3 måder denne kode kan fejle i produktion
2. Mindst 2 sikkerhedshuller
3. Edge cases der ikke er håndteret
4. Hvad sker der under load (100x normal trafik)?

Vær grundig og ærlig — lad være med at beskytte dit eget output.

AI'en er overraskende god til at finde fejl i sin egen kode, når du eksplicit beder den om det.

Workshop-øvelse: Understand-Before-You-Ship

Denne øvelse bruger vi i Nordic Logic workshops. Den tager 30 minutter og ændrer hvordan teams arbejder med AI:

Trin 1: Generer (5 min)

Bed AI'en om at bygge en konkret feature — f.eks. en REST endpoint med auth, validation og database-kald.

Trin 2: Forklar (10 min)

Uden at kigge på koden, forklar til din makker:

Hvad gør koden?
Hvilke design decisions er taget?
Hvad er de potentielle problemer?

Kan du ikke forklare det? Så forstår du det ikke. Gå tilbage.

Trin 3: Review (10 min)

Brug Teknik 2 og 5 ovenfor. Kør en AI-assisteret code review og adversarial test. Sammenlign AI'ens fund med det du selv spottede i Trin 2.

Trin 4: Dokumentér (5 min)

Generér dokumentation med Teknik 3. Læs den. Er der noget der overrasker dig? Det er præcis de steder du skal fokusere din læring.

Den nye udviklerkompetence

Fremtidens udvikler er ikke den der skriver mest kode. Det er den der:

Forstår hvad AI'en genererer — og kan forklare det til andre
Vurderer kvaliteten — sikkerhed, performance, vedligeholdelse
Redigerer med overblik — ved hvad der skal ændres og hvorfor
Lærer af outputtet — bruger hver generering som en undervisningsmulighed

AI erstatter ikke udviklere. AI erstatter udviklere der ikke forstår hvad AI'en laver.

At generere kode er ikke en færdighed mere. At forstå kode er den vigtigste færdighed du nogensinde har haft som udvikler — og AI er faktisk det bedste læringsværktøj du har til rådighed.

Brug den til at forklare, reviewe, dokumentere og udfordre. Ikke bare til at generere.

Hver eneste gang du accepterer kode du ikke forstår, bygger du teknisk gæld — ikke i kodebasen, men i dit eget hoved.

Workshop-øvelsen ovenfor er et uddrag af det vi kører i Nordic Logic workshops. Vil I prøve den med jeres eget team og jeres egen kodebase? Lad os tage en snak.