Skip to content
KontaktEN
Udgivet
Opdateret

Sådan kommer du i gang med programmering med AI

At komme i gang med AI-støttet programmering handler ikke først og fremmest om at finde den perfekte model. Det handler om at give værktøjet tilstrækkelige oplysninger, afgrænse opgaven, gennemgå resultatet og undgå, at AI’en gør en lille ændring 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 konkrete instruktioner og en tydelig arbejdsgang.

For mindre virksomheder betyder det noget, fordi hjemmesiden ofte hænger direkte sammen med henvendelser, booking, betaling, formularer, webanalyse og synlighed i søgning. AI kan hjælpe dig med at lære hurtigere, men en forkert ændring i et WordPress-plugin, en Laravel-database, et bookingforløb eller en Astro-skabelon kan stadig ramme forretningen.

En udvikler, der bruger AI-værktøjer til planlægning, implementering, kodegennemgang og…

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 hjælpefunktion
  • 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 følgeskader

Det betyder noget, fordi AI kan skrive overbevisende kode, der stadig er forkert. En afgrænset opgave giver et lille sæt ændringer, en tydeligere kodegennemgang 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, fejlfinding, omstrukturering, test og kodegennemgang. Det erstatter ikke forståelsen af, hvad der faktisk skal i produktion.

En god arbejdsgang 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, typekontrol, lint eller build.
  7. Bed en anden AI-gennemgang lede efter skjulte risici.

Arbejdsgangen er langsommere end blot at acceptere forslag, men den er hurtigere end at fejlfinde en oplagt fejl, efter den er kommet i produktion.

Brug AI til at lære god praksis

En af de bedste måder at bruge AI på er at bede den forklare praksissen bag koden.

I stedet for kun at bede om en implementering kan du spørge:

  • Hvad er den mest vedligeholdelige måde at løse dette på med projektets teknologi?
  • Hvilken del af koden er forretningslogik, validering, visning eller datalagring?
  • Hvilke fordele og ulemper er der ved den enkle rettelse sammenlignet med en renere omstrukturering?
  • Hvad ville du teste, før dette blev sat i drift?
  • Hvilke antagelser laver du ud fra de filer, du har set?

Det er her, AI bliver nyttig som lærer. Den kan vise, hvorfor en Laravel-controller ikke bør samle for meget blandet logik, hvorfor et WordPress-hook bør have et snævert ansvar, eller hvorfor en Astro-komponent skal holde indhold og layout forståeligt.

Læringen sker ikke, når du indsætter kode og accepterer den. Den sker, når du sammenligner forslaget med det eksisterende projekt, spørger hvorfor AI’en valgte den retning og afviser ændringer, der er for brede til opgaven.

Gennemgå kode, kommentarer og kommandoer

Resultatet fra AI kan se ryddeligt ud og stadig være forkert. Gennemgå den faktiske kode, ikke kun forklaringen omkring den.

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

  • Kode der ændrer adfærd uden for den ønskede opgave
  • Kommentarer der beskriver, hvad koden burde gøre, ikke hvad den faktisk gør
  • Fjernede særtilfælde, der så gamle ud, men var bevidste
  • Nye abstraktioner der skjuler en simpel forretningsregel
  • Kommandoer, der ændrer filer, afhængigheder, cache, lager eller databasens tilstand

Kommentarer skal vurderes med samme skepsis som kode. En genereret kommentar kan være skråsikker og stadig beskrive den forkerte adfærd. Hvis kommentar og implementering ikke stemmer, bør du ikke stole på nogen af delene, før du har kontrolleret det rigtige forløb.

Kommandoer kræver endnu mere kontrol, fordi de kan ændre tilstand med det samme. Et godt eksempel er Laravel-kommandoen php artisan migrate:fresh. Den er gyldig i udvikling, men Laravel-dokumentationen forklarer, at den sletter alle databasetabeller, før migreringerne køres igen. Det kan være nyttigt i en lokal engangsdatabase. Med den forkerte databaseforbindelse eller på en delt testdatabase eller produktionsdatabase er det ødelæggende.

