AI-assisteret kodning: Det komplette workflow fra idé til autonom agent

Hver gang du starter en ny session med Claude Code, arbejder du i et kontekstvindue - en begrænset mængde information agenten kan holde i 'hukommelsen' på én gang. Det lyder teknisk, men det har en konkret konsekvens: jo mere du fylder i kontekstvinduet, jo dårligere output får du.

Det betyder at lange, uafbrudte sessioner producerer ringere kode end korte, fokuserede sessioner. Du har to muligheder når du nærmer dig grænsen: komprimér (/compact), som opsummerer samtalehistorikken til en kortere form, eller ryd (/clear), som starter dig på bar bund. Mange erfarne AI-udviklere foretrækker /clear og en velstruktureret systemkontekst frem for komprimering - fordi en ren session altid starter i samme forudsigelige tilstand.

Sub-agents holder din primære kontekst ren

Claude Code understøtter sub-agents - specialiserede agenter der kører i deres egne isolerede kontekstvinduer. Når du beder den primære agent om at udforske en kodebase, analysere logs eller gennemgå dokumentation, kan den uddelegere opgaven til en sub-agent. Sub-agenten gør arbejdet, returnerer kun resuméet - og din primære kontekst forbliver ren og effektiv.

Den mest udbredte fejl i AI-assisteret udvikling er at hoppe direkte fra en vag idé til implementering. Resultatet er ikke dårlig kode - det er kode der løser det forkerte problem. Det kræver en alignment-fase: en interviewrunde der afdækker alle de spørgsmål og antagelser du ikke vidste du havde.

Princippet er enkelt: du giver agenten en kort beskrivelse af det du vil bygge, beder agenten om at interviewe dig til den har alt relevant og agenten interviewer dig aggressivt - et spørgsmål ad gangen - indtil I har nået fælles forståelse. For hvert spørgsmål giver agenten sin egen anbefaling, så du ikke bare svarer i blinde men aktivt tager stilling.

1. 01

   Start en frisk session

   Ryd kontekstvinduet (/clear) og giv agenten kun én ting: en kort beskrivelse af problemet eller idéen.

2. 02

   Lad agenten interviewe dig

   Agenten stiller ét spørgsmål ad gangen og giver sin anbefaling. Svar kort og konkret. Denne fase kan vare 20-60 spørgsmål og er altid human-in-the-loop - du kan ikke automatisere alignment.

3. 03

   Afslut med en fælles forståelse

   Når alle store spørgsmål er afklaret, er du og agenten på samme bølgelængde. Nu kan du bede agenten om at opsummere beslutningerne i et PRD.

Plan mode i Claude Code (Shift+Tab to gange) er det bedste greb du har: agenten producerer en plan uden at ændre noget kode. Brug det, men læs ikke nødvendigvis planen fra ende til anden - du har allerede nået alignment via interviewet. Planen er et tilstandsdokument, ikke et mål i sig selv.

Når du har nået alignment, har du brug for to dokumenter: et destinationsdokument (hvad der skal bygges) og en opgaveliste (hvad agenten skal gøre, og i hvilken rækkefølge). Disse dokumenter er det eneste agenten behøver for at arbejde autonomt.

PRD'et: Destinationen

Et PRD (Product Requirements Document) beskriver problemet, løsningen og en liste af user stories - konkrete beskrivelser af hvad systemet skal kunne. Det er ikke en teknisk specifikation; det er en fælles reference for hvad 'færdigt' betyder. Du behøver ikke læse hvert ord, fordi du allerede kender indholdet fra alignmentsessionen — agenten er god til opsummering.

Vertikale skiver, ikke horisontale lag

Når du opdeler PRD'et i konkrete opgaver, er der en afgørende regel: skær lodret, ikke vandret. En vertikal skive er en opgave der går igennem alle systemets lag på én gang - fra database til API til brugergrænseflade. En horisontal opgave er at implementere ét lag ad gangen - alle databasetabeller, derefter al API-logik, derefter al frontend.

Begrebet tracer bullets fra The Pragmatic Programmer beskriver præcis dette: ligesom sporlysende ammunition giver anti-lufts skytten øjeblikkelig feedback om skudretningen, giver en vertikal skive dig øjeblikkelig feedback på om alle lag spiller sammen - i stedet for at vente til du har implementeret alt.

AI-agenter har en velkendt tendens: de implementerer kode og skriver derefter tests der passer præcis til den kode de netop har skrevet. Det producerer grønne tests, men dårlig testdækning - og giver dig en falsk tryghed. Test-driven development (TDD) løser dette ved at tvinge agenten til at skrive den fejlende test inden implementeringen.

Red-green-refactor med AI

1. 01

   Rød: Skriv den fejlende test

   Agenten skriver en test der beskriver hvad koden skal gøre. Testen kører og fejler - for der er ingen implementering endnu. Det bekræfter at testen faktisk tester noget.

2. 02

   Grøn: Implementér det minimale

   Agenten skriver netop nok kode til at testen bliver grøn. Ikke mere. Det forhindrer over-implementering og holder opgaven fokuseret.

3. 03

   Refaktorér: Ryd op

   Med en grøn test som sikkerhedsnet kan agenten rydde op i koden uden at bryde funktionaliteten.

