Vibe-kodning efter bryllupsrejsen
· 6 min read · Filippo Spinella · AI, Coding, Agents, Developer Tools
Vibe-kodning er et af de udtryk, der synes født til at blive hadet og derefter langsomt bliver nyttige.
Først lyder det som: Jeg tror ikke, jeg spørger AI, jeg accepterer det, der kommer ud, fortsæt. En munter måde at producere teknisk gæld på med en musikalsk baggrund.
Men det ville være for nemt at afvise det sådan. Sandheden er, at vibe-kodning har opsnappet en rigtig ting: programmering med en model ændrer forholdet mellem idé og prototype.
Først fik du en tanke og så en lang stigning. Nu har man ofte en tanke, og en halv time senere bevæger der sig noget på skærmen. Det er svært ikke at lade sig forføre af det.
Det interessante spørgsmål i 2026 er ikke, om vibe-kodning er sand. Det er det. Spørgsmålet er: hvad sker der efter bryllupsrejsen?
Prototypen er blevet økonomisk
Dette er den vigtigste del.
AI-værktøjer har sænket de følelsesmæssige omkostninger ved at komme i gang. Før, hvis du ville prøve en idé, var du allerede nødt til at lægge arbejdet ind: Vælg stak, lav projekt, husk boilerplate, skriv layout, tilslut API'er, skændtes med kedelige detaljer.
Nu kan du sige: giv mig en første version.
Og en første version kommer.
Ikke altid smuk. Ikke altid korrekt. Ofte skrøbelig. Men det kommer. Og når den ankommer, ændrer den samtalen. Du skændes ikke længere i et vakuum. Du rører ved noget.
Dette er meget kraftfuldt for designere, grundlæggere, produktchefer, seniorudviklere, der er trætte af at omskrive stilladser, nysgerrige mennesker, der ikke ville have åbnet en redaktør før.
Vibe-kodning er hype, fordi det giver flere mennesker den fysiske fornemmelse af softwaren, der skabes.
Problemet er, at softwaren lever videre
Den del, som meme fortæller mindst, er dagen efter.
Prototypen skal læses. Korrekt. Testet. Indsat. Sikret. Fik det af en anden. Forbundet til rigtige data. Gøres tilgængelig. Vedligeholdes, når en afhængighed ændres.
Her rammer ren vibe-kodning muren.
En model kan hurtigt generere meget kode, men kode er ikke værdi i sig selv. Det er et løfte om adfærd. Og et løfte skal bekræftes.
Risikoen for vibe-kodning er ikke at skrive grim kode. Vi har altid gjort det selv uden AI. Risikoen er at miste følelsen af ejerskab: "modellen gjorde det" bliver en undskyldning for ikke at forstå nok.
Men køretiden accepterer ikke undskyldninger. Hvis koden kører i produktion, er den din.
Fra vibe-kodning til agentteknologi
Den modne version af vibe-kodning er ikke at stoppe med at bruge agenter. Det er at bruge dem med en mere seriøs cyklus.
Ikke: det genererer alt, og vi håber.
Men:
- beskriv hensigten;
- lad generere et udkast;
- bede agenten om at forklare planen;
- lav små forskelle;
- lanceringstests;
- lave anmeldelser;
- korrekt;
- først derefter deltage.
Denne ting fortjener et andet navn. Jeg kan godt lide agent engineering, selvom det lyder lidt højtideligt. Det betyder at bruge agenter ikke som spilleautomater, men som samarbejdspartnere i en ingeniørproces.
Pointen er ikke at tage energi fra vibe-kodning. Det giver hende spor.
Hvor det fungerer fantastisk
Vibe-kodning fungerer, når omkostningerne ved fejl er lave, og værdien af udforskning er høj.
Eksempler:
- grænsefladeprototyper;
- personlige værktøjer;
- interne dashboards;
- små spil;
- engangsscript;
- API-scanninger;
- proof of concept;
- mekaniske refaktorer med gode tests;
- teknisk indhold, der skal omdannes til demoer.
I disse tilfælde er hastigheden pointen. Du vil gerne se, om ideen har ben. Du vil gerne finde ud af, hvad du ikke forstod. Du ønsker at komme til en konkret samtale.
Vibe-kodning er perfekt til at få form til at opstå.
Hvor det bliver farligt
Det bliver farligt, når systemet får konsekvenser, og ingen bremser.
Betalinger, personlige data, godkendelse, tilladelser, infrastruktur, databasemigreringer, følsom ældre kode, compliance, produktion. Her er stemningen ikke nok. Vi har brug for stringens.
Det betyder ikke, at AI ikke kan hjælpe. Faktisk kan det hjælpe meget. Men det skal fungere inden for snævre rammer: gren, sandkasse, test, lint, anmeldelse, feature flag, rollback.
Sætningen, der skal tatoveres på skærmen, er enkel: Jo hurtigere agenten er, jo mere læsbar skal processen være.
Hvis du ikke kan forklare, hvad der er ændret, har du ikke accelereret. Du har lige flyttet gælden fra tid til at forstå.
Udviklerens nye rolle
Det mest interessante er, at udviklerens job ikke forsvinder. Skift tæthed.
Mindre tid på kedelplade. Mere tid til intention, nedbrydning, gennemgang, integration, test, grænser.
Udvikleren bliver en slags teknisk redaktør. Ikke i den haltende betydning af "korrekturlæsning". I stærk forstand: det bestemmer, hvad der skal eksistere, hvad der skal skæres, hvad der er i overensstemmelse med systemet, hvad der fortjener tillid.
En god redaktør tager ikke alt, hvad de får. Han omskriver ikke engang det hele af stolthed. Genkender godt stof, bringer det til form, beskytter læseren.
Hos agenter er læseren også fremtidens vedligeholder. Ofte er det dig om tre uger.
Det mønster, jeg ser dukke op
Det sundeste mønster er dette:
- menneskelig: hensigt, begrænsninger, smag, ansvar;
- agent: varianter, stilladser, søgning, lokale ændringer, gentagne tests;
- Infrastruktur: sandkasse, CI, sporing, tilladelser, implementering;
- team: gennemgang, ejerskab, standarder.
Når en af disse stykker mangler, bliver noget deformeret.
Eneste menneskelige: langsom, ofte bundet af gentagne arbejde.
Kun agent: hurtig, men uden situerede dømmekraft.
Bare infrastruktur: Elegant proces til at producere ubrugelige ting.
Kun team: meget velordnede møder omkring en prototype, der aldrig når frem.
Det bedste sker, når brikkerne taler med hinanden.
En lille tjekliste
Før jeg lader en vibe-kodet prototype vokse, vil jeg stille mig selv disse spørgsmål:
- forstår jeg strukturen af koden?
- er der tests for kritisk adfærd?
- ved jeg, hvilke filer agenten rørte ved?
- har jeg fjernet kode genereret, men ikke brugt?
- er nogen hemmeligheder, tokens eller falske data havnet det forkerte sted?
- overholdes minimum tilgængelighed?
- har implementeringen rollback?
- kan andre end mig beholde den?
Hvis svaret er nej på for mange spørgsmål, er det ikke en fiasko. Det er bare en prototype, der skal forblive en prototype lidt længere.
Min læsning
Vibe-kodning er et højt ord for en øm ting: glæden ved at se en idé tage form, før frygt stopper den.
Jeg vil ikke smide det væk. Det ville være snobbet. Mange gode ting fødes sådan, halvt skæve og levende.
Men den resterende software har brug for mere. Det kræver forståelse, test, ejerskab, infrastruktur, grænser. Der er brug for nogen til at sige: fedt, lad os nu gøre det virkeligt.
Måske handler fremtiden ikke om at vælge mellem "seriøst" programmering og "vibe" programmering. Måske er det at lære at skifte gear: udforsk let, og konsolider derefter med respekt.
Den menneskelige del er der. Ved, hvornår du skal løbe, og hvornår du skal sidde og læse forskellen.