Sådan kommer du i gang med programmering med AI

At komme i gang med AI-assisteret programmering handler ikke først og fremmest om at finde den perfekte model. Det handler om at lære at give værktøjet nok kontekst, afgrænse opgaven, gennemgå resultatet og undgå, at AI’en laver en lille ændring om til en omskrivning.

Den største fejl er at behandle AI som en erfaren udvikler, der allerede forstår din kodebase. Det gør den ikke. Den kan læse filer, aflæse mønstre og lave nyttige ændringer, men den har brug for praktiske instruktioner og et tydeligt workflow.

Start med den rigtige type opgave

De bedste første opgaver er nyttige, men afgrænsede. Start ikke med at bede AI om at genopbygge applikationen, redesigne frontend eller migrere hele backend.

Start med arbejde, hvor du kan verificere resultatet:

• Forklar en ukendt fil
• Skriv en lille utility-funktion
• Tilføj validering til en eksisterende formular
• Konverter én komponent ad gangen
• Forbedr en fejlbesked
• Tilføj tests for eksisterende adfærd
• Gennemgå et pull request for regressioner

Det betyder noget, fordi AI kan skrive overbevisende kode, der stadig er forkert. En afgrænset opgave giver et lille sæt ændringer, et tydeligere review og en bedre fornemmelse af, hvordan værktøjet opfører sig.

Brug AI som sparringspartner, ikke autopilot

AI er nyttigt til planlægning, implementering, debugging, refaktorering, test og review. Det erstatter ikke forståelsen af, hvad der faktisk skal i produktion.

Et godt workflow er:

1. Bed AI’en undersøge de relevante filer og forklare den nuværende struktur.
2. Bed om en kort implementeringsplan, før der ændres kode.
3. Godkend eller korriger planen.
4. Lad AI’en lave den mindste nyttige ændring.
5. Gennemgå ændringerne selv.
6. Kør tests, type checks, linting eller build.
7. Bed en anden AI-gennemgang lede efter skjulte risici.

Det workflow er langsommere end bare at acceptere forslag, men det er hurtigere end at debugge en sikker fejl, efter den er kommet i produktion.

Brug GitHub før du lader AI ændre kode

Før AI ændrer rigtig kode, bør projektet ligge i version control. Git er det vigtige. GitHub er det almindelige praktiske valg, fordi du får branches, pull requests, tydelige visninger af filændringer, historik, issues, code review og et sikkert sted at sammenligne, hvad der blev ændret.

Brug ikke AI til seriøse kodeændringer i en mappe, hvor du ikke let kan gennemgå og rulle resultatet tilbage.

Et basic GitHub-workflow er nok:

1. Commit eller stash dit nuværende arbejde, før du starter.
2. Opret en branch til den AI-assisterede ændring.
3. Bed AI lave en lille afgrænset ændring.
4. Gennemgå ændringerne lokalt.
5. Kør de relevante valideringskommandoer.
6. Push branchen og gennemgå den som et pull request.
7. Merge først, når du forstår ændringen.

Det er især vigtigt, når AI har direkte filadgang via en IDE eller terminal-agent. En browserchat kan foreslå dårlig kode. En coding agent kan skrive dårlig kode på tværs af flere filer, før du opdager det.

GitHub giver også et nyttigt revisionsspor. Hvis en ændring senere ødelægger noget, kan du se, hvilken commit der introducerede det, hvad prompten eller issuet forsøgte at løse, og om tests eller review overså noget.

I et enmandsprojekt kan pull requests stadig være nyttige. De sænker ændringen lige nok til, at du bliver tvunget til at gennemgå ændringerne ordentligt. Det er en god ting, når AI er involveret.

Vælg værktøjer efter dit workflow

Der findes ikke én bedste IDE eller ét bedste AI-værktøj til kode. Det rigtige valg afhænger af, hvordan du allerede arbejder, og hvor meget kontrol du vil have.

VS Code med GitHub Copilot eller Codex

