I Munk AI har vi i stigende grad taget VibeCoding og AI-assisteret kodning i brug, både fordi værktøjerne er blevet markant bedre, og fordi opmærksomheden omkring dem er eksploderet. Først og fremmest mener jeg, at opmærksomheden og “hypen” er fortjent! Det er et af de områder, som tydeligt viser mulighederne med AI (LLM’er) og samtidigt viser, hvor stærkt udviklingen er gået. 

Her deler vi ud af vores faktiske erfaring – ikke hype, ikke “How I built AI-x in a weekend”, men reel brug i rigtige projekter. 

Disclaimer: Vi er selv stor tilhænger af Claude Code. 

Hvor står vi i dag?  

For blot et år siden eksperimenterede vi med det (dengang) nye værktøj Claude Code. Erfaringen var dog, at kontekst hurtigt blev et problem. LLM’en overså eksisterende klasser og funktioner, genskabte allerede løst funktionalitet og introducerede redundante og ofte divergerende implementeringer. Her var vi et sted, hvor Claude såvel som andre LLM’er kunne løse problemer, men det hurtige tab af overblik over eksisterende arkitektur og afhængigheder gjorde større ændringer umulige i praksis. Siden da er der sket meget! 

Ikke-kode-teknisk: Hvis målet er hurtigt at afprøve en idé, visualisere et koncept eller bygge en lille fungerende løsning, er Google AI Studio et stærkt og tilgængeligt værktøj. Vi bruger det til at skabe mockups til fremlæggelser og tilbud. 

Reelt udviklingsarbejde: Vi er ikke i tvivl – med Claude Code og en bevidst tilgang til struktur får man markant bedre resultater. 

• Start med arkitektur og design, planlæg funktioner, integrationer og use cases. 

• Alt sammen i samspil med Claude: få det gemt i markdown-filer med en god struktur, hold claude.md-filen kort – ikke som et langt manifest-dokument, men som en letvægtsindeksering: hvad findes hvor, hvilke mønstre bruges, hvad må bruges, og hvad skal den opdatere undervejs. 

I brug ser jeg overordnet to typer opgaver: 

Mindre rettelser og justeringer kan ofte løses direkte via CLI’en uden planlægning eller andre workflows – beskriv blot ønsket præcist. 

Større ændringer, f.eks. ny funktionalitet eller komplekse ændringer. Her kræver det, at man starter et andet sted. Læg en plan og brug tid på at iterere på den, indtil den fanger de ønsker og eventuelle bekymringer, du har. En oneshot-implementering er meget bedre end at bruge iterationerne i koden (her går det nemlig stadig nogle gange galt med konteksten). 

Gode tricks:  

Skulle du ende i en løbende iteration, så er der stadig mange gode tricks at trække på – muligheden for at gå tilbage til planlægning, eller når tingene virker, at gå med en prompt-teknik ala “skær det, vi har udviklet i denne session, ind til benet og forfin en bedre implementering”. Teknikker som denne afhænger selvfølgelig af, at du stadig bruger normale udviklingsteknikker aktivt, såsom versionsstyring. 

Et andet godt råd, jeg ikke har set så mange steder, er muligheden for at bruge Claude Code til at tegne dine diagrammer som drawio-filer. Det er en god undskyldning til at lave et skill, men hold stadig ascii-versioner af det mest kritiske arkitektur til Claude Code i dine md-filer.  

Til sidst: Guldkornet  

Simpelt -> komplekst -> simpelt. 

Du kan finde uendelige guides og videoer, der viser dig, hvordan du opsætter 100 forskellige sub-agents, komplekse skills og lange Claude.md-filer. Her er min erfaring blevet, at de mange tilføjelser føles imponerende i starten, men hurtigt bliver for meget og faktisk ikke forbedrer resultatet. Hold det simpelt, lav målrettede skills til det, du har mest af, og undgå at overdesigne fra dag et.