AI i udvikling

2026-06-072026-06-07

Mange erfarne udviklere kan godt se, at AI fylder mere i branchen, uden at have gjort det til en reel del af deres egen udviklingsproces endnu. Det er fornuftigt nok. Branchen er fuld af hype, hurtige produktlanceringer og påstande om, at alt nu kan automatiseres. Men for udviklere, der har ansvar for drift, kvalitet og arkitektur, er en flot demo ikke nok. Det skal være nyttigt, kontrollerbart og teknisk forsvarligt.

Denne artikel er skrevet til udviklere, arkitekter og tekniske leads som gerne vil forstå, hvad der faktisk ændrer sig, hvilke værktøjer der er relevante, og hvordan AI kan bruges pragmatisk uden at sænke kravene til kvalitet, sikkerhed og faglighed.

Warning

AI-værktøjer ændrer sig hurtigt. Navne, prismodeller, funktioner og integrationsmuligheder kan have flyttet sig, siden artiklen blev skrevet. Fokus her er derfor ikke på bestemte produktfunktioner, men på arbejdsformer, mønstre og begreber, som er mere stabile.

Hvad er AI egentlig?

Inden vi taler om AI i udviklingsprocessen, er det værd at have en klar forståelse af, hvad vi faktisk taler om – og hvad vi ikke taler om.

AI i denne sammenhæng handler næsten altid om Large Language Models, forkortet LLM'er. Det er de modeller der driver ChatGPT, GitHub Copilot, Claude, Gemini og de fleste andre AI-assistenter du støder på. En LLM er grundlæggende et statistisk system, der er trænet til at forudsige det næste ord i en sætning baseret på mønstre i enorme mængder tekst.

Det lyder simpelt, men konsekvenserne er vidtrækkende. Når en model er trænet på milliarder af ord fra bøger, artikler, GitHub-repositories, dokumentation og Stack Overflow, opstår der noget, der ligner forståelse. Modellen kan generalisere: den kan skrive en funktion til et problem, den aldrig har set præcist beskrevet, fordi den har lært mønstre fra tusindvis af lignende problemer.

Eksempel: Hvis du beskriver "en funktion der parser ISO 8601-datoer og returnerer lokal tid", vil en god model foreslå kode baseret på mønstre fra lignende opgaver i dens træningsdata – ikke fordi den "ved" hvad ISO 8601 er, men fordi den har set den type kode mange gange.

Det vigtige at huske er, at modellen ikke forstår i menneskelig forstand. Den beregner sandsynligheder. Det betyder, at den kan tage fejl og lyde overbevisende imens. Det fænomen kaldes hallucinationer: modellen opfinder API'er, metoder, biblioteker eller fakta, der lyder plausible, men ikke eksisterer. Det er ikke en fejl, der kan rettes væk – det er en grundlæggende egenskab ved, hvordan modellerne fungerer.

Tekst konverteres internt til tal-vektorer kaldet embeddings, som repræsenterer betydning matematisk. "For-løkke" og "gennemløb af array" får vektorer tæt på hinanden, fordi de er relaterede koncepter. Det gør det muligt at finde kode og dokumentation baseret på betydning frem for eksakte ord.

Myter og virkelighed

Debatten om AI er præget af to yderpunkter: enten er det den teknologi, der erstatter alle udviklere inden for få år, eller også er det overhypet nonsens der ikke kan gøre noget nyttigt. Begge positioner er forkerte.

Myte	Virkelighed
AI erstatter udvikleren	AI er et værktøj, ikke en erstatning. Ansvar, prioritering og kvalitetsvurdering er stadig menneskeligt arbejde.
AI ved alt	AI hallucinerer og tager fejl. Den lyder sikker – også når den lyver.
AI er farlig/magisk	Det er software med klare begrænsninger. Hverken Terminator eller tryllestav.
Alle kan nu kode uden erfaring	Erfaring er mere værdifuld end nogensinde – til at vurdere, styre og validere AI-output.
Man skal forstå AI for at bruge det	LLM'er er en af de bedste brugerflader nogensinde skabt. Super simpelt at bruge, super komplekst bagved.

Den vigtigste konklusion er, at AI ikke gør den erfarne udvikler irrelevant. Den gør forskellen mellem stærk og svag teknisk dømmekraft tydeligere.

Fra autocomplete til agenter – en kort historisk rejse

For at forstå, hvor vi er nu, er det nyttigt at se på, hvor vi kom fra. (Årstallene er omtrentlige pejlemærker for, hvornår de enkelte arbejdsformer for alvor blev udbredte.)

1990'erne–2010: Autocomplete, IntelliSense og snippets Editoren foreslår ord og kendte mønstre baseret på hvad du har skrevet. Nyttigt, men uden kontekstforståelse.

2015: Intelligent refactoring og statisk analyse Værktøjer som ReSharper, IntelliJ og Roslyn-analyzers begyndte at forstå kode strukturelt og foreslå forbedringer baseret på mønstre og regler.

2018: Forbedret kontekstuel IntelliCode Machine learning begyndte at prioritere forslag baseret på, hvad der typisk skrives i den givne kontekst – ikke bare hvad der er syntaktisk muligt.

