Cursor som IDE: brug AI uden at miste kontrollen over appen

Hvornår giver Cursor mening?

Cursor passer godt, når I vil arbejde direkte i en rigtig kodebase og lade AI'en bruge projektets filer som kontekst. Det kan være til små funktioner, fejlretning, tests, forklaring af ukendt kode og afgrænsede refaktoreringer.

Start med et sikkert fundament

1. 1. Åbn den rigtige projektmappe. Cursor skal arbejde i en lokal kopi af jeres repository – ikke i en mappe med tilfældige eksporter og produktionsfiler.
2. 2. Kontrollér Git-status. Commit eller adskil eksisterende arbejde, så AI'ens ændringer ikke blandes sammen med ufærdige menneskelige ændringer.
3. 3. Få projektet til at køre først. Installer dependencies, kør tests og lav et build, før Cursor ændrer noget. Ellers ved I ikke, om en fejl var der i forvejen.
4. 4. Aktivér Privacy Mode efter virksomhedens politik. Gennemgå samtidig hvilke filer der indeholder kunde-, person- eller legitimationsdata.
5. 5. Begræns terminaladgang. Læs kommandoen før den køres. Giv ikke en agent fri adgang til produktion, cloud-konti eller destruktive scripts.

Vælg arbejdsform efter risiko

Cursor tilbyder forskellige modes. Navne og funktioner kan ændre sig, men princippet er stabilt: brug mindst mulig handlefrihed til opgaven.

• Ask: Brug til at forstå kode, finde relevante filer og diskutere en løsning uden automatiske ændringer.
• Manual: Brug til en præcis ændring, hvor du selv vælger fil og område.
• Agent: Brug til afgrænsede opgaver på tværs af filer, hvor Cursor må søge, redigere og køre relevante kontroller.

Skriv opgaven som en lille specifikation

“Lav login” giver AI'en plads til at opfinde arkitekturen. Beskriv i stedet mål, relevant kontekst, begrænsninger og hvordan resultatet skal verificeres. Bed om en lille ændring ad gangen.

Mål:
Tilføj validering af emailfeltet i kontaktformularen.

Kontekst:
- Formularen ligger i src/components/ContactForm.jsx
- Følg projektets eksisterende mønster for fejlbeskeder
- Bevar den nuværende danske tekst og styling

Begrænsninger:
- Lav den mindst mulige ændring
- Ændr ikke andre formularer
- Tilføj ingen ny dependency

Verifikation:
- Kør de relevante tests og build
- Vis hvilke filer der blev ændret
- Stop og spørg, hvis kravet er uklart

Henvis til konkrete filer og eksisterende mønstre. Bed Cursor læse dem før redigering, men undgå at sende hele kodebasen som kopieret tekst. Hvis løsningen kræver en ny database, loginmetode eller cloud-service, bør det behandles som en arkitekturbeslutning – ikke som en hurtig prompt.

Giv projektet fælles regler

Gentagne instruktioner kan lægges som korte Project Rules i .cursor/rules og versionsstyres sammen med koden. Reglerne bør beskrive konkrete arbejdsgange og grænser – ikke lange generelle ønsker. Den ældre .cursorrules-fil understøttes fortsat, men Cursor anbefaler Project Rules.

---
description: Regler for ændringer i frontend
globs: src/**/*.{js,jsx,ts,tsx}
alwaysApply: false
---

- Følg eksisterende komponent- og stylingmønstre.
- Lav små, afgrænsede ændringer.
- Tilføj eller opdatér tests ved ændret adfærd.
- Kør lint, test og build før opgaven afsluttes.
- Læg aldrig secrets eller persondata i kode eller prompts.

Regler er kontekst til modellen, ikke en teknisk sikkerhedsgrænse. Håndhæv vigtige krav med branch protection, tests, lint, adgangsstyring og review.

Beskyt kode, secrets og kundedata

Cursors AI-funktioner sender relevant kode og prompts til Cursors tjenester og modelleverandører. Ifølge Cursor bliver kode i Privacy Mode ikke brugt til træning, og deres modelleverandører er underlagt zero-data-retention-aftaler. Det ændrer ikke på, at virksomheden skal vurdere databehandlingen og undgå unødvendige persondata og secrets.

.env
.env.*
*.pem
*.key
credentials/
customer-exports/
production-dumps/

• Brug testdata eller anonymiserede eksempler i stedet for rigtige kundedata.
• Hold .env, private nøgler, database-dumps og kundeeksporter ude af AI-konteksten.
• Vær opmærksom på, at .cursorignore beskrives som en “best effort”-beskyttelse – det erstatter ikke korrekt secret management og adgangskontrol.
• Gennemgå virksomhedens databehandleraftale, underdatabehandlere, regionkrav og interne politik, før private repositories bruges.
• Installer kun nødvendige extensions. Cursor oplyser, at Workspace Trust og signaturkontrol for extensions adskiller sig fra VS Code, så plugins bør vurderes særskilt.

Gennemgå resultatet før commit

1. Læs diffen: Kontrollér alle ændrede og nye filer – også konfiguration, dependencies og migrations.
2. Kør kontrollerne: Test, typecheck, lint og produktionsbuild skal køres i samme miljø som projektet forventer.
3. Test negativt: Prøv forkert login, manglende rettighed, ugyldigt input og fejl fra eksterne services.
4. Kontrollér sikkerheden: Søg efter secrets, brede adgangsregler, ukontrolleret input og utilsigtede offentlige endpoints.
5. Commit småt: Ét forståeligt formål pr. commit gør review og rollback realistisk.

Cursors checkpoints kan gendanne Agentens egne ændringer lokalt, men de er ikke versionsstyring og omfatter ikke nødvendigvis dine manuelle ændringer. Git er den varige historik.

Typiske fejl ved AI-vibe coding i Cursor

• For stor første opgave: “Gør appen produktionsklar” blander sikkerhed, drift og funktioner i én uoverskuelig ændring.
• Blind accept af diffen: Koden ser plausibel ud, men har ændret en adgangsregel eller installeret en unødvendig pakke.
• Ingen baseline: Tests fejlede allerede før ændringen, men fejlen tilskrives AI'en eller overses helt.
• Chat som dokumentation: Vigtige arkitekturbeslutninger findes kun i en privat samtale og ikke i repositoryets dokumentation.
• Agent med produktionsadgang: En lokal kodeopgave får samtidig mulighed for at ændre rigtige data eller cloudressourcer.
• Secrets i prompten: En nøgle indsættes for at løse et problem hurtigt og ender i chat- eller terminalhistorik.

Tjekliste til den første Cursor-opgave

• □ Projektet ligger i et privat Git-repository, og arbejdsområdet er rent.
• □ Appen kan bygges og testes, før AI'en ændrer den.
• □ Privacy Mode og virksomhedens datakrav er gennemgået.
• □ Sensitive filer er ignoreret, og secrets ligger ikke i repositoryet.
• □ Opgaven har mål, kontekst, begrænsninger og verifikation.
• □ Agenten har ikke adgang til produktion eller unødvendige værktøjer.
• □ Hele diffen er læst, og relevante negative tests er gennemført.
• □ Ændringen bliver committed, reviewet og udgivet gennem den aftalte pipeline.

Relaterede guides