VS Code er et praktisk sted at starte, fordi mange AI-værktøjer understøtter editoren godt. GitHub Copilot har chat, completions, agent mode, custom instructions og understøttelse af AGENTS.md i VS Code. OpenAI Codex findes også via lokale klienter som CLI og IDE extension, blandt andet til VS Code og VS Code-baserede editorer.

Vælg denne vej, hvis du vil have en udbredt editor, et stort økosystem af extensions og AI-hjælp tæt på dit eksisterende udviklingsworkflow.

Cursor eller Windsurf

Cursor og Windsurf er AI-first editorer bygget omkring chat, agent-workflows, kodebasekontekst og regler. De er nyttige, hvis du vil have en editor, hvor AI-assisteret udvikling er en central del af arbejdsgangen i stedet for et tillæg til en traditionel editor.

Ulempen er, at du skal forstå hvert værktøjs regelsystem. Cursor har project rules og kan arbejde med AGENTS.md. Windsurf har Cascade, rules, workflows, memories og dokumenterer også brug af AGENTS.md til fælles projektinstruktioner.

JetBrains IDEs

Hvis du arbejder meget med PHP, Laravel, Java, Kotlin eller større backendprojekter, kan JetBrains IDEs stadig være det mest produktive miljø. JetBrains AI Assistant understøtter chat, agent mode, context management og eksterne agenter via Agent Client Protocol.

Den praktiske pointe er enkel: Hvis din eksisterende IDE allerede forstår dit framework, refaktorering, typer, navigation og tests godt, så skift ikke editor kun fordi et andet AI-værktøj er populært.

Terminal-agenter: Claude Code og Codex CLI

Terminal-agenter er ofte bedre til reelt repository-arbejde end en browserchat. De kan undersøge filer, ændre kode, køre kommandoer og arbejde med den samme projektstruktur, du bruger lokalt.

Claude Code bruger CLAUDE.md til vedvarende projektinstruktioner. Codex bruger AGENTS.md. Begge fungerer bedre med tydelige build-kommandoer, testinstruktioner, arkitekturnoter og grænser for, hvad der ikke må ændres.

Browserchat: ChatGPT og Claude

Browserchat er stadig nyttigt, især til planlægning, forklaring af fejl, sammenligning af tilgange og review af kodeudsnit. Det er mindre egnet til større kodeændringer, fordi du selv skal give kontekst og flytte kode frem og tilbage.

Brug browserchat, når opgaven er konceptuel. Brug en IDE eller terminal-agent, når opgaven kræver repository-kontekst og filændringer.

Projektinstruktioner gør AI markant mere nyttigt

Hvis du gentager de samme påmindelser i hver prompt, hører de hjemme i en projektinstruktionsfil.

Eksempler:

• Brug pnpm, ikke npm
• Kør pnpm check-types efter TypeScript-ændringer
• Ændr ikke public APIs uden at spørge
• Bevar eksisterende styling, medmindre opgaven specifikt handler om design
• Brug eksisterende komponenter, før du opretter nye
• Hold indholdets tone praktisk og direkte
• Tilføj ikke dependencies uden godkendelse
• Bevar tilgængelighed, semantisk HTML og teknisk SEO

Instruktioner reducerer gentagne prompts og gør AI-output mere konsistent. De garanterer ikke perfekt adfærd, men de flytter standarden i den rigtige retning.

Brug AGENTS.md som fælles base

AGENTS.md er en almindelig Markdown-fil til AI coding agents. Tænk på den som en README.md til værktøjer i stedet for mennesker.

En nyttig startfil kan se sådan ud:

# AGENTS.md

## Projekt

- Dette er et Laravel- og Astro-projekt.
- Hold backendlogik i Laravel services, medmindre den eksisterende struktur viser noget andet.
- Hold frontendkomponenter små, og brug eksisterende komponenter før nye oprettes.

## Kommandoer

- Installer dependencies med `pnpm install`.
- Kør type checks med `pnpm check-types`.
- Kør production build med `pnpm build`.

## Koderegler