TDD er særligt værdifuldt med AI fordi feedback-loops er afgørende for agentens output-kvalitet. Hvis agenten ikke kan køre tests og type-checks undervejs, koder den i blinde. Loftet for hvad agenten kan producere er direkte bestemt af kvaliteten af dine feedback-loops.

Brug TDD: skriv den fejlende test først (rød), kør den og bekræft at den fejler, implementér derefter det minimale kode der gør den grøn, kør tests og type-checks efter hver ændring.

Kør npm run test og npm run typecheck efter hvert trin. Stop og rapportér, hvis en test fejler uventet.

Skriv tests der tester offentlige grænseflader, ikke interne implementeringsdetaljer. Mock aldrig databasen — brug en test-database.

Når alignmentsessionen er færdig, PRD'et er skrevet og issues er opdelt i vertikale skiver, sker der noget afgørende: mennesket forlader loopet. Implementeringsfasen er en AFK-opgave (away from keyboard) — agenten tager dine issues, arbejder igennem dem i sekvens eller parallelt, og returnerer commits til code review.

Tænk på det som dag-vagt og natte-vagt. Dag-vagten er menneskenes: alignment, PRD, Kanban-board. Natte-vagten er agenternes: implementering, tests, commits. Dagen bruges på at kø-sætte arbejde til natte-vagten; natten bruges på at udføre det.

Hvad agenten skal vide for at køre autonomt

• Alle åbne issues - titler, beskrivelser og blocking-relationer
• Seneste commits - for at forstå hvad der allerede er gjort
• Prioriteringslogik - hvad der tages op først (typisk: kritiske bugs → infrastruktur → tracer bullets → polish)
• Definition af færdigt - hvornår en opgave er lukket (tests grønne, type-checks rent, PR-klart)

Push vs. pull for kodningsstandarder: Implementeringsagenten bør kunne trække kodningsstandarder til sig via skills når den støder på relevante situationer. Review-agenten bør have standarderne skubbet til sig via systemprompten, så den altid sammenligner med dem. Brug Claude Code's skill-mekanisme (SKILL.md-filer) til implementering og eksplicitte systemprompt-instruktioner til review.

En AI-agent producerer ikke bedre output end kodebasen den arbejder i tillader. Dårlig arkitektur giver dårlige agenter - ikke fordi agenten er dum, men fordi den ikke kan finde ud af hvad der afhænger af hvad, og fordi testgrænserne er uklare. Kvaliteten af din kodebase sætter loftet.

Dybe moduler vs. flade moduler

John Ousterhouts bog A Philosophy of Software Design skelner mellem dybe moduler (lille, simpel offentlig grænseflade, meget intern logik) og flade moduler (mange små filer med mange eksporter og indbyrdes afhængigheder). AI-agenter foretrækker dybe moduler.

Overladt til sig selv vil AI-agenter typisk producere kode der ser ud som flade moduler: mange små filer med utydelige ansvarsområder. Det er ikke AI'ens fejl - det er resultatet af at den ikke har fået at vide hvad en god arkitektur ser ud som for din kodebase. Formulér modulernes grænseflader eksplicit i PRD'et og i systemprompten.

AI-agenter er kraftfulde implementeringsværktøjer - men de er ikke autonome produktudviklere. Der er klare grænser for hvad du kan delegere, og det er vigtigt at kende dem inden du designer dit workflow.

• Frontend og visuelt design - AI kan generere kode, men den har ikke øjne. Den kan ikke se om et layout ser godt ud, om knapper er på de rigtige steder, eller om farverne fungerer. Visuel QA er altid human-in-the-loop.
• Alignment og planlægning - Interviewfasen kan ikke automatiseres. Du skal sidde ved tastaturet og tage de vigtige designbeslutninger.
• Code review - Agenten kan hjælpe med at identificere problemer, men den endelige vurdering af om koden er korrekt, sikker og holder til produktion kræver et menneske.
• Arkitekturbeslutninger - Hvad der skal bygges og hvordan systemet skal opdeles er menneskelige beslutninger. Agenten kan analysere og foreslå, men du ejer beslutningen.
• Mængden af code review stiger - Når agenter implementerer mere, stiger mængden af kode der skal gennemgås. Det er den direkte konsekvens af at delegere implementering og noget du skal planlægge ressourcer til.

En af de vigtigste distinktioner i AI-assisteret udvikling er at skelne mellem opgaver der kræver din tilstedeværelse, og opgaver der kan køre i baggrunden mens du laver noget andet.

Et team der bruger dette workflow kan køre planlægningsfasen om morgenen og lade agenten implementere om eftermiddagen og natten. QA og code review sker parallelt med agentens arbejde — ikke som et separat efterfølgende trin.

Claude Code er inkluderet i Anthropics betalte planer — du behøver ikke et separat abonnement. Adgangen er den samme, hvad enten du koder i terminalen, desktop-appen eller via IDE-extensions til VS Code og JetBrains.

Til parallelisering med flere agenter i separate worktrees anbefales Max-planen. Pro-planen er tilstrækkelig til enkelt-agent workflow og til at lære metodikken.