Vibecoding: Er ekspertisen vår nå bare en “vibe”?
I februar 2025 la Andrej Karpathy, en av hjernene bak GPT og tidligere AI-direktør hos Tesla, ut en post på X som satte fyr på utviklerforum verden over. Han beskrev en ny måte å kode på: du glemmer at koden eksisterer, følger magefølelsen, ber AI om det du vil ha, og aksepterer resultatet uten å lese for nøye.
“It’s not really coding… I just see stuff, say stuff, run stuff, and it mostly works.”
Han kalte det vibecoding.
Collins Dictionary kåret det til årets ord for 2025. Utviklerforum eksploderte. Og med det kom spørsmålet mange av oss kjente på i magen: rettferdiggjør dette egentlig oss? Kan det vi har brukt år på å lære: algoritmer, arkitekturmønstre, ytelsesoptimalisering, debugging av rare edge cases, nå kan oppsummeres med et ord som høres ut som noe man sier om en sommerfestival.
Når «alle» kan kode
Kort etter Karpathys post dukket overskriftene opp. «The End of the Programmer.» «Why Your Job Might Be Automated Soon.» GitHub Copilot-teamet viste at utviklere fullfører oppgaver betydelig raskere med AI. Stack Overflow rapporterte at et stort flertall av utviklere allerede bruker eller planlegger å bruke AI daglig.
Det er lett å tolke dette som at selve ferdigheten, det å skrive kode er i ferd med å miste verdi. Men her er det ingen snakker høyt om: de fleste prosjektene som starter med vibecoding, strander ikke fordi AI ikke kan kode. De strander fordi personen bak tastaturet ikke lenger forstår hva AI har kodet.
Utviklermiljøer kaller det “vibecoding-bakrusen”. Et team bygger noe som fungerer, men tre måneder senere kan ingen forklare hvordan det virker. Og dette er ikke bare en teoretisk risiko. I mai 2025 ble det avdekket et sikkerhetshull i 170 av 1 645 applikasjoner laget med vibekodingverktøyet Lovable, hull som lot hvem som helst hente ut personopplysninger.
Illusjonen av produktivitet
Det finnes et annet problem, og det er vanskeligere å se fordi det ikke føles som et problem.
AI starter sterkt. Men etter mange nok prompts begynner den å miste oversikten over det den selv har bygget. Den skriver om kode som allerede fungerer. Den motsier seg selv. Små endringer sprer seg raskt utover i systemet. Context window kollapser. Du fikser en liten bug, AI foreslår en endring som ser fornuftig ut, fiksen brekker noe annet, flere filer endres, du ber AI rette det opp, større andel av kodebasen blir berørt. Plutselig har du flere problemer enn du startet med. Og likevel føles det som fremdrift.
Det er dette som gjør det farlig. Følelsen av å være én prompt unna løsningen holder deg gående. Du bygger, justerer, bygger videre. Tempoet er høyt. Aktiviteten er konstant. Men når du stopper opp og ser tilbake, er bildet et annet: mye av det som ble laget må skrives om. Det som føltes som progresjon, var ofte bare bevegelse.
Tallene bekrefter det. GitClears analyse av over 200 millioner kodelinjer viser at code churn, andelen kodelinjer som rulles tilbake eller skrives om innen to uker, har steget fra 5,5% i 2020 til nesten 8% i 2024. Duplisert kode har åttedoblet seg. DORA-rapporten fra 2025, som kartla nesten 5 000 teknologiorganisasjoner globalt, fant det samme fra en annen vinkel: høyere AI-adopsjon korrelerer med høyere leveringsinstabilitet. AI gjør det enklere å produsere kode raskt. Det gjør det ikke enklere å bygge noe robust.
Det naturlige endepunktet for denne utviklingen er ubehagelig. Hvis du bruker AI til å generere kode, AI til å teste koden og AI i code review-loopen, hvor er det egentlig den menneskelige kontrollen ligger? Dette er ikke et hypotetisk fremtidsscenario. Det er en beskrivelse av kodebaser som allerede eksisterer i dag, i selskaper som trodde de jobbet smartere.
Det er ikke et kodeproblem. Det er et forståelsesproblem.
Da kalkulatoren kom var frykten den samme som nå: nå trenger ingen lære seg matte lenger. Det som faktisk skjedde var noe annet. Forståelsen av når man bruker hvilken utregning, og hva svaret egentlig betyr, ble like viktig som før. En kalkulator som gir feil svar fordi du tastet inn feil formel er ikke et kalkulator-problem. Det er et forståelses-problem. AI i koding er den samme kalkulatoren, bare eksponentielt kraftigere, og med eksponentielt større konsekvenser når du ikke forstår hva du ber om.
Det mest overraskende funnet: AI hjelper ekspertene mest.
Addy Osmani, engineering director hos Google Chrome, har brukt år på å studere hvordan team faktisk bruker AI i utvikling. Konklusjonen hans er kontraintuitiv: AI tar deg raskt 70% av veien, men de siste 30%, feilhåndtering, edge cases, ytelse, vedlikeholdbarhet, krever fremdeles dyp menneskelig ekspertise. Det overraskende er ikke dette gapet. Det overraskende er hvem som klarer å tette det.
Dette omtales ofte som et kunnskapsparadoks. Seniorer bruker AI til å akselerere det de allerede kan. Juniorer prøver å bruke AI til å lære hva de skal gjøre. Resultatene er dramatisk forskjellige. Jo mer du kan fra før, jo mer får du ut av AI. Det er det stikk motsatte av hva teknologioptimistene lovet, at AI endelig ville demokratisere programmering og la alle bidra likt.
Konsekvensen er kode som ser ferdig ut, men som kollapser under virkelige forhold fordi ingen med tilstrekkelig erfaring stilte de riktige spørsmålene underveis. Dette ble også understreket i en artikkel i New York Times Magazine i mars 2026, i en samtale med over 70 utviklere fra Google, Amazon og Microsoft: utviklere har faktisk en fordel ingen andre yrker har i møte med AI. De kan tvinge AI til å teste koden mot virkeligheten.
Så hva vil det egentlig si å være utvikler?
Rollen er i ferd med å forskyves. Ikke fordi den forsvinner, men fordi tyngdepunktet endres. Implementeringen blir enklere, og nettopp derfor blir andre ferdigheter viktigere: å bryte ned komplekse problemer, sette riktige mål, forstå hvordan hele systemet henger sammen, blir langt mer verdifulle, ikke mindre.
AI gjør det mulig å løfte blikket fra linje-for-linje-koding og heller fokusere på selve problemet. Du kan utforske flere løsninger parallelt og komme raskere frem til noe som fungerer. Samtidig krever det at du klarer å holde oversikt over helheten mens detaljene håndteres for deg. Det er ikke mindre krevende enn før, men krevende på en annen måte.
Det finnes også et viktig skille i hvordan AI brukes i praksis. Hvis du lar en modell skrive koden, men fortsatt tester, vurderer og forstår alt som bygges, er det ikke vibecoding. Det er faglig arbeid med bedre verktøy. Det er å bruke et LLM som skriveassistent. I oktober 2025 lanserte Simon Willison begrepet “vibe engineering”: en disiplinerte bruken av AI-agenter kombinert med automatisert testing, dokumentasjon og code review. Den flytter ikke ansvaret bort fra utvikleren, den skjerper det.
Det er nærmere arkitektens rolle enn håndverkerens. En arkitekt tegner ikke vegger for hånd lenger, men det er fremdeles arkitekten som vet om bygget kommer til å stå, om rømningsveiene er riktig plassert, om det faktisk er et godt sted å bo. Den kunnskapen kan ikke genereres av en modell. Den bygges gjennom erfaring, feil og forståelse av hva som skjer under panseret.
Er vibecoding et rettferdig begrep?
Begrepet traff noe reelt, men det bommer også på det viktigste. Det antyder at dette handler om intuisjon og tilfeldighet, når det i praksis krever det motsatte. Selv Karpathy justerte senere språket, og beveget seg bort fra “vibecoding” til mer presise beskrivelser av hvordan AI faktisk brukes. Poenget var enkelt: dette er ikke bare en vibe, det er et håndverk.
Han satte en tydelig strek under det da han i 2026 pensjonerte begrepet til fordel for “agentic engineering”. Begrunnelsen var ikke kosmetisk, men faglig. Navnet måtte reflektere at det ligger kunnskap, metode og ansvar bak det som bygges. Det handler ikke om å få noe til å virke, men å forstå hvorfor det virker, og hva som skjer når det ikke gjør det.
Samtidig er det verdt å se på hva denne måten å jobbe på gjør med oss. Følelsen av at det alltid er én prompt til, én forbedring til. Arbeidet flyter lettere over i resten av dagen, fordi terskelen for å fortsette er så lav. Du kan fortsette fra hvor som helst, når som helst.
Men det betyr ikke at det blir enklere. Tvert imot. Ansvaret for hva som faktisk bygges, hviler tyngre på den som sitter bak tastaturet, nettopp fordi implementeringen ikke lenger bremser oss. Og det er kanskje det mest misvisende med hele begrepet: det får det til å høres lettere ut enn det er.
Det er ikke bare en vibe. Det er et fag. Og det har aldri krevd mer av utviklere enn nå.
Kilder og videre lesing:
• Andrej Karpathy, X/Twitter, februar 2025 + februar 2026: “Retiring vibe coding for agentic engineering”
• Addy Osmani, «The 70% problem» (2024) + «Beyond the 70%» (mars 2025)
• Simon Willison, simonwillison.net – mars 2025, oktober 2025 + NYT Magazine mars 2026
• Rachel Thomas, «Breaking the Spell of Vibe Coding» – fast.ai, januar 2026
• Armin Ronacher, «Agent Psychosis» – lucumr.pocoo.org, januar 2026
• Kent Beck, intervju med ShiftMag ved Craft Conference, Budapest 2025
• DORA Report 2025: «State of AI-assisted Software Development»