Før du accepterer en kommando fra AI, så spørg:

  • Hvilket miljø kører den mod?
  • Hvilken databaseforbindelse, lagerplads eller API-konto rammer den?
  • Findes der en aktuel sikkerhedskopi og mulighed for at rulle tilbage?
  • Kan kommandoen først køres som en prøve uden at ændre noget?
  • Er den sikker i et testmiljø, før den rører produktionsdata?

Kommandoen er ikke dårlig, fordi AI foreslog den. Den er dårlig, hvis ingen kontrollerer miljø, effekt og vej tilbage.

Brug GitHub før du lader AI ændre kode

Før AI ændrer rigtig kode, bør projektet være under versionsstyring. Git er det vigtige. GitHub er det almindelige standardvalg, fordi du får grene, pull requests, tydelige visninger af filændringer, historik, opgaver, kodegennemgang og et sikkert sted at sammenligne ændringer.

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

En enkel arbejdsgang i GitHub er nok:

  1. Lav et commit, eller læg dit nuværende arbejde til side, før du starter.
  2. Opret en gren til den AI-støttede ændring.
  3. Bed AI lave en lille afgrænset ændring.
  4. Gennemgå ændringerne lokalt.
  5. Kør de relevante valideringskommandoer.
  6. Send grenen til GitHub, og gennemgå den som et pull request.
  7. Flet først ændringen, når du forstår den.

Det er især vigtigt, når AI har direkte filadgang via et udviklingsmiljø eller en agent i terminalen. En chat i browseren kan foreslå dårlig kode. En kodeagent kan skrive dårlig kode i flere filer, før du opdager det.

GitHub giver også et nyttigt revisionsspor. Hvis en ændring senere ødelægger noget, kan du se, hvilket commit der indførte fejlen, hvad instruktionen eller opgaven forsøgte at løse, og om tests eller kodegennemgang 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 din arbejdsgang

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 fornuftigt sted at starte, fordi mange AI-værktøjer understøtter programmet godt. GitHub Copilot har chat, kodeforslag, agenttilstand, egne instruktioner og understøttelse af AGENTS.md i VS Code. OpenAI Codex findes også via lokale klienter som CLI og udvidelser til udviklingsmiljøer, blandt andet VS Code og programmer baseret på VS Code.

Vælg denne vej, hvis du vil have et udbredt udviklingsmiljø, et stort udvalg af udvidelser og AI-hjælp tæt på din eksisterende arbejdsgang.

Cursor eller Windsurf

Cursor og Windsurf er udviklingsmiljøer bygget med AI som omdrejningspunkt. De samler chat, agentbaserede arbejdsgange, viden om kodebasen og projektregler. De er nyttige, hvis AI-støttet udvikling skal være en central del af arbejdet i stedet for et tillæg til et traditionelt udviklingsmiljø.

Ulempen er, at du skal forstå hvert værktøjs regelsystem. Cursor har projektregler og kan arbejde med AGENTS.md. Windsurf har Cascade, regler, arbejdsgange og hukommelse 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’ udviklingsmiljøer stadig være det mest produktive valg. JetBrains AI Assistant understøtter chat, agenttilstand, håndtering af sammenhæng og eksterne agenter via Agent Client Protocol.

Hovedpointen er enkel: Hvis dit eksisterende udviklingsmiljø allerede forstår projektets teknologi, omstrukturering, typer, navigation og tests godt, så skift ikke program, blot fordi et andet AI-værktøj er populært.

Terminal-agenter: Claude Code og Codex CLI

Agenter i terminalen er ofte bedre til rigtigt arbejde i en kodebase end en chat i browseren. 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. Næste trin er en kontrolleret arbejdsgang for Claude Code og Codex i en eksisterende kodebase.