2021: Første bølge af AI-kodeassistenter GitHub Copilot lanceredes og revolutionerede branchen. Pludselig kunne en editor foreslå hele funktioner og blokke baseret på en kommentar eller funktionssignatur.

2023–2026: Multi-modeller, agenter, CLI og dyb IDE-integration AI kan nu arbejde i hele kodebaser, oprette pull requests, køre tests, analysere logs og navigere i projekter selvstændigt. MCP standardiserer integrationer. Specialiserede modeller til kode, multimodalitet og agentbaserede flows ændrer arbejdsgangene markant.

Fra søgedrevet til dialogbaseret udvikling

I mange år har standardarbejdsgangen været nogenlunde den samme: læs en fejlmeddelelse, søg på nettet, find en tråd på Stack Overflow, læs dokumentationen, prøv et par forslag, ret koden, kør testene, og iterer. Den arbejdsgang forsvinder ikke, men AI ændrer tempoet og formen grundlæggende.

Det nye er, at en stor del af undersøgelses- og syntesefasen kan ske i dialog med en model. I stedet for kun at lede efter eksisterende svar kan du beskrive problemet direkte: en fejlsituation, en arkitektur, et datasæt, en pull request eller et ældre modul. Modellen kan så hjælpe med at formulere hypoteser, foreslå refaktoreringer, forklare fremmed kode og generere et første udkast til tests og dokumentation.

Det afgørende er, at AI ikke først og fremmest flytter værdien væk fra udvikleren. Den flytter værdien væk fra ren syntaksproduktion og hen mod forståelse, afgrænsning, evaluering og teknisk dømmekraft. Den erfarne udviklers rolle bliver ikke mindre vigtig, men mere koncentreret om det, der faktisk er svært: valg af retning, kvalitetskriterier, domæneforståelse og risikovurdering.

Det er også her begrebet vibe coding dukker op. Udtrykket beskriver en iterativ tilgang, hvor man ved hjælp af AI genererer kode gennem samtale – beskriver hvad man vil have, evaluerer resultatet, justerer og gentager. Det er ikke en afløser for struktureret udvikling, men det er en reel og produktiv arbejdsform, særligt til prototyper, eksperimenter og opgaver med klare, afgrænsede mål.

Mindset før prompt

En praktisk tommelfingerregel for teams, der er tidligt i gang: start med samarbejdsformen, ikke med værktøjslisten. Tænk AI som en pair-programming-makker, hvor du bliver i loopet og aktivt styrer kvaliteten, frem for en autopilot der bare producerer kode.

Det betyder i praksis, at du løbende kalibrerer, hvad "god nok" kvalitet er i din kontekst, og at du beder modellen om at forklare sine valg: hvorfor denne løsning, hvilke trade-offs, hvilke risici, og hvad der bør testes. Hvis man i stedet blindt accepterer output, flytter man hurtigt ansvar væk fra teknisk dømmekraft og over mod ren gennemstrømning.

Den modsatte arbejdsform giver en markant gevinst: AI bliver en læringsaccelerator. Når du holder dig aktivt i feedback-loopet, bliver det nemmere at forstå nye sprog, frameworks og domæner hurtigere uden at sænke kvalitetskravene.

Tre typer AI-værktøjer i udvikling

Når man taler om AI til softwareudvikling, er det nyttigt at skelne mellem tre kategorier af værktøjer.

Kodeforslag i editoren

Det første og mest kendte mønster er inline kodeforslag: editoren foreslår kode, mens du skriver. GitHub Copilot er det mest udbredte eksempel, men lignende funktioner findes i mange editorer og IDE'er. Gevinsten er typisk størst på trivielle eller gentagne opgaver: teststubber, dataobjekter, oversættelse mellem datamodeller, regulære udtryk og SQL-udkast.

Chatbaseret sparring

Den anden kategori er chatbaserede værktøjer, hvor du kan stille spørgsmål om kode, fejl, design og dokumentation. Her fungerer AI som en teknisk sparringspartner, der hurtigt kan forklare, sammenligne, opsummere og generere udkast. Styrken er bred: fra "hvad gør denne funktion?" til "hvad er forskellene på disse to arkitekturtilgange i min kontekst?".

Agentbaserede arbejdsgange

Den tredje kategori er agentbaserede værktøjer. Her beder du ikke blot om et svar, men om en opgave: analyser denne kodebase, find årsagen til fejlen, opret en test, opdater filerne og vis ændringerne. Værktøjer som Copilot Agent, Cline, Cursor, Windsurf, Aider og Gemini CLI falder i varierende grad i denne kategori.

Det er især den agentbaserede kategori, der ændrer udviklingsprocessen mærkbart, fordi værktøjet ikke kun genererer tekst, men arbejder i flere trin med kontekst og handlinger.

Vigtige begreber

Det er nyttigt at have disse begreber på plads. En agent er et AI-værktøj, der kan arbejde i flere trin og bruge værktøjer. En skill er en genbrugelig instruktion eller specialiseret evne, som hjælper modellen med at løse bestemte opgaver mere konsistent. MCP er en måde at standardisere forbindelsen mellem modeller og eksterne værktøjer. RAG er en måde at hente relevant materiale ind i svaret, når modellen ikke selv har den nødvendige kontekst. Embeddings bruges til at finde indhold, der ligner det, man spørger efter. Du behøver ikke kende detaljerne på forhånd – pointen er hvad de betyder i udviklingsarbejde.

