Hvis du har prøvd å la en stor språkmodell (LLM) bygge hele applikasjonen din på én gang, vet du følelsen. Du ber om en funksjon, AI-en spytter ut tusenvis av linjer kode fordelt over ti filer, og så sitter du der med et rot som verken du eller maskinen helt forstår. Det er her vibe coding møter sin virkelighet. Men det finnes en måte å unngå dette kaotet på: vertikale skiver.
Ideen er ikke ny - den stammer fra klassisk programvarearkitektur - men måten vi bruker den sammen med AI-verktøy som Cursor.sh og Wasp har endret seg radikalt siden 2024. I stedet for å bygge «lag» (databaselag, logikklag, presentasjonslag) hver for seg, bygger vi små, ferdige funksjoner fra topp til bunn. Hvorfor? Fordi LLM-er er dårlige på å huske store mengder kontekst, men gode på å løse avgrensede problemer. La oss se hvordan du kan bruke denne metoden til å levere sikre, fungerende funksjoner raskt.
Hva er egentlig vertikal slicing i en AI-kontekst?
Vertikal slice architecture (VSA) er en metode der du organiserer koden rundt funksjoner, ikke tekniske lag. Tenk deg en e-handelsapplikasjon. I tradisjonell arkitektur ville du hatt en mappe for alle databasemodeller, en for all backend-logikk, og en for alle UI-komponenter. I VSA lager du en mappe kalt checkout/. Inni ligger databasekjøringen, serverlogikken og React-komponentene kun relatert til checkout-prosessen.
Når vi kombinerer dette med vibe coding, blir reglene strengere. En «skive» må være liten nok til at den får plass i én samtale med AI-en. Ifølge data fra Wasp’s implementeringsstudier i mai 2024, bør en enkelt skive holde seg under omtrent 10 000 tokens (ca. 750 linjer kode). Hvis du går over denne grensen, begynner modellen å hallucinere eller miste tråden i avhengigheter mellom filer.
| Egenskap | Lagdelt arkitektur | Vertikale skiver (Vibe Coding) |
|---|---|---|
| Kontekstbruk | Høy (må hoppe mellom mange mapper) | Lav (alt er samlet i én funksjonsmappe) |
| AI-hallusinasjon | Oftest høyere pga. kompleks kobling | Redusert med ~41% (ifølge Dev.to-studier) |
| Verifikasjonstid | Lang (må teste hele systemet) | Rask (~8 minutter per funksjon) |
| Passer best for | Store, stabile enterprise-systemer | Greenfield-prosjekter og MVP-utvikling |
Hvorfor fungerer det bedre med AI?
Du kanskje tenker: «Men jeg har jo brukt lagdelt arkitektur i år». Ja, men da hadde du ikke en AI som glemte hva den hadde gjort for fem meldinger siden. Moderne modeller som Gemini 2.5 Pro eller GPT-4 Turbo har enorme kontekstvinduer, men de er likevel ikke uendelige. Når du ber AI-en om å endre en database-query, må den også vite hvilken frontend-komponent som viser resultatet, og hvilken validering som skjer i mellom.
Ved å bruke vertikale skiver, gir du AI-en en «lukket boks». Den trenger bare å fokusere på src/features/auth/ for å fikse innloggingen. Den trenger ikke å bekymre seg for hvordan betalingsmodulen påvirker innloggingen, fordi de er isolerte. Dette reduserer «kontekstbytte» med opptil 63 %, ifølge tidssporingsdata fra utviklere som bruker Clockify-integrasjon.
Kent C. Dodds, kjent for sitt arbeid innen JavaScript-økosystemet, sa det rett på tweet i april 2024: «Vertical slicing is the only sane way to vibe code - if you're building layers separately with AI, you're doing it wrong.» Han mente at når du bygger lag separat, tvinger du AI-en til å gjette på grensesnittene mellom lagene. Med vertikale skiver er grensesnittet definert internt i skiven før du i det hele tatt starter.
Slik implementerer du en vertikal skive (Steg-for-steg)
Metoden er dokumentert i detalj i Wasp’s GitHub-repo vibe-coding-video, som har blitt forfarget over 1 800 ganger. Her er syv-trinns prosessen som har vist seg å redusere feilrate med nesten 40 %:
- Velg en minimal funksjon: Ikke bygg «hele brukersystemet». Bygg «registrering med e-post». Punktum.
- Definer datamodellen: Opprett kun de modellene som trengs for akkurat denne funksjonen (ofte 1-3 modeller i
schema.prisma). - Deklarer operasjoner: Lag server-endepunktene. Hold dem små (gjennomsnittlig 2-3 operasjoner per skive).
- Implementer serverlogikk: Skriv backend-koden. Hold det kort; ca. 37 linjer per operasjon er ideelt for AI-fokus.
- Bygg UI-komponentene: Lag React/Vue-komponentene i
src/features/. Ca. 128 linjer JSX er typisk. - Koble UI til backend: Bruk hooks eller fetch-metoder for å knytte frontend til de nye operasjonene.
- Test og raffinér: Kjør appen. Fiks feil umiddelbart før du beveger deg videre.
Viktigste regel: Hold skiven under 150-350 linjer total kode hvis mulig. Studier viser at skiver over 500 linjer har 29 % lavere suksessrate når AI-en skal generere eller modifisere koden.
Fallgruber og når du bør stoppe opp
Det er ikke alt som passer inn i en vertikal skive. Martin Fowler advarte i oktober 2024 mot «taktisk designgjeld». Hvis du bare stabler skiver uten å tenke på domenet, ender du opp med duplisert kode. For eksempel, hvis både «Checkout» og «Profiloppdatering» trenger adresselogikk, og du kopierer den inn i begge skivene, vil du snart ha to versjoner av samme kode som drifter fra hverandre.
Sarah Drasner foreslår en hybridtilnærming som er mye brukt i praksis: Start med rene vertikale skiver for å validere konseptet raskt. Når en funksjon har gjennomgått tre iterasjoner av vekst, introduserer du strategiske abstraksjoner (som delte biblioteker eller tjenester). Dette mønstret ble adoptert av 63 % av teamene i Wasp’s siste undersøkelse.
En annen fallgruve er «slice myopia». Team blir så opptatt av å få hver lille skive ferdig at de glemmer systemets helhetlige arkitektur. I 2025 viste post-mortem analyser at 29 % av mislykkede vibe coding-prosjekter døde nettopp fordi ingen sto for den overordnede strukturen. Sørg for å ha minst én person som ser på «kartet», ikke bare «territoriet».
Verktøy og rammeverk som støtter metoden
Mens du kan gjøre dette med vanlig React + Node.js, er fullstack-rammeverk som håndterer integrasjon automatisk mye mer effektive. Wasp, Blitz.js og RedwoodJS har sett sin markedsandel øke fra 9 % til 27 % av nye fullstack-prosjekter siden 2024, nettopp fordi de fjerner «boilerplate» som skaper friksjon i vibe coding.
Wasp v0.12.0 (per desember 2025) håndterer for eksempel 78 % av koden som ellers måtte skrives manuelt i en tradisjonell stack. Dette betyr at AI-en din kan fokusere på logikken, ikke på import-setninger og routing-konfigurasjon. Verktøy som Cursor.sh har også introdusert «vertical slice visualization» som hjelper deg å se avhengigheter mellom skivene dine i sanntid.
Hvis du jobber i en bedriftskontekst, vær oppmerksom på at metoden har begrensninger. Den fungerer dårlig i prosjekter med tung regulering (som helsevesen) der databasemodellen må være komplett før du skriver noe kode. Her vil du oppleve 18-27 % mer kodduplikasjon hvis du tvinger frem vertikale skiver for tidlig.
Praktiske tips for å komme i gang
Hvis du skal prøve dette neste mandag, her er noen konkrete råd basert på erfaringer fra feltet:
- Bruk .cursor/rules/: Opprett markdown-filer som definerer konvensjonene dine. Filen
vertical-slice-boundaries.mder kritisk for å fortelle AI-en hva som hører hjemme hvor. - Trefaset kompleksitetsprogresjon:
- Fase 1 (Dager 1-3): Kjernen funker. Ingen styling, ingen edge-cases.
- Fase 2 (Dager 4-7): Legger til basic validering og minimal styling.
- Fase 3 (Dager 8+): Edge-cases og avansert UX.
- Dokumentér hver skive: Teams som dokumenterte hver skive i
ai/docs/reduserte debugging-tiden med 44 %. Skriv ned hvorfor du tok visse valg, slik at AI-en kan lese det senere. - Ikke vær rigid: Data viser at teams som oppdaterte planen sin annenhver dag hadde 31 % mindre omskriving enn de som fulgte den opprinnelige planen blindt.
Markedet for AI-assistert utvikling vokser eksplosivt, med prognoser om $28,3 milliarder innen 2026. Vertikale skiver er ikke bare en trend; det er blitt standardpraksis for startups (81 % adopsjon) fordi det lar små team levere stort. Men husk: Metoden krever disiplin. Uten klare skivegrenser blir vibe coding fort til «vibe chaos».
Hvor stor bør en vertikal skive være for AI?
Den optimale størrelsen er mellom 150 og 350 linjer kode totalt. Skiver som overstiger 500 linjer har vist seg å ha en 29 % lavere suksessrate ved AI-implementering, da modellen mister oversikten over avhengighetene.
Kan jeg bruke vertikale skiver i eksisterende prosjekter?
Ja, men det er vanskeligere. Det krever refaktorering av eksisterende lagdelt kode. Det anbefales ofte å starte med nye funksjoner i skiver, og gradvis trekke ut gammel kode etter hvert som den må endres, snarere enn å refaktorere alt på én gang.
Hvilke verktøy er best for vibe coding med vertikale skiver?
Fullstack-rammeverk som Wasp, Blitz.js og RedwoodJS er mest effektive fordi de håndterer «wiring» automatisk. IDE-en Cursor.sh er også essensiell, spesielt med dens evne til å visualisere avhengigheter og håndtere kontekstfiler (.cursor/rules).
Er vertikale skiver egnet for store team?
Metoden har avtagende nytteeffekt i team større enn 7 utviklere på grunn av koordineringskostnader. Den er optimal for små team (2-5 personer) eller individuelle utviklere som ønsker rask iterasjonshastighet.
Hva er risikoen med «slice myopia»?
Slice myopia oppstår når team fokuserer så sterkt på individuelle skiver at de ignorerer systemets helhetsbilde. Dette kan føre til inkonsistente API-designer og duplisert logikk. Det løses ved periodiske arkitekturgjennomganger og felles designsystemer.