AI-kodeassistent: Claude Code vs Cursor vs Copilot

Den forskel der faktisk betyder noget

Alle tre kan kalde de samme frontier-modeller. Sammenligner du på modelnavne, sammenligner du på den eneste akse hvor de er ens.

Den reelle forskel er hvor værktøjet sidder — og dermed hvad det kan se og hvad det må gøre.

Copilot      → i editoren, ved markøren
                ser: åbne filer + den fil du skriver i
                gør: forslag du accepterer med Tab

Cursor       → editoren er selve produktet
                ser: indekseret repo + det du @-nævner
                gør: diffs på tværs af filer, du godkender

Claude Code  → i terminalen, i projektroden
                ser: hele filsystemet, git, kommandoers output
                gør: læser, redigerer, kører tests — bag permissions

Den tredje linje er kvalitativt anderledes end de to første. Et forslag du kan afvise med Escape, og en proces der kører rm, hører ikke til samme risikokategori. Derfor handler over halvdelen af opsætningen i Claude Code om permissions, mens Copilot næsten ingen har.

De tre værktøjer

GitHub Copilot

Den ældste af de tre og stadig den bedste til det oprindelige formål: at foreslå den næste kodeblok mens du selv skriver. Latenstiden er lav nok til at forslaget når frem før du selv når at skrive linjen, og det er hele værdien. Der er også en chat og en agent-tilstand, men styrken ligger i den inline-løkke.

Konteksten er til gengæld smal. Copilot ser primært den aktuelle fil og andre åbne faner. Beder du om noget der kræver kendskab til et modul du ikke har åbent, får du et plausibelt gæt — hvilket er værre end ingenting, fordi det ligner et svar.

1# Projektkonventioner
2
3- TypeScript i strict mode. Ingen `any`.
4- Fejl håndteres med Result-typen i `src/lib/result.ts`,
5  ikke med kastede exceptions.
6- Tests skrives i vitest, i en `.test.ts` ved siden af filen.
7- Kommentarer på engelsk, commit-beskeder på engelsk.

Cursor

En VS Code-fork hvor AI ikke er et plugin, men grundpræmissen. Cursor indekserer hele repoet, så du kan referere til filer og symboler med @, og ændringer på tværs af filer bliver præsenteret som diffs du gennemgår hunk for hunk.

Det gennemgangstrin er styrken. Du ser hver ændring i editoren, med syntax highlighting og i sammenhæng, før den lander på disken. Til refaktoreringer der rører ti filer, er det svært at slå.

1---
2description: Regler for databaselaget
3globs: ["src/db/**/*.ts"]
4alwaysApply: false
5---
6
7- `schema.ts` er source of truth. Migrationer i `drizzle/` er
8  genereret — redigér dem aldrig i hånden.
9- Alle queries går gennem repository-funktioner i `src/db/repos/`.
10  Ingen SQL i route-handlers.
11- Transaktioner: brug `withTransaction()`, ikke manuel BEGIN/COMMIT.

globs er det der gør regelsystemet brugbart. Reglen om databasen indlæses kun når der arbejdes i databasemappen, så du kan have tyve regelfiler uden at fylde kontekstvinduet med nitten irrelevante.

Claude Code

En agent i terminalen. Ingen editor-integration nødvendig — den arbejder mod filsystemet, kan køre kommandoer, læse deres output og fortsætte derfra. Det gør den til det eneste af de tre der kan arbejde uden at nogen kigger med, og til det eneste der kan køre i en CI-pipeline.

Prisen er at gennemgangstrinnet forsvinder fra editoren og flytter til git diff. Til gengæld kan man køre flere sessioner side om side på forskellige opgaver. Konfiguration og permissions er beskrevet i guiden til Claude Code.

1# Afgrænset opgave, kører til den er færdig
2claude -p "Migrér src/api/users.ts fra callbacks til async/await. \
3  Kør npm test bagefter og ret det der fejler." \
4  --allowedTools "Read Edit Bash(npm test:*)"

Den samme opgave i tre værktøjer

Opgaven: en valideringsfunktion er kopieret ind i seks route-handlers og skal samles ét sted. Klassisk oprydning, ikke svær, men den rører flere filer.

Konklusionen er ikke at det sidste er bedst. Den er at gennemgangstrinnet flytter sig — fra tastetryk til hunks til git-diff. Hvor du vil have det til at ligge, afhænger af hvor kritisk koden er, og hvor godt du kender den i forvejen.

Pris

Priser pr. september 2026. Alle tre har ændret prisstruktur mindst én gang det seneste år — tjek selv efter, og læs betingelserne for hvad "ubegrænset" dækker.

Regnestykket er sjældent afgørende. Et abonnement koster mindre end en time af en udviklers tid om måneden. Det der kan blive dyrt, er forbrugsbaseret betaling kombineret med lange agent-sessioner — en agent der kører i en halv time gennem et stort repo, brænder mange tokens. Sæt et loft hvis du fakturerer per token, og hold øje de første uger.

Hvad de har til fælles: konteksten

Alle tre bliver markant bedre af en projektfil der forklarer konventionerne. Filnavnene er forskellige — det samme princip:

Skriv det der ikke kan udledes af koden: byggekommandoer, hvilke mapper der er genereret, hvilke mønstre der er forladt men ikke fjernet endnu. Lad være med at forklare hvad et framework er — modellen ved det, og hver linje koster tokens ved hver forespørgsel.

Alle tre understøtter desuden MCP-servere, så adgang til database, issue-tracker eller dokumentation kan konfigureres ét sted og genbruges på tværs.

Sådan vælger du

• Skriver du selv det meste af koden? Copilot. Den inline-løkke er stadig den mest effektive, og den kræver ingen omstilling.
• Arbejder du i et stort ukendt repo? Cursor. Indekseringen og de gennemgåede diffs er præcis det man mangler når man ikke kender koden i forvejen.
• Har du afgrænsede opgaver med tests der kan verificere dem? Claude Code. Den kan køre løkken selv, og du reviewer resultatet frem for hvert skridt.
• Skal det køre i CI? Claude Code, som den eneste af de tre der er bygget til at køre uden et menneske ved tastaturet.
• Må koden ikke forlade huset? Ingen af dem. Se guiden til lokale modeller — og vær indstillet på at kvaliteten er en anden.

Common pitfalls

• At acceptere kode du ikke ville have skrevet selv. Det er den fejl der koster mest. Alle tre producerer kode der ser rigtig ud og virker på det glade tilfælde. Reviewet er dit — det er ikke blevet valgfrit.
• At vælge på modelnavne. De skifter hvert kvartal. Vælg på arkitektur og arbejdsgang; det ændrer sig langsommere.
• Ingen projektfil. Uden konventioner gætter modellen, og den gætter på gennemsnittet af al offentlig kode — ikke på jeres.
• For store opgaver på én gang. "Refaktorér hele backenden" giver et diff ingen orker at gennemgå. Opgaver der kan reviewes på ti minutter, er den rigtige størrelse.
• At bruge en agent uden tests. En agent der kan køre testsuiten, kan rette sine egne fejl. Uden tests er der ingen feedback-løkke, og så løber den i den forkerte retning.
• Hemmeligheder inden for rækkevidde. Alt hvad værktøjet kan læse, kan ende i konteksten. Hold .env og nøglefiler uden for indekset.