Konkrete AI-værktøjer

Der er efterhånden mange AI-assistenter til udviklere. Her er et overblik over de mest relevante i 2026:

Editorer og IDE-integrationer

GitHub Copilot: Det mest udbredte AI-værktøj blandt professionelle udviklere. Integreret i Visual Studio Code, JetBrains, Visual Studio og andre editorer. Tilbyder inline kodeforslag, chat (Ask-mode), redigering (Edit-mode) og agentbaseret arbejde (Agent-mode) hvor AI navigerer selv i kodebasen. Har desuden Copilot Coding Agent (tidligere Copilot Workspace) til cloud-baserede agentflows fra issue til pull request.
Cursor: En AI-drevet editor bygget oven på VS Code med dyb AI-integration i alle dele af udviklingsoplevelsen.
Windsurf: AI-first IDE (tidligere Codeium), i dag ejet af Cognition – firmaet bag den autonome agent Devin. Indbygget agent (Cascade), lang konteksthukommelse og integrerede agenter til større opgaver.
Cline: En VS Code-extension, hvor AI'en fungerer som coding agent med direkte adgang til editor, terminal og repos. Kan selv lave branches, commits og pull requests.

CLI-baserede agenter

Gemini CLI: Googles kommandolinjeværktøj til Gemini direkte fra terminalen. Velegnet til automation, scripts og hurtige eksperimenter.
Claude Code: Anthropics kodningsassistent med fokus på kontekstforståelse og arbejde med hele kodebaser og komplekse refaktoreringer.
GitHub Copilot CLI: Copilot i terminalen til hurtige opgaver, shell-assistance og AI-understøttede workflows tæt på build/test/deploy.
Codex CLI: OpenAIs terminalorienterede kodningsagent til flertrins-opgaver med fokus på implementering, fejlfinding og refaktorering i eksisterende kodebaser.

No-code og low-code platforme

Hurtig prototyping uden traditionel kode er en reel og nyttig arbejdsform til idévalidering og MVP'er – men har begrænsninger ift. skalerbarhed til enterprise-løsninger:

Lovable: Bygger fulde webapplikationer fra naturlige beskrivelser. AI-genererede webapps fra prompts.
Bolt: StackBlitz' AI-drevne webapp-builder med instant deployment og preview.
n8n: Open source workflow automation med AI-integration. Bygger AI-agenter og workflows uden kode.

Hvad en AI-agent faktisk er

Begrebet "agent" bruges løst i branchen, men i praksis er en AI-agent typisk en model, der har adgang til værktøjer og kan arbejde iterativt mod et mål med en given kontekst. Det kan være adgang til filsystem, terminal, Git, browserautomatisering, sagsstyring, REST-API'er eller interne systemer.

Forskellen på en chatbot og en agent er ikke intelligensniveau, men handleevne. Chatbotten svarer. Agenten gør noget – eller forsøger i det mindste at gøre noget under kontrollerede rammer.

Et realistisk eksempel: "Find fejlen i login-flowet, forklar årsagen, foreslå en minimal rettelse og opret en pull request med en regressionstest." Her er det ikke nok at kunne skrive kode. Værktøjet skal kunne læse den rigtige del af systemet, følge kontrolflow, forstå sammenhængen og udføre en serie handlinger i korrekt rækkefølge.

Det klassiske AI-scenarie i udvikling var: "Her er et kodeforslag." Det nye scenarie er tættere på: "Jeg analyserede projektet, fandt det sandsynlige problem, foreslog en ændring, opdaterede testen og bad dig godkende resultatet."

For en erfaren udvikler er det interessante ikke, om det kaldes en "agent", men om arbejdsformen er nyttig. Hvis et værktøj kan tage en konkret, afgrænset opgave og reducere den manuelle friktion uden at skjule for mange beslutninger, er der reel værdi.

Kontekst betyder mere end modelvalg

Mange diskussioner om AI låser sig fast i spørgsmålet om, hvilken model der er "bedst". I praksis er det ofte et for snævert fokus. Den model, der har adgang til den rigtige kontekst og de rigtige værktøjer, er i mange situationer mere nyttig end en stærkere model, der kun ser et tekstfelt.

Et værktøj eller en integration kan være adgang til GitHub, en database, en browser, Docker, en intern service, et filsystem eller organisationsspecifikke kommandoer. AI bliver først rigtig brugbar i udviklingsarbejde, når den både kan se relevant kontekst og handle på den.

Moden anvendelse af AI handler derfor ikke kun om prompts. Den handler også om, hvordan man giver adgang til kodebaser, dokumentation, standardkommandoer, testmiljøer og adgangsmønstre på en måde, der er sikker og brugbar.

MCP og standardiserede integrationer

Et centralt begreb i den udvikling er MCP, Model Context Protocol. Den korte forklaring er, at MCP forsøger at være en standardiseret måde for modeller at bruge eksterne værktøjer og datakilder.

Det er vigtigt at være præcis: MCP er ikke det samme som, at modeller pludselig har fået mulighed for at bruge værktøjer. Det fandtes allerede i former som tool calling, function calling, plugins og produktspecifikke integrationer. Det nye i MCP er standardisering og genbrug på tværs af klienter og værktøjer.