Chat i browseren: ChatGPT og Claude

En chat i browseren er stadig nyttig, især til planlægning, forklaring af fejl, sammenligning af tilgange og gennemgang af kodeudsnit. Den er mindre egnet til større kodeændringer, fordi du selv skal give de nødvendige oplysninger og flytte kode frem og tilbage.

Brug en chat i browseren, når opgaven er overordnet eller forklarende. Brug et udviklingsmiljø eller en agent i terminalen, når opgaven kræver kendskab til kodebasen og ændringer i filer.

Giv kodeværktøjet faste projekt­instruktioner

Hvis du gentager de samme påmindelser i hvert prompt, hører de hjemme i kodebasen. Faste instruktioner kan beskrive pakkehåndtering, kontrolkommandoer, grænser i arkitekturen, indholdsregler og funktionalitet, der ikke må ændres uden godkendelse.

Codex læser normalt AGENTS.md, mens Claude Code læser CLAUDE.md. Når begge værktøjer arbejder i samme projekt, bør fælles fakta vedligeholdes ét sted i stedet for at blive kopieret til flere filer. Værktøjsspecifik vejledning bør kun dække reelle forskelle som tilgængelige funktioner, rettigheder eller metoden til at kontrollere resultatet.

Gode instruktioner er konkrete: “kør pnpm check-types efter TypeScript-ændringer” er nyttigt; “skriv kode af høj kvalitet” er ikke. De skal samtidig være korte nok til at gennemgå og må ikke forveksles med en teknisk sikkerhedsgrænse.

Den komplette guide til fælles projektregler i AGENTS.md og CLAUDE.md gennemgår filernes hierarki, import, underordnede regler, ansvar for billedgenerering, forskelle i kørselsmiljø, teknisk håndhævelse og kontrol af, hvilke instruktioner hvert værktøj faktisk har indlæst.

Bedre instruktioner til programmering med AI

Projektregler sætter grundniveauet. Den enkelte instruktion betyder stadig noget.

En svag instruktion er:

Fix this component.

En stærkere instruktion er:

Undersøg den eksisterende komponent, og forklar, hvorfor mobilmenuen ikke lukker efter navigation. Foreslå derefter den mindste rettelse. Ændr ikke udseende, komponentstruktur eller ruternes adfærd, medmindre det er nødvendigt. Fortæl bagefter, hvilke filer der blev ændret, og hvilke kontroller du udfø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 kodegennemgang bør du bede om risici i stedet for ros:

Gennemgå disse ændringer for utilsigtede ændringer i adfærd, manglende tests, problemer med tilgængelighed, sikkerhedsproblemer og unødvendige abstraktioner. Omskriv ikke koden endnu. Opstil konkrete fund med filhenvisninger.

En sikker arbejdsgang den første uge

Hvis du er ny i programmering med AI, så brug en forsigtig arbejdsgang 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 gren, lad AI lave én lille ændring, og gennemgå ændringerne manuelt.

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

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

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å:

  • Hemmeligheder og API-nøgler
  • Kundedata
  • Databaseudtræk
  • Privat forretningslogik
  • Proprietær kode under stramme kontrakter
  • Logfiler fra produktion med persondata

Gode instruktioner kan også hjælpe her. Tilføj regler som “indsæt ikke hemmeligheder i chatten”, “opret ikke databasemigreringer uden godkendelse”, “kør ikke migrate:fresh uden udtrykkelig godkendelse” eller “kør ikke kommandoer, der ændrer produktionsdata”.

Hold udvikleren inde i processen

Den nyttige måde at komme i gang med programmering med AI er ikke at give tastaturet væk. Det er at bygge en arbejdsgang, hvor AI har tilstrækkelig viden til at hjælpe, men ikke frihed til ubemærket at ændre det forkerte.

Start småt. Brug dit eksisterende udviklingsmiljø, hvis det 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. Del først instruktionerne op 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

Flere artikler