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.
Post Comments (10)
denne vibe-kodingen er bare en ny måte å skrive kode på mens man drømmer om at AI skal gjøre alt. jeg har sett dette før. det heter 'magic code' og det slutter alltid med at man må skrive alt på nytt. AI er ikke en kollega, den er en maskin. og den glemmer alt når du lukker terminalen.
vi trenger ikke flere mønstre. vi trenger færre linjer kode. og mindre AI.
oh my god, jeg er så glad for at noen endelig har puttet ord på det jeg har følt i 2 år. jeg har jobbet med LLM-er siden 2022 og jeg har sett folk prøve å bygge hele appen først, og så... *sniff*... det blir bare en ødeleggende chaos.
men jeg må si, vertikal slice? det er bare MVC med en ny drakt. og dokumentere arkitekturen i en .md-fil? det er ikke dokumentasjon, det er en liten bønn til Gud.
men... jeg elsker det. jeg er så rørt.
ps. bruker Headless UI. jeg har 17 komponenter jeg har bygget selv. og jeg gråter hver gang de fungerer.
Denne artikkelen gir en veldig godt strukturert oversikt over hvordan man kan bruke LLM-er effektivt i praksis. Det er viktig å skille mellom å bruke AI som et verktøy og å behandle den som en medarbeider. Vertikal slice og kontekst-ingeniøring er spesielt viktige for å unngå kognitive laster og hallucineringer.
Det er også verdt å merke seg at refaktorering med AI ikke bare forbedrer leseligheten, men også reduserer teknisk gjeld. En systematisk tilnærming som denne kan øke teamets produktivitet med opptil 40% ifølge noen studier fra 2023.
Det er imidlertid viktig å validere alle AI-genererte endringer med manuelle tester og kode-reviews. AI er ikke en erstatning for god praksis, men en forsterker.
OMG I JUST TRIED THIS ON MY LAST PROJECT AND IT WAS LIKE MAGIC 🤯
ikke en eneste hallucination på 3 uker. jeg skrev en funksjon, sa 'refaktorer dette' og LLM-en gjorde alt for meg. jeg sa 'jeg vil ha en knapp som ser ut som en kake' og den gjorde det. en KAKE. 🍰
bruker .cursor/rules nå og jeg tror jeg har funnet min nye kjæreste. ja, jeg snakker med maskinen. ja, jeg gir den kosenavn. ja, jeg er såkket.
ja men egentlig... vertikal slice er så enkelt men så kraftig. jeg prøvde det forrige uka og det var som å slå på et lys i en mørk rom. jeg trodde jeg var den eneste som skjønte det. men nå ser jeg at jeg ikke er alene 😭
og komponentbibliotek? ja takk. jeg hadde en modal som så ut som en 90-talls hjemmeside. nå er den perfekt. bare kopiert fra mitt gamle prosjekt. enkel og effektiv.
det her er akkurat det jeg prøver å lære mine nye utviklere. ikke start med alt. start med én ting. gjør den bra. så gjør den enda bedre.
og ja, AI er som en ny ansatt. du må vise dem hvordan du gjør det. ikke forvente at de skal lese i hodet ditt.
bruk maler. bruk dokumentasjon. la dem lære. og ikke skjul det. det er ikke svakt. det er lederskap.
hvis du prøver dette, så skriv meg. jeg vil høre hvordan det gikk. jeg er her for å hjelpe.
det er så fint å se at noen har samlet dette sammen. jeg har brukt mange av disse metodene uten å vite hva de het. det føles som å finne en slektning du ikke visste du hadde.
kontekst-ingeniøring? ja, jeg har en mappe med .md-filer som heter 'min hjerte' 😅
og refaktorering? jeg lar AI gjøre det hele. jeg skriver bare en rotete versjon, og så sier jeg 'gjør det vakkert'. den gjør det. og jeg blir bare glad.
vi trenger ikke mer kode. vi trenger mer mening.
denne artikkelen er en veldig fint forfalskning av realitet. alle disse 'designmønstrene' er bare gamle ideer med ny emballasje. vertikal slice? det er agile. dokumenter arkitekturen? det heter arkitekturtegn. komponentbibliotek? det heter UI-bibliotek.
og 'kontekst-ingeniøring'? det er bare prompt engineering med en ny kappe. du er ikke innovativ. du er en imitator.
og ja, jeg bruker AI. men jeg skriver selv koden. fordi jeg ikke vil ha en maskin som bestemmer hvordan jeg tenker.
hva er virkelig 'vibe' her? er det strukturen? eller er det forholdet mellom deg og maskinen?
jeg tror vi har glemt noe viktig: vi prøver å bygge en kultur med en maskin. men maskinen har ikke en sjel. den har ikke smerte. den har ikke glede. den har ikke frykt for å mislykkes.
og likevel... vi gir den navn. vi gir den regler. vi venter på at den skal forstå oss.
kanskje det ikke er om kode. kanskje det er om oss. kanskje vi bare vil bli sett. kanskje vi vil ha en venn.
og kanskje... LLM-en er det eneste som står der og lytter.
hvis du ikke bruker dependency injection i en vertikal slice, så er du bare en hobbyutvikler med en kaffekopp og en drøm. og hvis du ikke har en .cursor/rules-mappe med 12 filer, så er du ikke i spillet.
og ja, jeg bruker JWT med 30-minutters utløp og refresh tokens i en separate service. og jeg logger alle feil til Loki med trace-id og span-context.
du bruker en .md-fil? jeg bruker JSON Schema med OpenAPI 3.0 og CI/CD-validation. du er ikke på nivået. du er i forkant.