Den letteste analogi er, at MCP forsøger at blive som USB-C for AI-værktøjer: en fælles måde at forbinde modeller med funktioner uden at hver integration skal være et proprietært specialplugin.

I praksis kan en model via MCP få adgang til funktioner som:

læsning og skrivning af filer
opslag i GitHub eller andre kodeplatforme
browserautomatisering og skærmbilleder
databaseopslag
kald til interne eller eksterne services

Eksempler på udbredte MCP-servere:

GitHub MCP: Læs issues, pull requests, kode og repos direkte i modellen
Google MCP: Gmail-integration, Google Cloud-services
Database MCP: Returnerer skemaer og data, så AI kender præcis hvilke tabeller og felter der findes
Chrome DevTools MCP: Browserautomatisering og test via AI – se Chrome DevTools MCP

Værdien af AI stiger markant, når modellen ikke kun svarer ud fra sin træning, men også kan hente aktuelle data og udføre konkrete handlinger i dit miljø.

Kombinationen af agenter, skills og MCP i praksis

Hvis man kun tager én ting med fra denne artikel, bør det være dette: den største produktivitetsgevinst kommer sjældent fra "en bedre model", men fra den rigtige kombination af agent + skills + MCP.

Hvad bidrager hver del med?

Agenten styrer arbejdsflowet: planlægger trin, vælger handlinger, udfører ændringer, og evaluerer resultatet.
Skills styrer kvalitet og konsistens: genbrugelige instruktioner for fx teststrategi, sikkerhedskrav, navngivning, arkitekturmønstre og deployment-regler.
MCP giver handleevne i den virkelige verden: adgang til filer, GitHub, browser, databaser, API'er og andre systemer.

Kort sagt: Agenten tænker i trin, skills bestemmer hvordan trinene skal udføres, og MCP gør det muligt faktisk at udføre dem.

Et konkret flow

Forestil dig opgaven: "Implementer en ny feature, lav tests, og opret PR med dokumentation."

Agenten læser issue og kodebase.
En skill for "backend quality" instruerer agenten i at bevare offentlige API'er, køre analyzers og kræve tests.
Via MCP henter agenten relevante filer, opretter ændringer og kører tests i terminal.
En skill for "security review" får agenten til at lave et ekstra tjek for inputvalidering og hemmeligheder.
Via GitHub MCP opretter agenten branch, commit og pull request med en tydelig changelog.

Uden skills bliver adfærden ofte ujævn. Uden MCP bliver output ofte "forslag i chat" i stedet for gennemført arbejde. Uden agent mister du flertrins-orkestrering.

Hvornår virker kombinationen bedst?

Når opgaven har flere trin og afhængigheder
Når teamet har tydelige standarder for kvalitet og sikkerhed
Når der er brug for integration mod eksterne systemer
Når du vil kunne gentage samme arbejdsgang med stabil kvalitet

Typiske fejlmønstre

For brede agent-opgaver uden afgrænsning (giver diffust output)
Manglende skills (giver inkonsistent kvalitet mellem kørsler)
For mange MCP-tools uden policy (giver støj og større risikoflade)
Fravær af menneskelig godkendelse før merge/deploy

En pragmatisk tommelfingerregel: start med få, veldefinerede skills og 2-3 MCP-integrationer, mål effekten, og udvid gradvist.

Konteksthåndtering er ofte den reelle forskel

I praksis handler mange moderne AI-værktøjer mindre om selve modellen og mere om konteksthåndtering. Det afgørende spørgsmål er ofte ikke kun, hvor god modellen er, men hvilke filer den kan se, hvor meget af kodebasen der er tilgængeligt, hvordan tidligere beslutninger opsummeres, og hvordan relevant information genfindes uden at overskride modellens kontekstvindue.

Det er her begreber som kontekstvinduer, samtalehukommelse, indeksering af kodebaser, opsummering og genfinding bliver praktiske og ikke bare teoretiske. Hvis værktøjet kun ser få filer uden historik, får du generiske eller misvisende svar. Hvis værktøjet derimod kan kombinere kodeindeks, tidligere beslutninger, relevante dokumenter og de filer, du arbejder i, bliver svarene typisk mere præcise og brugbare.

Det er vigtigt at skelne mellem hukommelse og genfinding. En models hukommelse i en samtale er ikke det samme som RAG. Hukommelse handler om, hvad værktøjet vælger at bære med videre fra tidligere interaktioner. RAG handler om at hente relevante data ind, når de er nødvendige. Professionelle AI-værktøjer kombinerer ofte begge dele, men har stadig begrænsninger: store kodebaser må opsummeres, noget kontekst går tabt, og genfindingen rammer ikke altid præcist.

RAG, embeddings og egne data

RAG – Retrieval-Augmented Generation – er nyttigt, når svar skal forankres i materiale, der ændrer sig ofte eller kun findes internt: dokumentation, arkitekturbeslutninger, runbooks, interne biblioteker, API-kontrakter, driftsvejledninger eller større kodebaser, som modellen ikke pålideligt kan holde i sin kontekst alene.

