Sådan styrer du AI-coding-agenter: dirigér Claude Code som en instruktør

De fleste bruger AI-coding-agenter som en spilleautomat: kast en forespørgsel ind, træk i håndtaget, håb på det bedste. Til et hurtigt udkast rækker det. Til alt, der skal køre pålideligt, er det en opskrift på frustration. Det afgørende skift: bliv instruktør i stedet for bruger – altså dirigér agenten i stedet for at se på, mens den improviserer.

Det gælder Claude Code, fordi det er det mest udbredte værktøj lige nu – men lige så meget for ethvert andet AI-værktøj. Og det gælder ikke kun programmering: Har du først forstået, hvordan man styrer en agent ordentligt, kan du bruge det til at kalkulere tilbud, lave rapporter eller automatisere hele forretningsgange. En baggrund i software engineering er ikke nødvendig.

Fra „vibe coding“ til struktureret arbejde

Den hyppigste fejl har et navn: „vibe coding“. Man formulerer en forespørgsel, lader agenten løbe af sted og kontrollerer knap nok resultatet. Det er præcis de to trin, der gør arbejdet seriøst, som mangler – planlægningen på forhånd og valideringen bagefter.

Et enkelt billede er byggeriet af et træhus. Først tegner du en skitse, overvejer hvor meget træ du skal bruge hvor, og skaffer det rigtige værktøj. Når huset står, sætter du ikke bare børnene ind i det – du tester først, om det holder. Den samme disciplin kræver omgangen med coding-agenter.

Det bliver vigtigt, fordi modellerne har en tendens til smiger. Spørger du „Ser det godt ud?“, kommer der gerne et „ja“, uden at planen reelt er blevet kritisk gennemgået. Omvendt påstår modeller af og til, at noget er færdigt, selv om det ikke er det. Du har altså brug for din egen, uafhængige metode til at kontrollere begge dele. Forløbet har fire trin:

• Planlæg – afklar med den nødvendige kontekst, hvad der skal bygges, og hvordan succes konkret ser ud.
• Byg – deleger så meget af udførelsen som muligt til agenten.
• Verificér – hav en klar, selvstændig måde at kontrollere resultatet på.
• Forbedr systemet – det ofte oversete fjerde trin: udled en varig forbedring af hver kørsel.

Verifikation: bevis i stedet for påstand

Verifikation betyder i kernen: „Bevis for mig, at det virkelig er færdigt.“ Ved programmering er det tests og linting – men princippet kan overføres til næsten alt. Eksempel uden kode: Agenten laver et diagram og renderer det derefter som billede. Da moderne modeller er fremragende til at læse billeder, kan agenten se på sit eget værk, opdage overlap og selv rette dem over flere runder. De indledende fejl er ligegyldige; kun resultatet til sidst tæller.

Effekten kan måles: Uden kontrolmekanisme ligger det første resultat måske på 65 til 70 ud af 100 point. Med en indbygget kontrol er omkring 92 muligt allerede i første forsøg. Perfekt bliver det sjældent med det samme – og det er heller ikke pointen. Pointen er at give agenten en ramme, den kan kontrollere sit eget arbejde med. Ledespørgsmålet er altid: Hvordan kan agenten kontrollere resultatet, sådan som en rigtig bruger ville gøre det? Et blot blik på den genererede kode er aldrig nok.

Hvad er en „harness“?

En harness er skallen omkring AI-modellen – de værktøjer og den kontekst, modellen har adgang til, så den ved, hvad den arbejder på. Forestil dig det som en lagmodel: I centrum står modellen som selve „hjernen“. Uden om lægger du et værktøj som Claude Code. Og ovenpå bygger du dit eget lag – konfiguration, Skills, Hooks og forbindelser til CRM eller opgavestyring. Netop det øverste lag gør et generisk værktøj til dit system.

Planlægning: det undervurderede trin

De fleste planlægger alt for lidt. Med coding-agenter bruger du mere tid på at planlægge end på at bygge, fordi du i vidt omfang giver udførelsen fra dig – succesen hænger dermed direkte sammen med planens kvalitet. Ét enkelt dokument, der beskriver målet, har vist sig at virke:

• Hvad bygger vi – og hvorfor?
• Hvordan ser succes konkret ud?
• Hvordan kan agenten se, at arbejdet er færdigt og korrekt?
• Ved tekniske opgaver: Hvilke steder i det eksisterende system skal reelt røres?

Det typiske forløb: først samle kontekst og relevante dokumenter, så researche og derefter udvikle planen sammen med agenten. Meget vigtigt: Lad agenten stille mange spørgsmål, så den ikke træffer utallige antagelser om det ønskede resultat. Først når den har spurgt målrettet ind, er menneske og agent enige om, hvad der skal gøres, og hvordan det skal kontrolleres.

At føle sig tryg, også uden at kunne læse kode

Hvordan får man tillid til kode, man ikke selv læser? Der er to veje. For det første: Bed agenten om at forklare det, den har skrevet. Kode virker skræmmende i starten, men efter den første forhindring læses den næsten som engelsk. For det andet, hvis du slet ikke vil lære at programmere: Tilliden opstår gennem valideringsstrategien. Netop her ligger forskellen til vibe coding – du klemmer udførelsen ind mellem en omhyggelig plan og en lige så omhyggelig kontrol, som du selv er en del af. Agenten får først grønt lys, når det er klart defineret, hvordan den dokumenterer, at arbejdet er færdigt.

Kontekst er knap: „dumb zone“

Når du planlægger, er det vigtigste at styre konteksten, for en models opmærksomhed er en knap ressource. Der cirkulerer en misforståelse om, at det er ligegyldigt, hvor meget man byder agenten, fordi moderne modeller har enorm kontekstkapacitet. Tallene er imponerende – men der er to forbehold.

For det første er konteksten brugt hurtigere, end man tror: Læser agenten flere Skills eller større mængder kode, er titusinder til hundredtusinder af tokens væk på et øjeblik. For det andet findes „dumb zone“. I den forreste del af kontekstvinduet virker modellen skarp og på højden af sin ydeevne. Overskrider samtalen en bestemt tærskel, tipper det: Modellen virker overlæsset, overser ting og laver fejl, som aldrig ville ske med frisk kontekst.

Derfor må du nøje afveje, hvad du giver agenten på forhånd, og hvad den selv må opdage efter behov. Netop det er styrken ved Skills: De stiller fremgangsmåder og best practices til rådighed, men modellen bestemmer selv, hvornår den har brug for hvilken information. Hæld ikke det hele ind på én gang. Meget ofte ligger problemet ikke hos modellen, men i måden konteksten fyldes på. Det store kontekstvindue giver altså en falsk tryghed – det kritiske punkt bør du helst slet ikke nå.

Orkestrér flere sessioner

Fordi „dumb zone“ findes, kan du ikke smide store opgaver ind i én enkelt session. Svaret er et workflow af flere agent-sessioner: Én agent planlægger, giver dokumentet videre til en anden, der udfører det, denne skriver en udførelsesrapport, og en tredje validerer og kontrollerer arbejdet. Omstændeligt, men for produktionsklar software eller forretningskritisk automatisering ganske enkelt nødvendigt.

Billedet er et samlebånd: Hver agent gør én ting rigtig godt og giver sit resultat videre, så den næste har kontekst nok til at forstå, hvad der er gjort, hvad der udestår, og hvad dens egen aktuelle opgave er.

Et eksempel fra B2B-hverdagen: udarbejdelse af tilbud, for eksempel i bygge- eller trykkeribranchen. Sådanne kalkulationer er omstændelige – anslå indsatsen, fastlægge materialer, undersøge priser, vælge leverandører. Her bygger man et workflow af specialiserede agenter: én kontrollerer lagerbeholdningen, én sammenligner priser, én laver udkastet til PDF’en. Til sidst står en validering – for eksempel et regnestykke, der kontrollerer, om den ønskede margin nås. Ser du ærligt på dit eget arbejde, opdager du hurtigt, at det kan skæres op i mange små delopgaver – og netop den opdeling giver med det samme enorm løftestang.

