når du skriver kode med en LLM som din medarbeider, blir det ikke bare en spørsmål om å skrive bedre kode. Det handler om å skape en struktur som gjør at AI faktisk forstår hva du vil ha - og ikke bare gjetter. I vibe coding, der fokus ligger på å bygge noe som føles riktig, ikke bare fungerer, er designmønstrene du velger avgjørende. De er det som skiller en kodebase som holder seg sammen fra en som går i stykker etter tre uker.
Hva er vibe coding?
Vibe coding er ikke en teknologi. Det er en holdning. Du starter ikke med å tegne alle database-tabellene, definere alle API-ene, eller skrive en 50-siders arkitektur-dokument. Du starter med å bygge én enkel ting - og gjøre den perfekt. Etterpå bygger du på den. Du lar koden vokse naturlig, ikke med en plan som ikke kan endres. LLM-er passer perfekt til dette. De er gode på å generere kode fra små, tydelige beskrivelser. Men de er dårlige på å forstå hva du tenker hvis du ikke gir dem en klar ramme.
Vertikal slice - bygg én funksjon fullstendig
Den mest brukte designmønsteret i vibe coding er vertikal slice. Denne metoden handler om å bygge en funksjon fra bunnen av - fra database til brukergrensesnitt - i én enkel, fullstendig steg. Ikke først database, så API, så frontend. Nei. Du starter med det enkleste eksemplet: for eksempel en innlogging.
Du lager bare det du trenger: én brukertabell, én API-endepunkt, én innloggingsform, og én side som viser at du er logget inn. Ikke mer. Ikke mindre. Deretter legger du til neste funksjon - kanskje en profilside - og bygger den på samme måten. Hver gang du legger til noe, bygger du på det du allerede har. Det gjør det mye lettere for LLM-en å holde oversikt. Den ser ikke en uendelig kodebase. Den ser en liten, klar, forståelig enhet.
Denne metoden reduserer hallucineringer. Når LLM-en ikke har noe å referere til, gjetter den. Men når den har et eksempel - en funksjon som allerede fungerer - kan den kopiere stilen, strukturen og logikken. Det gir koden en konsistent følelse. Og det er akkurat det vibe coding handler om.
Dokumenter arkitekturen - ikke bare tenk den
LLM-er vet ikke hva du tenker. De vet ikke om du vil ha MVC, eller om du vil ha en ren komponentmodell. De vet ikke om du vil bruke dependency injection eller bare legge alt i controlleren. Hvis du ikke sier det, vil de bruke det de har lært fra offentlige kodebasen - og det er sjelden det du vil.
Derfor må du dokumentere arkitekturen. Ikke i en 20-siders PDF. Men i en enkel fil, kanskje kalt architecture.md, som ligger i roten av prosjektet. Her skriver du:
- Hvilket mønster du bruker: MVC, View-Logic, eller noe annet?
- Hvordan du håndterer database-tilganger: repository-mønster med dependency injection?
- Hva du kaller dine mapper:
models/,services/,components/? - Hva du ikke gjør: for eksempel «ikke bruk globale variabler» eller «ikke legg logikk i komponentene».
Denne filen blir LLM-en din sin bokstavlige regelbok. Den vil sjekke mot den før den genererer kode. Og hvis du endrer arkitekturen senere? Oppdater filen. Det er så enkelt. Og det fungerer.
Komponentbibliotek og maler - ikke la LLM-en gjette utseendet
Hvor mange ganger har du sett en LLM generere en knapp som ser ut som den er fra 2012? Eller en modal som ikke passer til resten av appen? Det skjer fordi LLM-en ikke vet hva «vibe» din er. Den vet ikke om du vil ha moderne, minimalistisk, eller korket.
Her kommer komponentbiblioteket inn. Bruk en katalog med ferdige komponenter: knapper, skjemaer, navigasjonsmenyer, modaler. Ikke skriv dem selv. Bruk en som allerede eksisterer - enten fra en open-source-bibliotek som Headless UI, eller din egen samling av komponenter du har bygget tidligere.
OG bruk maler. En mal for en ny side. En mal for en ny API-endepunkt. En mal for en ny test. Når LLM-en får en mal, vet den ikke bare hva som skal skrives - den vet også hvordan det skal se ut. Det sparer tid. Og det gjør koden mer sammenhengende.
Verktøy som Wasp (for JavaScript) eller Laravel (for PHP) gjør dette lettere. De har «batterier inkludert» - de tar hånd om infrastrukturen, så du kan fokusere på logikken. LLM-en kan da gjøre det den er god på: skrive logikk, ikke sette opp servere.
Kontekst-ingeniøring - gi LLM-en en kontekst, ikke bare en prompt
Det finnes en ny, kraftig teknikk som heter kontekst-ingeniøring. Den bruker du når du arbeider med Cursor eller Claude Code. Du lager en mappe kalt .cursor/rules/. I den legger du flere filer:
coding-style.md- hvordan du skriver variabelnavn, hvordan du formatterer kode, hvilke kommentarer du bruker.authentication.md- hvordan du håndterer innlogging i dette prosjektet: JWT? Sessions? Hva er token-levetiden?error-handling.md- hvordan du håndterer feil: logger du dem? sender du brukeren til en side? sender du en e-post?database-conventions.md- hvordan du navngir tabeller, bruker foreign keys, og håndterer migreringer.
Når LLM-en får en ny oppgave, leser den alle disse filene først. Den får en fullstendig kontekst - ikke bare en prompt. Den vet hva du vil ha. Og den svarer med kode som virkelig passer til prosjektet ditt.
PRD og implementeringsplan - la LLM-en hjelpe deg planlegge
Tradisjonelt skriver du en PRD (Product Requirements Document) før du begynner. Men i vibe coding? Du lar LLM-en skrive den for deg.
Bruk en prompt som: «Skriv en PRD for en app der brukere kan legge inn og dele notater. Fokuser på enkle, grunnleggende funksjoner.» LLM-en svarer med en strukturert liste: «Bruker kan logge inn», «Bruker kan lage notat», «Bruker kan slette notat». Deretter sier du: «Lag en implementeringsplan basert på vertikal slice.»
LLM-en gir deg en rekke steg: «Steg 1: Bygg innlogging med bare brukernavn og passord.» «Steg 2: Legg til en enkel notat-liste med POST og GET.» «Steg 3: Legg til redigeringsfunksjon.»
Du sjekker planen. Endrer den. Godkjenner den. Og så går du gjennom hvert steg én etter én. Det er ikke en plan du følger. Det er en plan du bygger sammen med AI. Og det er det som gjør det så effektivt.
Refaktorering - la AI gjøre jobben for deg
En av de mest overraskende sakene med LLM-er er at de er veldig gode på refaktorering. Ikke på å skrive ny kode. På å forbedre eksisterende kode.
Den beste tilnærmingen er: «Gjør det riktig. Skriv tester. La refaktoreringen komme.» Du skriver en enkel, litt rotete versjon av en funksjon. Du skriver tester som bekrefter at den fungerer. Og så sier du: «Refaktorer denne for å gjøre den mer leselig og vedlikeholdbar.»
LLM-en vil da:
- Bytte ut lange funksjoner med små, enkle funksjoner
- Navngi variabler bedre
- Fjerne duplisert kode
- Legge til kommentarer der det mangler
Dette er en av de mest verdsatte brukene av LLM-er. Du slipper å prøve å skrive perfekt kode fra begynnelsen. Du slipper å bli forvirret av alle mulighetene. Du fokuserer på å få det til å fungere. Og så lar du AI gjøre det vakre.
Agentbasert arbeidsflyt - behandle LLM-en som en kollega
Ikke tenk på LLM-en som en smart søkemotor. Tenk på den som en ny medarbeider. En som er rask, men som må lære hvordan du tenker.
Den beste måten å jobbe med den på er en syklisk prosess:
- Gi den et problem: «Lag en funksjon som lagrer en bruker og sender en bekreftelsesmail.»
- La den generere en løsning.
- Sjekk den. Sier du: «Ikke bruk denne metoden. Bruk i stedet den vi brukte i innlogging.»
- La den prøve igjen.
- Gjenta til den får det riktig.
Dette er akkurat som å veilede en ny ansatt. Du gir tilbakemelding. Du forklarer. Du lar dem lære. Og etter noen uker, kan de jobbe selv.
Denne metoden bygger tillit. Og den bygger kvalitet. Ikke bare kode - men en kultur.
Hva er ikke en designmønster?
Det er mange ting du ikke bør gjøre:
- Ikke prøv å lage en komplett arkitektur fra begynnelsen. Det blir for mye.
- Ikke bruk LLM-en til å skrive alle testene før du har kode. Testene skal følge koden.
- Ikke la LLM-en bestemme hvordan du skal navngi ting. Du må ha en konvensjon.
- Ikke bygg en app med 10 funksjoner på én gang. Bygg én. Få den riktig. Deretter den neste.
Vibe coding handler ikke om å bruke mer AI. Det handler om å bruke AI smartere.
Sluttresultat
Designmønstrene i vibe coding er ikke kompliserte. De er enkle. Men de er nødvendige. Du trenger ikke å lære 20 nye mønstre. Du trenger å bruke fem - og gjøre det riktig:
- Vertikal slice - bygg én funksjon fullstendig
- Dokumenter arkitekturen - i en enkel fil
- Brug komponentbibliotek og maler - ikke la AI gjette utseende
- Kontekst-ingeniøring - gi LLM-en en kontekst, ikke bare en prompt
- Refaktorering og agentbasert arbeid - la AI forbedre og lære
Hvis du bruker disse fem, vil du se forskjellen. Din kode blir ikke bare raskere å skrive. Den blir lettere å forstå. Lettere å vedlikeholde. Og - viktigst - den blir en del av deg. Ikke bare en tilfeldig samling av AI-generert kode. Den blir din kodebase. Med din vibe.
Hva er forskjellen mellom vibe coding og tradisjonell koding?
I tradisjonell koding starter du med å planlegge alt før du skriver én linje kode. Du tegner arkitektur, definerer alle modeller, og skriver detaljerte krav. I vibe coding starter du med å bygge én enkel funksjon - og bygger videre fra der. Du lar koden vokse naturlig, ikke etter en fast plan. LLM-er passer perfekt til dette, fordi de er gode på å generere kode fra små, klare beskrivelser - ikke fra store, komplekse dokumenter.
Hvorfor fungerer vertikal slice så bra med LLM-er?
LLM-er blir forvirret av store, komplekse kodebasen. De gjetter, og gjetter feil. Vertikal slice reduserer kompleksiteten til én enkel funksjon på en gang. Når LLM-en ser en fullstendig, fungerende eksempel - fra database til UI - kan den kopiere stilen, strukturen og logikken. Det reduserer hallucineringer og gir koden en konsekvent struktur. Det er som å gi en lærer ett eksempel istedenfor å forklare alt fra scratch.
Hva er kontekst-ingeniøring, og hvordan brukes den?
Kontekst-ingeniøring er når du lager en mappe med regler for hvordan koden skal skrives - for eksempel .cursor/rules/coding-style.md, authentication.md, og error-handling.md. Når du spør LLM-en om å skrive kode, leser den disse filene først. Den får en hel kontekst: hvordan du navngir ting, hvordan du håndterer feil, hvordan du bygger database. Det gjør at den ikke lenger gjetter. Den skriver kode som passer til ditt prosjekt - ikke til en generell kodebase.
Bør jeg bruke en komponentbibliotek i vibe coding?
Ja. Hvis du ikke bruker et komponentbibliotek, vil LLM-en generere UI-elementer som ikke passer sammen. En knapp her, en modal der - og de ser ikke ut som de hører sammen. Et komponentbibliotek gir LLM-en en standard. Den kan kopiere stilen, fargene, avstandene, og oppførselen. Det gjør appen profesjonell - og det sparer tid. Bruk enten et offentlig bibliotek som Headless UI, eller bygg ditt eget fra tidligere prosjekter.
Hvorfor er refaktorering viktig i vibe coding?
Fordi LLM-er ikke er gode på å skrive perfekt kode fra begynnelsen. De er veldig gode på å forbedre eksisterende kode. Du skriver en enkel, litt rotete versjon av en funksjon. Du skriver tester for å bekrefte at den fungerer. Så sier du: «Refaktorer denne.» LLM-en vil da gjøre alt: navngi variabler bedre, dele opp lange funksjoner, fjerne duplisert kode, legge til kommentarer. Det er en av de mest effektive måtene å bruke AI på - og det gjør koden mer vedlikeholdbar.