I den type situationer kan RAG gøre en reel forskel. Det kan hjælpe en model med at svare ud fra jeres faktiske materiale i stedet for generel træning – og det kan være forskellen på et generisk svar og et svar, der tager udgangspunkt i jeres navngivning, mønstre og systemlandskab.

Men RAG er ikke en universalløsning. Det hjælper dårligt, hvis dokumentationen er forældet, hvis det forkerte materiale bliver fundet, eller hvis opgaven handler om dyb kodeforståelse og konsekvensvurdering. RAG er godt til at finde relevant materiale. Det er ikke det samme som hukommelse, og det er ikke det samme som forståelse.

Bag mange RAG-løsninger ligger embeddings og en vektordatabase. Et embedding er groft sagt en matematisk repræsentation af betydning: tekst konverteres til et tal-array (typisk fra nogle hundrede op til flere tusinde dimensioner), så tekster med lignende betydning får vektorer tæt på hinanden. Det gør det muligt at finde indhold, der ligner det, brugeren spørger efter, selv når ordene ikke matcher direkte.

Den praktiske konklusion er enkel: brug RAG, når du vil gøre AI mere forankret i aktuelle, interne eller domænespecifikke data. Brug det ikke som undskyldning for dårlig dokumentation eller som erstatning for teknisk vurdering.

Gode prompts som specifikationer

Udviklere, der kommer til AI uden erfaring, undervurderer typisk, hvor meget kvaliteten af svaret afhænger af det, de giver modellen. En vag prompt giver et vagt svar. En præcis prompt giver et mere nyttigt arbejdsresultat.

For udviklere kan det at skrive prompts ses som en form for letvægts-specifikation. Du beskriver mål, begrænsninger, kontekst, teknologistak og succeskriterier. Jo mere præcist du gør det, jo mindre overlader du til modellens gætteri.

En stærk prompt til kodearbejde indeholder ofte:

formålet med ændringen
tekniske begrænsninger og arkitekturvalg
relevante filer, grænseflader eller kode-uddrag
ønsket kvalitetsniveau
krav til tests, performance eller sikkerhed

Et simpelt før/efter-eksempel viser forskellen klart.

En vag prompt:

Omskriv denne service

Det giver typisk en generel omskrivning, hvor modellen gætter på struktur, tests og ansvar uden at kende dine egentlige krav.

En mere brugbar prompt:

Omarbejd denne ASP.NET Core-service, så den bruger tydelig afhængighedsinjektion,
bevarer det offentlige API, flytter domænelogik ud af controlleren og gør koden lettere
at enhedsteste. Tilføj forslag til 3 relevante tests og peg på eventuelle risici ved ændringen.

Det giver typisk et langt bedre resultat: modellen foreslår en konkret struktur, peger på testbare enheder og gør det lettere at vurdere, om ændringen faktisk passer til den arkitektur, du ønsker.

Tilpasning: instruktioner og prompt-filer

Udover den individuelle prompt er der i mange AI-værktøjer mulighed for at sætte permanente retningslinjer op, der styrer al interaktion i et projekt eller et team.

Copilot Instructions (.github/copilot-instructions.md) er workspace-specifikke retningslinjer, der fortæller AI'en om projektet: teknologistak, kodestil, navngivningskonventioner, arkitekturvalg og hvad den skal undgå. Det er en af de mest effektive måder at sikre konsistens på tværs af alle i teamet.

