Vibe coding, eller vibbekoding på norsk, kan by på muligheter både for oss som jobber med systemutvikling og for deg som ikke har noe forkunnskap. Her er min guide til hvorfor, når og hvordan du lykkes med disse verktøyene.
KI-assistert utvikling tok verden med storm med lovnader om gull og grønne skoger. I februar 2025 formaliserte Andrej Karpathy, medgrunnlegger av OpenAI, utviklingsmetodikken døpt «vibe coding» med denne tweeten.
Kort fortalt foreslår Karpathy, som også er tidligere «director of artificial intelligence» hos Tesla, en tilnærming til utvikling som baserer seg på å la KI’en ta førersetet fullstendig.
Mange var raske til å kaste seg på bølgen – ikke bare i IT-bransjen, men særlig også utenfor. En front av ikke-tekniske nysgjerrige skapere, armert med manglende kunnskaper om sikkerhet, programvarearkitektur og DevOps ble møtt med kraftige motreaksjoner fra et skeptisk IT-miljø.
I kjølvannet av all velfortjent kritikk vibe coding mottok, har den underliggende teknologien og verktøy rundt det ulmet og fått rotfestet seg i bakgrunnen. For allmennheten har i skrivende stund mer visuelle verktøy som Base44, Lovable og Bolt blitt svært populære alternativer, og for oss fagfolk har særlig GitHub Copilot vevd seg dypere og dypere i utviklingsverktøyene våre. Vi står overfor en tid hvor vår rolle som utviklere forandres markant, men vi kan ikke slippe hendene fra rattet riktig enda – for å lykkes må vi følge med på veien.
For en solid intro til hva vibbekoding er, anbefaler jeg å lese denne artikkelen fra min kollega, Eivind
Før vi ser nærmere på hvorfor, når og hvordan vi jobber med verktøyene, behøves litt begrepsavklaring:
Assistansespekteret
I figuren over ser du mitt egendefinerte spekter som beskriver mengden og kvaliteten på hjelp og tilbakemelding fra maskin til utvikler. Assistert kode er i denne sammenheng noe vi alle allerede har et forhold til, helt siden vi tastet vår første spaghettikode…”
- På den ene siden av spekteret har vi kompilatorassistanse, som ble tilgjengeliggjort så tidlig som på 50-tallet da Fortran kom.
- Videre har vi IntelliSense, som har eksistert i varierende kompleksitet, siden 1996.
- I nyere tid har utviklingsmiljø som VS Code integrert mer primitive maskinlæringsmodeller som med IntelliCode først ble tilgjengelig i 2018. Disse har senere blitt byttet ut med modeller basert på mer sofistikerte nevrale nettverk.
- På den ekstreme motpolen til kompilatorassistanse finner vi apokalyptisk brain-rot vibbekoding, der utviklerene så vidt har oppmerksomhetsspenn til å taste prompts til en server, og godtar blindt generert kode fordi de ikke orker å lese resultatet.
I denne artikkelen tar jeg men noen friheter og velger å bruke vibe coding som et samlebegrep som inkluderer all interaktiv KI-assistert utvikling der KI’en står som fører. Altså er et par hakk i konservativ retning på aksen vår også å betrakte som vibe coding i denne artikkelen.
Hvorfor?
Så hvorfor er vibe coding enda noe vi alle bør sette oss inn i? Når kan det i det hele tatt lønne seg å dele førersetet med KI’en?
Om vi beveger oss noen få hakk i konservativ retning på assistentspekteret, lander vi kanskje på en plass hvor KI enda står relativt sentralt i utviklingssyklusen. En plass hvor vi benytter oss av de nyeste verktøyene, og tar inspirasjon fra mer ekstreme metodikker. En plass hvor organisasjoner har nok oversikt over rammene rundt bruken til å anse det som trygt. Her vil vi kanskje finne en trygg havn hvor vi er i kontroll og kan skape noe som faktisk virker til sin hensikt, med vesentlig raskere leveransetid.
Funksjonelle- og ikke-funksjonelle krav
All kode vi skriver har i hensikt å innfri to kategorier krav: funksjonelle og ikke-funksjonelle.
Funksjonelle krav er kravene en kunde eller bruker ville formulert. De er brukerrettede og verifiserbare som for eksempel «når jeg trykker på denne knappen, skal en liste med mine nærmeste kollegaer vises». Ikke-funksjonelle krav handler mer om hvordan vi bygger systemer tenkt til å innfri disse kravene. Eksempler på dette kan være «systemet skal bygges modulært slik at vi kan utvikle det i lang tid fremover», eller «systemet skal være sikkert, og skal forhindre uautorisert tilgang». Disse kravene gir utsprang til prinsippene vi utviklere er vant til å rette oss mot, og relateres ofte med code craftsmanship. Kort fortalt handler det om hva systemet vårt skal yte vs hvordan systemet vårt skal yte.
Dagens LLM’er (large language models) klarer helt fint å innfri en haug med funksjonelle krav vi stiller til systemet vårt. Der de derimot ofte sliter, er på de ikke-funksjonelle kravene. De har ikke den samme helhetlige forståelsen av organisasjon, behov og kultur som oss, og dette gjenspeiles fort i koden den lager. La oss se på et kort konkret eksempel av dette. Eksempelet blir satt noe på spissen, og vi skal senere se på hvordan prompt engineering vil gi oss bedre kvalitative resultater, men poenget står enda.
Task manager
Jeg ba GPT liste 10 funksjonelle krav for vår gode, gamle venn task manager/TODO app. I et helt blankt prosjekt i VS Code serverte jeg agenten med kravene én etter én, uten kontekst. De eneste gangene jeg avveik fra å bare sende funksjonelle krav var når resulterende kode ikke fungerte som ønsket. Videre ga jeg en instruks om at dette skulle være en webapplikasjon som eneste kontekst. Kravene er:
- Task Creation
The system shall allow users to create new tasks with a title and optional description. - Task Editing
The system shall allow users to modify existing task details. - Task Deletion
The system shall allow users to remove tasks from the list. - Task Listing
The system shall display all created tasks in a list view. - Task Status Update
The system shall allow users to mark tasks as “pending” or “completed” - Search & Filter
The system shall allow users to search for tasks by keyword and filter by status. - Persistent Storage
The system shall save tasks locally in the browser (e.g., localStorage) so they remain after refresh. - Sorting
The system shall allow users to sort tasks by creation date or status. - Responsive Design
The system shall adapt its layout for both desktop and mobile screens. - Undo Last Action
The system shall allow users to undo their last action (e.g., deleting or editing a task).
Resultatet fra omrking 4 minutter med prompting og verifisering er en kodebase som består av 3 monolittfiler, *
- index.html → 138 linjer med kode
- styles.css → 738 linjer med kode
- script.js → 796 linjer med kode
samt en velfungerende applikasjon med et minimalistisk og rent grensesnitt, en konsoll som logger debug-kode og en menneskelig utvikler som ikke orker tanken på å ta en kodegjennomgang på rotete plain JavaScript kildekode.
Vi har altså et verktøy som er i stand til å skape et system som innfrir en rekke funksjonelle krav av relativt lav kvalitet, men på veldig kort tid. Vi kan se disse egenskapene sammen med hvordan de kommer til liv i et Venn diagram:
Der i midten. I stormens øye, hvor hurtig utvikling møter funksjonelle krav og lite gjennomtenkt arkitektur, finner vi prototyper og proof of concepts. Disse typer systemer er ment til å kommunisere ideer, etablere kort feedbackloop mellom utviklingsteam og kunde, og gi oss en bedre selvsikkerhet på «market fit». Dette må vel være en god kandidat for vibe coding?
Hvordan kommer du i gang?
Fjo! Lang intro! Heldigvis er jeg ufattelig flink på introduserende tankestrømmer, men konkluderer relativt raskt.
La oss se litt nærmere på hvordan man faktisk kommer i gang med vibe coding. Her tas det utgangspunkt i VS Code, men det aller meste av hva vi skal gjennom skal det være tilsvarende støtte for i andre utviklingsmiljøer også. Før du starter, kan det være lurt å sette seg inn i ditt selskap sine retningslinjer for bruk av KI verktøy. Videre trenger du også en lisens på GitHub Copilot. Om du planlegger å bruke verktøyet på jobb kan du høre med din nærmeste leder om hvordan du får tak på et slikt.
VS Code Copilot
Vi tar først en rask gjennomgang av de elementære elementene i VS Code sin Copilot integrasjon. Om du er bekvem på det grunnleggende kan du hoppe over til neste seksjon.
Chatvindu
I VS Code er Copilot godt integrert. Fra AI chat-vinduet har vi et par nøkkelelementer som chatvinduet, modusvalg og modellvalg. Chatvinduet er kanskje relativt selvforklarende – dette er hvor du kommer til å prompte agenten. I chathistorikken vises alle prompts du har sendt samt KI’ens tankestrøm. Chatten blir med jevne mellomrom oppsummert internt, slik at prosjektforståelse og brukerpreferanser bevares. Vi skal se på hvordan du kan skreddersy dette litt senere.
Når du jobber med en spesifikk del av kodebasen, kan det være lurt å hjelpe KI’en med et utgangspunkt. Her er prompt-kontekster hendig. “Add Context” lar deg legge til blant annet filer, bilder, søkeresultater og konsollmeldinger til prompten din. Filen du har åpen i editor legges automatisk til som kontekst.
Modus
Modusvelgeren lar deg velge mellom forskjellige moduser. En modus er som en slags personlighet du gir LLM’en, men mer sofistikerte moduser setter også føringer for hva KI’en får lov til å styre på maskinen din. VS Code kommer med tre forhåndsdefinerte moduser:
- Ask: ren samtale. All interaksjon foregår i chat-vinduet.
- Edit: lett, kontrollert redigering. Du velger selv hva KI’en skal redigere, og den foreslår endringer du må godta før koden lagres til fil.
- Agent: helautomatisert opplevelse. KI’en kan lage, lese, skrive og lagre filer, eksekvere kommandoer i terminal og, avhengig av organisasjonsbegrensninger, hente data fra verdens vide nett.
Er du usikker på hvor du skal begynne, velger du agent mode. Denne kommer med alt du trenger, og ettersom at du er nødt til å eksplisitt godkjenne alle kommandoer og web-besøk, kan du gjøre deg trygg på at det enda er du som er det svakeste leddet. Vi kommer til å se på hvordan vi kan lage våre egne moduser om noen strakser.
Modell
Modellvelgeren lar deg velge hvilken underliggende LLM som skal jobbe med koden din. Her kan du velge mellom litt tregere premium-modeller, som teller på den månedtlige kvoten din, eller gratismodeller som ikke er like sofistikerte. Ofte holder gratismodellene, men dersom du skal gjøre store refaktoreringer på tvers av kodebasen din, eller dersom problemet som skal løses er mer komplisert, kan det være lurt å velge en av de tyngre modellene. Det er ikke uvanlig å bytte mellom de forskjellige modellene i arbeidsflyten.
Klar?
Så er det vel bare å komme i gang da vel?
Start med å gi KI’en en enkel instruks for å se hvordan flyten fungerer. I VS Code blir all KI-kode presentert for deg i en diff-view som ligner litt på conflict editoren. Her kan du velge å beholde enkelte linjer, hele filer eller alle filendringene maskinen har foreslått.
Avslutningsvis i artikkelen følger det noen gode råd om metodikken, samt litt mer avansert bruk av verktøyet. Lykke til!
Bedre kode, takk!
Avslutningsvis skal vi se på litt mer avansert bruk, som vil kunne brukes til å produsere kode bedre tilpasset prosjektstørrelser vi i Bouvet ofte jobber med, samt noen personlige råd og erfaringer. Helt til slutt ser vi på hvordan dette viser seg i den overnevnte TODO-appen.
Chatmodes
Chatmodes er hvor du kan lage egne moduser i tillegg til de predefinerte modusene som følger med. En chatmode er en forhåndsgenerert markdown-fil med en frontmatter som sendes inn ved hver prompt. Forbi de forhåndsdefinerte modusene som følger med VS Code, kan det være hjelpsomt å definere moduser som for eksempel en arkitekt-agent som hjelper deg med kodebasen på et overordnet nivå eller en tester som hjelper deg med å skrive gode enkle tester. Du kan lese mer om chatmodes [her]
Det foregår mye eksperimentering i KI-miljøene rundt å finne chatmodes som passer til forskjellige formål. Sjekk for eksempel ut [awesome copilot chatmodes] repoet for inspirasjon.
Instructions
Instruksjoner hjelper deg med å definere brukerpreferanser til kodebasen eller for å gi tilleggsinformasjon om prosjektet. De er svært nyttige, spesielt i startfasen av et prosjekt fordi KI’en har så lite kontekst fra start. De defineres på lik linje som chatmodes, altså markdown-filer med frontmatter. Typiske instrukser kan for eksempel være konsistent bruk av UI-biblioteker eller design patterns du ønsker å holde deg til, eller spesifikke instrukser. Du kan lese mer om instrukser [her].
Noen personlige råd og erfaringer
Dersom du planlegger å bruke teknologien i prosjekter på eksisterende kodebase kan det være lurt å være varsom på at KI’en ikke har samme historiske kontekst vi som har jobbet med kodebasen har. Den har ikke deltatt i utallige Teamsmøter. Den har ikke idémyldret over kaffe, kaker og kos. Den har ikke tatt på seg teknisk gjeld i viten om at det gjøres for the greater good. Det du gir, er det den har av kontekst. I min mening er det nettopp i mangelen på kontekst at vi ser de største svakhetene til KI-generert kode. Ikke nødvendigvis bare i en mangelfull teknologi.
Det samme må gjelder dersom du velger å starte et nytt prosjekt med KI-partneren din. I startfasen har du ofte mindre modne tanker om hva det er du skal bygge, og dette kan fort gjenspeile seg i kodeforslagene. Det er verdt å nevne at dette også kan utnyttes som en styrke. “Hvor skal jeg starte?” er et spørsmål de fleste av oss har tenkt før første kodetast går. La partneren din forsøke å finne ut av det! Vi er mye bedre på å peke på ting vi ikke liker enn å tenke oss til hva vi trenger.
Finn tempoet og mengden menneskelig involvering som fungerer best for deg, ditt team og systemets formål. Om du blindt aksepterer all kode KI’en foreslår, mister du fort kontroll over kodebasen. Dette gjør oss helt avhengige av KI’en for å fikse feil, noe som kan være veldig frustrerende dersom kodebasen er stor og vond. Sett gjerne opp en filstruktur som gir mening for deg og dere. Strukturen vil gi KI’en hint om hvordan du ønsker at koden skal organiseres, og du blir mer våken på den overordnede arkitekturen.
Refaktorer! Personlig erfaring viser at KI’en har tendens til å produsere enklere og renere kode dersom kodebasen din er velorganisert og strømlinjeformet. Om du kjenner at kompleksiteten og mengden spaghetti vokser stadig over tid, kan du be noen av de mer sofistikerte modellene om å refaktorere koden med noen spesifikke endringer i hovedfokus. Dette er også en fin måte å eliminere bugs på, da en ny gjennomgang av kode i lys av ny kunnskap ofte kan føre til høyere abstraksjonsnivåer.
TODO 2: Electric Boogaloo
La oss kort gjenbesøke TODO-appen vår med alt vi har lært så langt.
Jeg kommer til å definere tre agenter:
- architect : For å iterativt idémyldre behov og tekniske begrensninger rundt systemet jeg ønsker.
- prompt-designer: For å generere effektive promtpts basert på hvor i utviklingsløpet vi er.
- beastmode: En forhåndsdefinert modus som gir greie koderesultater.
Og lager en `requirements.instructions.md` fil som inneholder de 10 funksjonelle kravene listet tidligere.
Jeg starter med å sparre litt om hva jeg ønsker med arkitekten. Den spør meg om hvilke teknologier og rammeverk meg og mitt team er komfortable med, og følger opp med spørsmål rundt disse. Den spør om ønsket plattform, antall utviklere i teamet, lagring av data og hvordan jeg ser for meg at applikasjonen skal skalere. Jeg forteller den at jeg i all hovedsak er interessert i å kjøre applikasjonen lokalt, men ønsker ett oppsett som lar seg lett distribuere. Videre ønsker jeg at systemet skal bygges på en måte som lar meg ekspandere på funksjonaliteten i fremtiden, men at de funksjonelle kravene holder for denne gang. Resultatet av sparresesjonen er et dokument som definerer det overordnede systemet, hvilke teknologier som skal benyttes, elementære interfaces og en roadmap for hvordan vi skal bygge applikasjonen. Dette dokumentet gir jeg til prompt-designeren som kondenserer det til en prompt-fil jeg bruker som kontekst til beastmode.
Hele seansen tok denne gang rundt 15-20 minutter. Jeg har ikke sett stort på koden som ble generert, men å navigere i kodelandskapet er en mye triveligere opplevelse enn før. Agenten har respektert SOLID prinsippene, lent seg på veletablerte bibliotek og rammeverk, og skrevet kode ment for å vare. Om du ønsker å se detaljer rundt prompts, moduser brukt eller bare inspisere koden selv finner du den [her].
Funksjonelt er applikasjonen identisk vår første iterasjon, men det er hva som foregår bak kulissene som utgjør det store forskjellen. Dette er en kodebase jeg har lyst til å jobbe med fremover.