- Lav den mindste ændring, der løser opgaven.
- Bevar eksisterende adfærd, medmindre brugeren udtrykkeligt beder om en ændring.
- Tilføj ikke dependencies uden at spørge.
- Redesign ikke UI, medmindre opgaven specifikt handler om design.
- Tilføj eller opdater tests, når adfærd ændres.

## Review-tjekliste

- Tjek for adfærdsændringer, der ikke var ønsket.
- Tjek tilgængelighed og semantisk HTML ved frontendændringer.
- Tjek sikkerhed og validering ved backendændringer.
- Nævn alle valideringskommandoer, der ikke kunne køres.

Hold filen kort nok til, at AI’en kan bruge den. Lange instruktionsfiler bliver ofte baggrundsstøj. De bedste instruktioner er konkrete, aktuelle og lette at verificere.

Større projekter har brug for mindre instruktionsfiler

I større projekter bliver én stor instruktionsfil svær at vedligeholde. Et bedre mønster er at holde root AGENTS.md fokuseret på globale regler og lægge mindre filer tættere på den kode, de beskriver.

For eksempel:

my-project/
|-- AGENTS.md
|-- apps/
|   |-- web/
|   |   `-- AGENTS.md
|   `-- admin/
|       `-- AGENTS.md
|-- packages/
|   `-- ui/
|       `-- AGENTS.md
`-- docs/
    `-- ai/
        |-- testing.md
        |-- content-style.md
        `-- deployment.md

Root-filen bør forklare hele projektet. En fil i en undermappe bør forklare de lokale konventioner for den del af kodebasen.

For eksempel kan apps/web/AGENTS.md beskrive routing, komponenter, styling og build-kommandoer for det offentlige website. packages/ui/AGENTS.md kan beskrive komponent-API’er, tilgængelighedskrav og visuel konsistens.

Det gør instruktionerne lettere at vedligeholde og forhindrer, at AI’en får irrelevant vejledning med i hver opgave. Det gør også dokumentationen lettere for mennesker at gennemgå.

Split ikke instruktionerne for tidligt. Hvis projektet er lille, er én AGENTS.md nok. Split først, når filen bliver svær at overskue, eller når forskellige dele af kodebasen reelt har forskellige regler.

Sådan kan CLAUDE.md genbruge AGENTS.md

Claude Code læser CLAUDE.md, ikke AGENTS.md. Men CLAUDE.md understøtter imports med syntaksen @path/to/file, så du kan undgå at duplikere de samme projektinstruktioner.

Et praktisk setup er:

@AGENTS.md

## Claude Code

- Brug Plan Mode før større refaktoreringer.
- Spørg før du ændrer arkitektur, routing eller public APIs.
- Foretræk små ændringer, og forklar alle kommandoer der ikke kunne køres.

Så har du én fælles base i AGENTS.md og et lille Claude-specifikt afsnit i CLAUDE.md.

I større Claude Code-projekter kan du også bruge .claude/rules/ til modulære regler, herunder regler med path-scope. Det er nyttigt, når nogle instruktioner kun gælder src/api/**/*.ts, content/**/*.mdx eller en bestemt package i et monorepo.

Den vigtige regel er at undgå duplikeret sandhed. Hvis du vedligeholder den samme instruktion i AGENTS.md, CLAUDE.md, Cursor rules og Copilot instructions, vil de før eller siden glide fra hinanden.

Hvad skal der stå i instruktionerne?

Gode AI-instruktioner er operationelle. De fortæller værktøjet, hvordan det skal arbejde i projektet.

Medtag:

• Projektstruktur og hvor vigtig kode ligger
• Package manager og almindelige kommandoer
• Kommandoer til test, lint, type check og build
• Koderegler, der ikke er åbenlyse ud fra koden
• Krav til sikkerhed, tilgængelighed, SEO eller performance
• Regler for dependencies, migrations, deployment og genererede filer
• Områder der ikke må røres uden godkendelse

Undgå:

• Lange essays om projektets historie
• Vage regler som “skriv ren kode”
• Modstridende instruktioner
• Gamle kommandoer der ikke længere virker
• Værktøjsspecifikke detaljer i den fælles fil, medmindre de gælder bredt

En nyttig test er: Hvis en ny udvikler startede på projektet i morgen, ville filen så hjælpe vedkommende med at lave sikrere ændringer? Hvis ja, hjælper den som regel også AI’en.

Bedre prompts til programmering med AI

Instruktioner sætter grundniveauet. Prompts betyder stadig noget.

En svag prompt er:

Fix this component.

En stærkere prompt er:

Undersøg den eksisterende komponent og forklar, hvorfor mobilmenuen ikke lukker efter navigation. Foreslå derefter den mindste rettelse. Ændr ikke styling, komponentstruktur eller route-adfærd, medmindre det er nødvendigt. Fortæl bagefter hvilke filer der blev ændret, og hvilken validering du kørte.

Ved implementeringsarbejde bør du definere:

• Målet
• Filerne eller området opgaven handler om
• Hvad der ikke må ændres
• Forventet validering
• Om AI’en skal planlægge først eller ændre direkte

Ved review bør du bede om risici i stedet for ros:

Gennemgå disse ændringer for utilsigtede adfærdsændringer, manglende tests, tilgængelighedsregressioner, sikkerhedsproblemer og unødvendig abstraktion. Omskriv ikke koden endnu. List konkrete findings med filreferencer.

Et sikkert workflow den første uge

Hvis du er ny i programmering med AI, så brug et konservativt workflow den første uge.

Dag 1: Brug kun AI til at forklare kode og fejl.

Dag 2: Bed AI skrive tests for eksisterende adfærd.

Dag 3: Læg projektet i GitHub, hvis det ikke allerede ligger der. Opret en branch, lad AI lave én lille ændring, og gennemgå ændringerne manuelt.

Dag 4: Tilføj en basic AGENTS.md med kommandoer, konventioner og grænser.

Dag 5: Brug AI til en rigtig bugfix, men kræv en plan før edits.

Dag 6: Bed et andet AI-værktøj gennemgå ændringerne.

Dag 7: Opdater instruktionsfilen med det, du måtte gentage i løbet af ugen.

Det bygger den vigtigste vane: AI kan hjælpe med arbejdet, men du er stadig ansvarlig for resultatet.

Privatliv og projektgrænser

Før du bruger AI på klientkode eller produktionskode, bør du tjekke, hvad værktøjet sender til sin udbyder, hvordan data gemmes, og hvad dit abonnement eller din firmapolitik tillader.

Vær særligt opmærksom på:

• Secrets og API keys
• Kundedata
• Database dumps
• Privat forretningslogik
• Proprietær kode under stramme kontrakter
• Produktionslogs med persondata

Gode instruktioner kan også hjælpe her. Tilføj regler som “indsæt ikke secrets i chat”, “opret ikke migrations uden godkendelse” eller “kør ikke kommandoer, der ændrer produktionsdata”.

Hold udvikleren i loopet

Den nyttige måde at komme i gang med programmering med AI er ikke at give tastaturet væk. Det er at bygge et workflow, hvor AI har nok kontekst til at hjælpe, men ikke nok frihed til usynligt at ændre det forkerte.

Start småt. Brug din eksisterende IDE, hvis den allerede fungerer godt for dig. Tilføj AGENTS.md, når du bliver træt af at gentage de samme regler. Tilføj CLAUDE.md med @AGENTS.md, hvis du bruger Claude Code. Split først instruktioner efter mapper, når projektet er stort nok til, at det giver mening.

Målet er ikke at få AI til at skrive mere kode. Målet er at lave bedre ændringer med mindre spildtid og færre undgåelige fejl.

Officiel dokumentation der er værd at læse

• AGENTS.md repository
• OpenAI Codex overview
• Claude Code memory and CLAUDE.md
• VS Code custom instructions and AGENTS.md
• GitHub Copilot custom instructions
• Cursor rules
• Windsurf Cascade memories and rules
• JetBrains AI Assistant