Prompt-filer (.github/prompts/*.prompt.md eller brugerspecifikke) er genbrugelige prompter til specifikke opgaver: "gennemgå denne kode for sikkerhedsproblemer", "skriv en integrationstestpakke til dette modul" eller "lav en changelog baseret på disse commits". De kan deles i teamet eller bruges personligt på tværs af projekter.

GitHub Spec Kit introducerer en mere struktureret tilgang til AI-assisteret udvikling: fire faser – Specify, Plan, Tasks, Implement – der tager AI-generering fra impulsiv vibe coding til en gennemtænkt, Markdown-baseret og Git-integreret arbejdsgang. Det er et godt eksempel på retningen fra enkeltprompts mod orkestrerede, flertrins-workflows.

AI ændrer ikke behovet for kodekvalitet

AI er stærk til acceleration, men verificerer ikke automatisk at resultatet er korrekt. Den kan skrive tests, men ikke garantere at testene dækker det vigtige. Den kan generere en overbevisende forklaring, men tage fejl i sine antagelser. Den kan lave en elegant refaktorering og samtidig indføre en subtil regression.

AI skal ikke forstås som en erstatning for ingeniørdisciplin, men som en multiplikator for den disciplin, der allerede er til stede. Har teamet gode tests, tydelig arkitektur, gode kodegennemgange og driftsmæssig feedback, kan AI løfte produktiviteten betragteligt. Har teamet uklare krav, fraværende testdækning og svag kodehygiejne, kan AI lige så effektivt accelerere problemerne.

Et overset punkt er statisk kodeanalyse. AI bør ikke kun bedømmes på, om koden kompilerer, men på om den respekterer de analyseværktøjer, teamet allerede bruger.

I .NET/C#: Roslyn-analyzers, StyleCop, SonarQube, SonarLint
I Java: SonarQube, SpotBugs, PMD, Checkstyle, Error Prone
I JavaScript/TypeScript: ESLint, Biome, SonarJS

Hvis AI foreslår kode, der straks udløser advarsler, er det et tegn på, at den ikke arbejder inden for teamets faktiske kvalitetskrav. I agentbaserede arbejdsgange bør en god opsætning instruere AI'en i at tage hensyn til eksisterende analyzers, køre dem som del af valideringen og behandle advarsler som reelle signaler.

De mest oplagte anvendelser i en moden udviklingsproces er:

refaktorering af kedelig eller repetitiv kode
generering af første udkast til enheds- og integrationstest
dokumentation og forklaring af ældre kode
migrationsopgaver mellem biblioteker eller framework-versioner
analyse af stacktraces, logs og fejlscenarier

Men mennesket skal fortsat validere, prioritere og beslutte.

Mennesket er stadig i kontrol

I professionelle udviklingsmiljøer er den mest robuste model sjældent fuld autonomi. Den er snarere "AI-genereret, menneskeligt godkendt". AI kan analysere, foreslå, skrive og omstrukturere – men det er stadig mennesker, der godkender ændringer, bærer ansvaret og vurderer konsekvenserne.

Jo større rækkevidde AI får, desto vigtigere bliver det, at beslutningsretten ikke bliver diffus. Et team kan lade en agent oprette et udkast til en pull request, men bør stadig have kodegennemgang, godkendelsestrin og klare ansvarspunkter.

Evaluering af AI kræver egne testformer

Når AI bliver del af udviklingsprocessen, opstår et behov for at teste AI-adfærd mere systematisk. Mange teams arbejder med evals: kontrollerede testsager og faste scenarier, der bruges til at måle kvaliteten af prompts, agenter og AI-genererede arbejdsgange.

Det kan være alt fra benchmark-opgaver til regressionstests for prompts og agenter. Hvis et team bruger AI til kodeforslag, dokumentation eller analyse, er det nyttigt at kunne måle, om kvaliteten faktisk bliver bedre eller dårligere over tid. Ellers ender man med at diskutere AI ud fra mavefornemmelser i stedet for målbar kvalitet.

Sikkerhed, etik og ansvar

Datasikkerhed og fortrolighed

Datasikkerhed er et af de første og vigtigste spørgsmål at tage stilling til. Spørgsmålet er ikke hypotetisk: kode, der sendes til et cloud-baseret AI-system, forlader virksomhedens netværk.

Del aldrig credentials, nøgler, tokens, CPR-numre eller personhenførbare oplysninger i prompts
Brug anonymiserede cases og testdata når du søger hjælp til konkrete problemer
Kend virksomhedens politik for brug af AI-værktøjer
Gratis AI-værktøjer kan bruge samtaler til træning – læs vilkårene

Gratis og betalte versioner adskiller sig typisk på databeskyttelse. GitHub Copilot Enterprise tilbyder fx et niveau af databeskyttelse, som gratis alternativer ikke gør.

For organisationer med høj dataklassifikation er lokale modeller et reelt alternativ. Værktøjer som Ollama, LM Studio og vLLM gør det muligt at køre modeller lokalt eller i eget driftsmiljø. Det løser ikke alle sikkerheds- eller kvalitetsproblemer, men giver mere kontrol over data, adgang og drift.

Hallucinationer og fejl

AI kan lyde overbevisende – også når den tager fejl. De hyppigste fejltyper:

Hallucinationer: AI opfinder API'er, metoder eller fakta, der ikke eksisterer
Bias: AI afspejler mønstre fra træningsdata, herunder fordomme og forældet praksis
Forældet viden: Modellerne har en cutoff-dato og kender ikke nyeste versioner
Overfladiske tests: AI genererer tests der bekræfter implementeringen uden at udfordre den

En praktisk tommelfingerregel: stol aldrig blindt på AI i beslutninger, der har konsekvenser du ikke selv kan overskue og rulle tilbage.

Licens og ejerskab

AI er trænet på enorme mængder kode – herunder open source kode med varierende licenser. Det rejser spørgsmål om:

Risiko for at AI genererer kode der ligner eksisterende copyrighted kode
GitHub Copilot Enterprise tilbyder juridisk beskyttelse i visse scenarier
Uanset hvad: du er ansvarlig for koden du deployer, uanset hvem eller hvad der genererede den

Ansvar og governance

AI skal indgå i den samme styring som resten af udviklingsprocessen:

Klare retningslinjer for hvilke data der må deles
Hvilke AI-værktøjer der er godkendt i organisationen
Hvordan AI-genererede resultater gennemgås og godkendes
Logning, sporbarhed og adgangskontrol
Dokumentation af hvornår og hvordan AI er anvendt

Der er også en jordnær faktor der sjældent diskuteres: økonomi. Tokenforbrug, API-priser, seat-licenser og omkostninger ved at drive modeller selv kan hurtigt blive en reel del af beslutningen – særligt hvis AI skal bruges bredt i et team eller integreres i automatiserede arbejdsgange.

Risici og hvor AI typisk fejler

For at bruge AI professionelt er det lige så vigtigt at kende fejlbillederne som styrkerne.

De mest almindelige svagheder:

at opfinde API'er, metoder eller biblioteker, som lyder plausible
at undervurdere særtilfælde og driftsmæssige konsekvenser
at foreslå arkitektoniske ændringer uden at forstå alle afhængigheder
at generere tests, der bekræfter implementeringen uden at udfordre den
at give generiske svar på problemer, der er domænespecifikke

AI er mindre egnet til opgaver, hvor domæneforståelse, ansvar og konsekvensvurdering er centrale. Strategiske arkitekturvalg, sikkerhedskritiske beslutninger, vurderinger af data og lovmæssig overholdelse samt ændringer med stor produktionsrisiko bør stadig ejes tydeligt af mennesker.

Den nye måde at lære programmering

AI ændrer ikke kun måden, erfarne udviklere arbejder på – den ændrer også måden, man lærer at programmere. AI fungerer som en personlig mentor, der altid er tilgængelig, aldrig dømmer og kan forklare det samme begreb på ti forskellige måder, indtil det giver mening.

For begyndere kan AI hjælpe med at komme i gang uden at sidde fast ved syntaksfejl. For erfarne kan AI introducere koncepter fra nye sprog og frameworks hurtigt og kontekstuelt. Det rejser også spørgsmålet om "kan alle nu kode?" – svaret er nuanceret: AI sænker barrierne for at producere fungerende kode, men hæver kravene til at forstå, evaluere og styre koden.

Praktiske arbejdsgange der giver værdi hurtigt

Vil man i gang uden at vende hele udviklingsprocessen på hovedet, er det klogt at starte med opgaver, hvor værdien er tydelig og risikoen overskuelig.

Sparringspartner under kodning: Bed AI om at forklare en service, opsummere et modul, pege på sandsynlige forbedringer eller formulere en plan for en refaktorering, inden du selv ændrer koden.

Testarbejde: AI er god til at generere testtilfælde, finde særtilfælde og foreslå datavarianter – særligt når du allerede har en tydelig struktur for testene.

Dokumentation og onboarding: En model kan hurtigt omsætte kode og struktur til introduktioner, arkitekturopsummeringer og README-udkast, som ellers sjældent prioriteres.

Debugging: Ikke fordi AI magisk kender årsagen, men fordi den kan strukturere fejlsøgningen: formulere hypoteser, forbinde symptomer med mulige fejlkilder og foreslå, hvilke observationer der vil afklare næste skridt.

Multimodale arbejdsgange: Når et værktøj kombinerer kode med skærmbilleder, browserkørsel, UI-inspektion og logs, åbner det for nye typer analyse og fejlsøgning. Det er ikke modent overalt endnu, men retningen er tydelig.

En pragmatisk startmodel for teams

Et team, der vil i gang uden at gøre AI til endnu et diffust transformationsprojekt, kan starte enkelt:

Vælg afgrænsede opgaver: Reversible, lette at validere – fx testgenerering, dokumentation og kodeforklaring
Hold menneskelig godkendelse som fast led: Ingen AI-genereret kode deployes uden review
Mål på konkrete mål: Gennemløbstid, kvalitet af kodegennemgange, antal fundne regressionsrisici
Sæt instruktioner op én gang: Brug .github/copilot-instructions.md til teamets retningslinjer
Skaler gradvist: Brug bredere kodegenerering og agentflows, efter I har erfaring med simple opgaver

Det vigtigste er ikke at indføre AI overalt. Det vigtigste er at finde de steder, hvor værktøjerne reducerer friktion uden at sløre ansvar.

Sådan kommer erfarne udviklere godt i gang

Den bedste start er sjældent at bede et værktøj om at bygge et helt system. Det er bedre at begynde med små, kontrollerede opgaver i en kodebase, du allerede forstår.

Prøv for eksempel disse typer opgaver:

Forklar denne service og tegn de vigtigste afhængigheder op.
Skriv forslag til tests for denne metode, inklusive særtilfælde.
Gennemgå denne pull request og peg på regressionsrisici.
Foreslå en refaktorering, der reducerer kompleksitet uden at ændre adfærd.
Forklar denne stacktrace og giv tre sandsynlige årsager i prioriteret rækkefølge.

Den type opgaver passer godt til erfarne udviklere, fordi de kan bedømme kvaliteten af svaret. Det er her den reelle læring opstår: ikke ved blind tillid til output, men ved at bruge modellen som en hurtig samarbejdspartner, der hele tiden udfordres af faglig vurdering.

En praktisk tommelfingerregel: jo lettere en ændring er at teste, gennemgå og rulle tilbage, jo bedre egner den sig som tidlig AI-opgave.

Demo-eksempler til undervisning og foredrag

De følgende fire prompts illustrerer "vibe coding" fra en tom fil til en fungerende applikation. De er velegnede som live-demo eller øvelse i undervisning.

Solsystemet – animeret visualisering

Lav en HTML-side med alt i én fil (HTML, CSS og JavaScript):

En animeret visualisering af solsystemet med følgende funktioner:
- Solen i centrum med realistiske størrelser og afstande (skaleret passende)
- Alle 8 planeter der kredser om solen med forskellige hastigheder
- Hver planet skal have sin korrekte farve (Merkur: grå, Venus: gulbrun, Jorden: blå,
  Mars: rød, Jupiter: orange med striber, Saturn: gul med ringe, Uranus: lyseblå,
  Neptun: mørkeblå)
- Planeternes baner skal vises som svage streger
- Saturn skal have synlige ringe
- Mørk baggrund med stjerner
- Responsive design der fungerer på alle skærmstørrelser

Gør det visuelt flot og astronomisk nogenlunde korrekt ift. relative størrelser og omløbstider.

Se eksempel: Solsystemet Demo

Hukommelsestest – Simon Says

Lav en HTML-side med alt i én fil (HTML, CSS og JavaScript):

En sekvenshukommelses-test inspireret af Simon Says:
- 4 store farvede knapper i 2x2 grid (rød, grøn, blå, gul)
- Computeren viser en sekvens, spilleren skal gentage den
- Niveau stiger ved korrekt svar, game over ved fejl
- Score gemmes i localStorage
- Professionelt design med tydelig kontrast og store knapper (mindst 150x150px)
- Fungerer på tablet og desktop

Gør det professionelt og nemt at bruge for ældre brugere.

Se eksempel: Hukommelsestest Demo

ReactAppAI: Simpel momsberegner med validering

Brug repoet ReactAppAI som reference, og giv agenten en tydelig, testbar prompt som denne (de to momssatser i prompten er valgt for at give demoen noget at vælge imellem – 12,5% er ikke en reel dansk sats):

Byg en simpel momsberegner som React-komponent (TypeScript) med fokus på robust validering og tydelig UX.

Funktionelle krav:
- Brugeren skal kunne beregne både:
    1) Beløb før moms -> efter moms
    2) Beløb efter moms -> før moms
- Understøt præcist to momssatser: 12.5% og 25%
- Brugeren vælger retning (før->efter eller efter->før) via radio buttons
- Brugeren vælger momssats via dropdown eller segmented control

Validering (obligatorisk):
- Inputfelt accepterer kun gyldige tal med op til 2 decimaler
- Tomt input, negative tal, tekst og ugyldige formater skal give fejlbesked
- Beløb over 10.000.000 skal afvises med tydelig fejl
- "Beregn"-knap skal være disabled, når input er ugyldigt
- Fejlbeskeder skal være konkrete og på dansk

Krav til beregning:
- Brug præcis decimal-håndtering (ingen synlige floating-point artefakter)
- Vis resultat med 2 decimaler
- Vis også den beregnede moms i kroner

Krav til UI:
- Simpelt, rent layout
- Tydelige labels og hjælpetekster
- Accessibility: korrekt label-for, aria-live på fejl/resultat

Kvalitetskrav:
- Skriv enhedstests for validering og beregningslogik
- Skriv komponenttests for de vigtigste brugerflows
- Lever løsningen som små, læsbare commits (eller en tydelig ændringslog)

Svarformat:
- Vis først en kort plan
- Implementer derefter
- Afslut med testoversigt og kendte begrænsninger

Pointen med dette eksempel er, at det er lille nok til en live-demo, men komplekst nok til at vise forskellen på løs kodegenerering og en struktureret agent-arbejdsgang med klare kvalitetskrav.

MCP-demo med Chrome DevTools

Hent serialdate og brug Chrome DevTools MCP til at:

Få et overblik over brugerfladen
Teste at konvertering fungerer korrekt
Generere en Lighthouse-rapport

Det demonstrerer konkret, hvordan en AI-agent kan arbejde med en rigtig applikation via MCP-integration – ikke kun generere kode, men interagere med og analysere et kørende system.

Se også MyCalc og MiniCrm for eksempler på mere avancerede projekter.

Slides (HTML): Programmering med AI

Hvad er allerede i gang?

Det mest ærlige svar er, at ingen ved præcist, hvordan AI i udviklingsarbejde ser ud om to år. Men der er allerede nu tydelige tendenser:

Værktøjerne bliver mere agentbaserede
Udviklingsmiljøer får dybere AI-integration i alle faser
Test, kodegennemgang, dokumentation og analyse bliver i stigende grad assisteret
Flere teams arbejder med flertrinsflows: planlægning, udførelse og kontrol
Specialiserede modeller til kode, diagram-generering og multimodalitet modnes hurtigt

Netop derfor er det værd at holde fast i det, der er mere stabilt end værktøjslandskabet. Arkitektur, domæneforståelse, kritisk tænkning, kommunikation og ansvar for kvalitet er ikke blevet mindre vigtige. Tværtimod er de sandsynligvis de kompetencer, der bliver mest afgørende, når resten ændrer sig.

Konklusion

AI er på vej til at blive en integreret del af udviklingsprocessen. Ikke som en erstatning for udviklere, men som et produktivitetsværktøj, en analytisk hjælper og i stigende grad en teknisk samarbejdspartner, der kan arbejde i flere trin.

For erfarne udviklere er det vigtigste ikke at lære alle nye værktøjer på én gang. Det vigtigste er at forstå arbejdsformen: hvordan kontekst, instruktioner, værktøjer, validering og styring spiller sammen.

De udviklere, der får mest ud af AI, bliver næppe dem, der ukritisk accepterer alt output. Det bliver dem, der kombinerer klassisk softwarehåndværk med en evne til at styre, afgrænse og validere AI-assisterede arbejdsgange.

AI gør ikke den erfarne udvikler irrelevant. Den gør forskellen mellem stærk og svag teknisk dømmekraft tydeligere.

Ekstra

Slides (HTML): Programmering med AI