Nogen i teamet har set en demo, hvor en app blev bygget på ti minutter ud fra en beskrivelse. Nu spørger de, om I ikke bare kan bygge jeres egne værktøjer. Det kan I godt. Spørgsmålet er, hvem der passer på dem bagefter.
Vibe coding er navnet på den måde at bygge på: I beskriver med almindelige ord, hvad værktøjet skal gøre, og AI skriver koden. For et team uden udviklere er det første gang, at et lille værktøj ikke kræver et IT-projekt. Men vibe coding i virksomheden er noget andet end vibe coding derhjemme. Derhjemme er det ligegyldigt, om appen virker om et halvt år. På arbejdet er det hele forskellen.
Det er fjerde del af vores serie om vejen fra BI til AI-drevne apps. I første del om AI og BI sorterede vi rapporterne i behold, flyt og byg. Den her handler om den sidste bunke: det, I bygger selv.
Hvad er vibe coding?
Vibe coding er at bygge software ved at beskrive, hvad den skal gøre, og lade AI skrive koden. Man retter ved at sige, hvad der er galt, ikke ved at læse koden. Andrej Karpathy, en af medstifterne af OpenAI, gav fænomenet navn i et opslag i februar 2025. Samme år kårede Collins Dictionary vibe coding som årets ord.
Værktøjerne findes i to former. De almindelige AI-assistenter kan i dag skrive og køre små programmer direkte i samtalen. Og en række app-byggere laver en hel webapp med database og login ud fra en beskrivelse. Hvilket værktøj I vælger, betyder mindre. Grænsedragningen nedenfor gælder for dem alle.
Interne værktøjer, et team kan bygge selv
Det, der virker, er de små interne værktøjer: dem, der i dag er et regneark med for mange faner, eller en opgave, én person laver i hånden hver fredag. Tre typer går igen.
Beregnere og skabeloner
En tilbudsberegner, der regner timer, materialer og avance ud fra fem felter. En formular, der laver et standardbrev ud fra en sag. Det er værktøjer med faste regler, som hele teamet bruger, og som i dag lever i en Excel-fil, kun én forstår.
Opslag i jeres egen viden
Et internt opslagsværktøj, hvor man søger i procedurer, prislister eller tjeklister i stedet for at spørge den kollega, der ved det. Indholdet findes allerede. Værktøjet gør det bare lettere at finde.
Små dataflows
En eksport fra ét system, der hver uge skal renses og sættes ind i et andet format. En liste over åbne sager, der samles fra tre mapper. Det er de opgaver, hvor et lille program sparer en time om ugen, hver uge. Holder data ikke, holder værktøjet heller ikke, så tjek datakvalitet og AI, før I bygger oven på en kilde.
Fælles for alle tre: værktøjet bruges af jeres eget team, det læser data, men skriver ikke tilbage i kundesystemerne, og det kan falde ud en dag uden at nogen kunde opdager det.
Grænsen går ved det, I kan vedligeholde
AI kan efterhånden bygge næsten hvad som helst. Derfor er spørgsmålet ikke, om I kan bygge det, men om I kan eje det. Et værktøj er ikke færdigt, når det virker første gang. Det er færdigt, når I ved, hvad der sker, den dag det holder op med at virke.
Stil de her fire spørgsmål, før I bygger:
- Hvem retter det, når det går i stykker? Et system opdaterer sit eksportformat, og værktøjet stopper. Er der en, der kan bede AI rette det i morgen?
- Hvilke data rører det? Egne tal og offentlige data er én ting. Kundeoplysninger og personaledata er noget helt andet
- Hvem bruger det? Tre kolleger i samme afdeling kan leve med en fejl. Tredive kolleger, eller kunderne, kan ikke
- Hvad sker der, når den, der byggede det, holder ferie eller stopper? Hvis svaret er, at så går det i stå, er værktøjet ikke klar til at blive brugt af andre
Det er sjældent selve bygningen, der er svær med vibe coding. Det er driften. Byg derfor kun det, I også kan vedligeholde, og start der, hvor en fejl er til at leve med.
Trafiklyset: hvad et selvbygget værktøj må røre
De fleste ledere er bekymrede for persondata, og med god grund. Men det er ikke et argument for at lade være. Det er et argument for at sortere. Vi bruger samme tre farver som i vores guide til, hvad man må dele med ChatGPT. Her handler de bare om, hvad værktøjet må have adgang til.
| Farve | Hvad værktøjet rører | Hvad der skal til |
|---|---|---|
| Grøn | Ingen persondata. Egne tal, offentlige data, interne procedurer. Bruges af jeres eget team | Byg løs. Skriv det ind i registret |
| Gul | Interne forretningsdata, fx eksporter fra økonomi eller CRM uden personoplysninger. Bruges i hele afdelingen | En ejer og en reserve, en beskrivelse på én side, og IT ved, at værktøjet findes |
| Rød | Persondata om kunder eller medarbejdere, skriver tilbage i kildesystemer, bruges af kunder eller håndterer betalinger | Byg ikke selv. Brug en prototype til at vise, hvad I har brug for, og lad IT eller en udvikler bygge det rigtige |
Det meste af det, et team har lyst til at bygge, er grønt eller gult. Den røde række er ikke et forbud mod at prøve idéen af. En selvbygget prototype med opdigtede data er en glimrende kravspecifikation.
Vibe coding uden skygge-IT
Skygge-IT er det, der opstår, når værktøjer bliver bygget og brugt, uden at nogen har overblikket. Det er IT-afdelingens største bekymring ved vibe coding, og den er berettiget. Løsningen er ikke at forbyde det. Det er at gøre det synligt. Fire ting er nok i en SMV:
- Ét register. Et delt ark med navnet på værktøjet, hvad det gør, hvilken farve det har, og hvem der ejer det. Står det ikke i registret, findes det ikke
- En ejer og en reserve. To navne på hvert værktøj, der bruges af mere end én person. Reserven skal have prøvet at rette det mindst én gang
- En beskrivelse på én side. Hvad værktøjet gør, hvor data kommer fra, og hvad man gør, når det fejler. Bed AI skrive den, når værktøjet er færdigt. Den kan beskrive sin egen kode bedre end de fleste
- En godkendelse ved gul og rød. Grønne værktøjer kræver ikke tilladelse. Gule kræver, at IT er orienteret. Røde bygges ikke af teamet selv
Med de fire ting på plads bliver IT en sparringspartner frem for en modstander. De ved, hvad der findes, og de kan sige til, hvis noget nærmer sig rødt.
Skal man kunne programmere?
Nej. Men man skal kunne beskrive et problem præcist. De bedste værktøjer, vi ser, er bygget af folk, der kender deres eget arbejde ned til detaljen: controlleren, der ved præcis, hvordan en kreditnota skal regnes, eller koordinatoren, der kender alle undtagelserne i vagtplanen.
Det, der kræver træning, er at teste. AI bygger det, I beder om, ikke det, I mener. Derfor skal I prøve værktøjet af på tal, I kender svaret på, før andre begynder at bruge det. Det er samme disciplin som i resten af serien: kend jeres kontrolsum.
Kom i gang med vibe coding i teamet
Vælg én grøn opgave, der i dag tager tid hver uge, og som kun jeres eget team bruger. Byg en første version på en eftermiddag. Brug den selv i to uger. Virker den, så skriv beskrivelsen, find en reserve, og sæt den i registret. Først derefter deler I den med resten af afdelingen.
Næste del af serien viser, hvordan det ser ud, når man går hele vejen: vi har selv bygget Proptechguiden, en guide med over 130 leverandører, på den måde, og vi fortæller, hvor det knækkede undervejs.
Vil I lære det sammen med teamet, er det netop indholdet i afsnittet om programmering uden udvikler-baggrund på vores Claude-firmakursus, hvor I bygger på jeres egne opgaver. Den mere tekniske side kan I se i vores gennemgang af Claude Code for vidensarbejdere. Handler det mere om, hvordan I organiserer det på tværs af virksomheden, så er det AI-rådgivning.
Hvad skal jeres team bygge først?
Vi kigger på jeres opgaver sammen med jer og peger på de to eller tre værktøjer, der giver mest, og som I kan eje selv. Så starter I det rigtige sted.
Se også, hvordan teamet bygger på et firmakursus.
Paw Lundin
Stifter af Digital Forlomme. 15+ års erfaring med digitalisering, først som intern leder, nu som rådgiver. Underviser, implementerer og rådgiver.
Ofte stillede spørgsmål om vibe coding
Hvad er vibe coding?
Vibe coding er at bygge software ved at beskrive med almindelige ord, hvad den skal gøre, og lade AI skrive koden. Man retter ved at fortælle, hvad der er galt, frem for at læse koden. Begrebet blev navngivet af Andrej Karpathy i februar 2025.
Kan man bruge vibe coding uden at kunne programmere?
Ja, til små interne værktøjer som beregnere, opslagsværktøjer og simple dataflows. Det vigtigste er at kunne beskrive problemet præcist og teste resultatet på tal, man kender svaret på.
Hvad bør et team ikke bygge selv med AI?
Værktøjer, der behandler persondata om kunder eller medarbejdere, skriver tilbage i kildesystemer, bruges af kunder eller håndterer betalinger. Dem kan teamet godt lave en prototype af, men den rigtige løsning bør bygges af IT eller en udvikler.
Hvordan undgår man skygge-IT med vibe coding?
Med et fælles register over alle værktøjer, en ejer og en reserve på hvert værktøj, en beskrivelse på én side og en regel om, at IT orienteres, når et værktøj rører interne forretningsdata. Det gør værktøjerne synlige i stedet for at forbyde dem.
Hvem skal vedligeholde et værktøj, teamet har bygget?
Den, der byggede det, plus en navngiven reserve, som har prøvet at rette det mindst én gang. Har værktøjet ingen reserve, bør det kun bruges af den, der byggede det.
Hvor lang tid tager det at bygge et internt værktøj med AI?
En første version af et simpelt værktøj kan ofte bygges på en eftermiddag. Det, der tager tid, er at teste det, skrive beskrivelsen og få det på plads i hverdagen, så andre kan bruge det trygt.