Sikkerhed hører til i teknikken, ikke i prompten

En særligt falsk tryghed handler om rettighederne. Mange tror, at deres prompts er beskyttelse nok. Det er de ikke. Siger du til en agent, at den aldrig må slette en database, kan det ske alligevel. Forbyder du den at slette en mappe, skriver den måske et script, der gør præcis det.

Den eneste holdbare grundholdning er derfor: Alt, hvad agenten kan læse eller røre, rører den før eller siden også – selv uopfordret. Rettigheder skal håndhæves teknisk: via snævert afgrænsede nøgler eller ved at bestemte ting simpelthen er uden for rækkevidde. Et virkeligt eksempel viser faren: En agent misforstod et punkt på sin opgaveliste – og sendte derfor en e-mail med en rabatkode til hele distributionslisten, selv om den aldrig skulle ud.

Et gennemprøvet middel er Hooks – små stykker kode, der køres ved en bestemt hændelse, for eksempel lige før agenten bruger et værktøj. Sådan kan du kontrollere, om en kommando er kritisk, og blokere den. De samme Hooks kan bruges til at forbedre systemet af sig selv – for eksempel ved at der i slutningen af hver session automatisk skrives et resumé i en daglig log.

Gør hver fejl til en varig opgradering

Det måske vigtigste er systemets udvikling. Opstår der et problem, retter du det ikke bare og går videre – du bruger det sammen med agenten som anledning til at spørge, hvad der kan forbedres, så det ikke gentager sig. Måske opstår der en ny regel i din konfiguration, et ekstra planlægningsdokument eller en tilpasset Skill. Sådan bliver hver bug til en varig opgradering.

Har du først etableret dette system, byder du fejl næsten velkommen. Og inden de overhovedet opstår, hjælper et enkelt spørgsmål, som næsten ingen tør stille: „Hvad kunne gå galt her?“ Lad agenten målrettet konstruere grænsetilfælde og forsøge at knække applikationen med problematisk input. Går noget i stykker, hører det tilbage i kontrolsløjfen: find problemet, ret det og – meget vigtigt – test igen. Måske løste rettelsen slet ikke problemet.

Den rigtige holdning til værktøjet

Behandl værktøjet som en mentor – verdens klogeste menneske, der samtidig er din bedste ven. Det ler ikke ad dig, når du spørger om noget tilsyneladende dumt. Men ikke alt egner sig som spørgsmål: På grund af smigeren er det problematisk at spørge en model om dens mening. Til gengæld egner den sig fremragende til at forstå, hvordan noget fungerer, eller hvor der findes empiriske data – ved grænsetilfælde virker en automatisering med et bestemt input, eller også gør den ikke. Ingen gråzone. Har du brug for et andet perspektiv, lader du to modeller gå imod hinanden: den ene bygger, den anden spiller djævelens advokat i en separat session i stedet for at rose ukritisk.

Konklusion: tænk som en produktmanager

Det centrale råd til slut: Uanset hvor teknisk kyndig du er – betragt dig selv som produktmanager for din agent. Du behøver ikke beskrive, hvordan noget bygges. Men du skal forme visionen: Hvad bygger vi, og hvorfor? Giv værktøjet hvorfor’et med – det præger hvordan’et overraskende meget.

Det er den ærlige kerne bag hypen: AI-agenter er hverken en spilleautomat eller et mirakelmiddel. De er et effektivt værktøj, der bliver præcis så godt som den ramme, du giver det. Gode planer, klare kontrolkriterier og disciplinen til at lære af hver fejl – det bringer dig længere end enhver ny model. Start i det små: Skriv en af dine processer ned, skær den op i delopgaver og definér, hvordan du kan se, at resultatet holder. Resten kan du delegere.

Kilde: Denne artikel bygger på videoen How to Build Effective Claude Code Agents in 2026 af Nate Herk | AI Automation. Indholdet er bearbejdet selvstændigt og sat i kontekst for en tysksproget læserskare.