Vibecoding vs WordPress

Før vi avgjør om det er et problem for WordPress, er det verdt å være presis på hva begrepet betyr, for det sprer seg fort og oppfattes ulikt fra person til person.

Det er også verdt å ta ett forbehold til selve tallet. Ulike datasett forteller ulike historier. W3Techs viser fallet og veksten i kategorien uten detekterbart CMS, men det er én måling basert på sin egen deteksjonsmetode. Andre kilder legger vekten et annet sted. Det endrer ikke retningen, for retningen bekreftes av flere uavhengige observasjoner, men den som slenger ut ett tall som bevis, forenkler. Her er det ikke den eksakte prosenten som er interessant, men fenomenet: en del av markedet flytter seg faktisk bort fra ferdige CMS-er og over mot sider generert fra en prompt.

#Hva vibecoding er

Vibecoding er å bygge en applikasjon ved å beskrive den for en språkmodell og godta det den lager, uten å lese koden linje for linje. Verktøyene er Lovable, Bolt.new, v0 fra Vercel, Replit Agent og Base44. Du skriver “lag en butikk med innlogging og betaling”, og du får en fungerende frontend, en database (som regel Supabase) og en deploy på noen minutter.

Til en prototype, et internt verktøy eller en kampanjeside som skal leve en uke, er dette faktisk bra. Vi bruker det selv til egne skisser, for å vise en kunde en retning før noen skriver produksjonskode. Problemet oppstår først når resultatet settes i drift som fundamentet under en bedrift.

#Vibe coding vs. agentisk coding og verktøybølgen i 2026

Bak “la AI-en skrive det” ligger det nå to forskjellige ting, og skillet er verdt å ha klart før du avgjør hva du egentlig ser på. Prompt-to-app-verktøy (Lovable, Bolt.new, v0, Replit Agent, Base44) genererer en hel kjørende app fra én setning og skjuler koden. Agentisk coding er bølgen som slo gjennom i 2026: kodeagenter som jobber inne i et ekte repositorium (Cursor, Claude Code og de nye agentiske IDE-ene Google Antigravity og AWS Kiro), drevet av frontlinjemodeller som Gemini 3, som redigerer filer, kjører tester og åpner pull requests slik en utvikler ville gjort.

De agentiske verktøyene gir merkbart mer vedlikeholdbar kode enn prompt-to-app-generasjonen, fordi de opererer på en reell kodebase med versjonskontroll og ikke på en forseglet forhåndsvisning. Det er en reell forbedring, og det er derfor søkeinteressen rundt dem stiger. Det er også her misforståelsen sniker seg inn: bedre kodegenerering er ikke det samme som ansvar. En agentisk IDE vil fortsatt legge en Supabase-nøkkel i bundlen, fortsatt la en admin-rute stå uten autorisasjon, fortsatt rendre en katalog kun på klienten hvis ingen sier noe annet, fordi modellen optimaliserer for “funksjonen virker når jeg tester den”, ikke for “dette tåler reell trafikk, en gjennomgang og EUs krav til tilgjengelighet”. Verktøyet klatret ett trinn opp. Avstanden mellom en fungerende demo og et produksjonssystem noen svarer for, flyttet seg ikke. Uansett hvilket verktøy som bygde det, er spørsmålene i resten av denne teksten de samme.

#Der vibecodede nettsteder ryker

Dette er ikke et refleksforsvar for WordPress. Det er en liste over hva som faktisk dukker opp når noen kommer og sier “det virket, og nå virker det ikke”:

• Nøkler i bundlen. Modellen legger en Supabase service_role-nøkkel inn i kode som havner i nettleseren. Alle med utviklerverktøy kan lese den. Gjennom 2025 lekket hele brukertabeller ut fra Lovable-bygde apper og Supabase-databaser uten Row Level Security påslått.
• Endepunkter uten autorisasjon. Prompten “lag et adminpanel” lager et panel, men ruten /api/admin sjekker aldri hvem som banker på. Det ser riktig ut fordi forfatteren tester det innlogget på sin egen konto.
• Ingen validering eller grenser. Et kontaktskjema uten rate limiting og uten sanitering blir en åpen dør for spam og injeksjonsforsøk.
• Usynlig i søk. Innhold som rendres kun på klienten, uten serverside-rendering, er en tom side for Googlebot. En produktkatalog som ikke finnes i HTML-en, blir ikke indeksert.
• Ingen vedlikeholdsvei. Ingen databasemigreringer, ingen sikkerhetskopier, ingen versjonering, ingen pipeline. Den første reelle endringen betyr omskriving fra bunnen, for ingen, heller ikke den som skrev prompten, vet hvorfor det ble bygd slik det ble.
• E-postlevering overlatt til tilfeldighetene. Det genererte skjemaet sender e-post gjennom en gratis leverandør uten SPF, DKIM og DMARC. Ordrebekreftelsene havner i spam, og eieren får vite det fra kundene, ikke fra panelet.
• Tilgjengelighet ignorert. Kontrast, fokus, tastaturnavigasjon, feltetiketter. Modellen genererer en pen skjerm, ikke et tilgjengelig grensesnitt. I EU, med kravene i European Accessibility Act, er ikke dette kosmetikk, men en juridisk risiko.
• Innelåst i én plattform. Koden er sveiset fast til én bestemt preview-host og én bestemt database. Å komme seg ut av det økosystemet, når regningene begynner å vokse med trafikken, betyr en migrering ingen har forberedt seg på.

To konkrete tilfeller fra de siste månedene. En startup i Oslo bygde et kundepanel i Bolt.new og lanserte på en uke. To uker senere kunne brukerne se og redigere data fra andres kontoer, fordi Supabase-anon-nøkkelen lå i koden og Row Level Security aldri var slått på. En nettbutikk på Vestlandet satte opp en “butikk” i v0. Den var rask og pen, og etter tre måneder hadde den null trafikk fra Google, fordi hele katalogen rendret seg først i nettleseren. Begge nettstedene så plettfrie ut på lanseringsdagen. Det er fella i vibecoding: demoen er perfekt, og regningen kommer senere.

#Usynlig for Google og for AI

Det ligger en ironi i dette. Vibecoding er et produkt av AI-æraen, og likevel er sidene det lager ofte usynlige nettopp for AI. Dukker innholdet først opp etter at et skript har kjørt i nettleseren, ser verken Googlebot eller svarmotorene som bygger AI Overviews og lignende funksjoner det. En modell som oppsummerer nettet, leser HTML, den rendrer ikke en applikasjon. Ligger ikke katalogen i HTML-en, ligger den heller ikke i svaret.

Det er et dobbelt tap. Nettstedet mister trafikk fra de klassiske resultatene og faller samtidig ut av den nye kanalen der kjøpsreisen stadig oftere starter. Synlighet i generative funksjoner lar seg måle, det skriver vi om for seg, men først må innholdet i det hele tatt finnes i kode maskinen klarer å lese. Et nettsted bygd utelukkende på klienten kommer ikke over den terskelen.

#Hvorfor generert kode er vanskelig å vedlikeholde

Problemet stopper ikke ved enkelthull. Det handler om struktur. Modellen optimaliserer for at skjermen skal virke nå, ikke for at noen skal videreutvikle koden om et halvt år. I praksis gir det noen tilbakevendende mønstre: den samme logikken kopiert fem steder i stedet for skilt ut én gang, ingen lagdeling, ingen tester som ville varslet at en endring brøt noe, og avhengigheter valgt etter mote i stedet for stabilitet.

Hver av disse tingene er til å leve med hver for seg. Til sammen gir de kode der en liten endring kan velte noe på den andre siden, uten at noen vet det før kunden ringer. Vedlikehold av et nettsted er ikke å dytte inn funksjoner. Det er visshet om at en ny funksjon ikke velter noe annet. Generert kode gir ikke den vissheten, for ingen har designet den med endring for øye.

#Hvordan du kjenner igjen et vibecodet nettsted

Du trenger ikke tilgang til koden. Noen signaler holder:

• Vis kilde (Ctrl+U) viser en nesten tom <body> og én stor JavaScript-fil. Innholdet dukker først opp etter at skriptet er lastet.
• Slå av JavaScript etterlater en blank side i stedet for tekst.
• I Google har nettstedet ingen sider utover forsiden, selv om nettleseren viser mange.
• Ingen innloggingsside på nettstedets eget domene, eller et adminpanel som lener seg helt på en ekstern tjeneste uten oppsatte rettigheter.
• Svarhodene peker på preview-hosting (Vercel, Netlify) uten et eget applikasjonslag.

Ingen av punktene er en dom alene. Til sammen tegner de et nettsted som kom ut av en prompt og aldri fikk et fundament.

#Vibecoding vs WordPress i produksjon

Tabellen sier ikke at vibecoding er dårlig. Den sier hva hvert verktøy passer til. Til å teste en idé over en helg vinner vibecoding uten diskusjon. Til et nettsted som skal tjene penger om ett år, vinner fundamentet.

#Hva en gjennomgang av et AI-bygd nettsted faktisk sjekker

Når et slikt nettsted havner hos oss, begynner vi ikke med å skrive om. Vi begynner med en diagnose, for “det virket, og nå virker det ikke” har som regel flere lag. Rekkefølgen er alltid den samme:

1. Sikkerhet først. Ligger det nøkler i koden som lastes til nettleseren, som ikke skulle vært der. Har databasen tilgangsregler slått på. Sjekker endepunktene hvem som banker på. Det avgjør om nettstedet i det hele tatt kan stå trygt på nett mens reparasjonen pågår.
2. Rendering og indeks. Ligger innholdet i HTML, eller først i JavaScript. Hvor mange undersider ser Google egentlig. Finnes det redirigeringer, kanoniske pekere og et nettstedskart. Det svarer på hvorfor den organiske trafikken uteblir.
3. Data og kontinuitet. Hvor ligger dataene, finnes det sikkerhetskopier, lar de seg eksportere. Uten det er hver videre avgjørelse et sjansespill.
4. Avgjørelsen: redde eller skrive om. Først nå. Noen ganger holder det å legge til laget som manglet. Andre ganger er det billigere og tryggere å flytte innholdet over på et fundament som lar seg vedlikeholde. Gjennomgangen sier hvilken av de to veiene som er billigst målt over et år, ikke bare denne uken.

Det viktigste er at dette ikke er en jobb for enda en prompt. En prompt leser ikke andres kode med ansvar for konsekvensene. En ingeniør gjør det.

#Hvorfor dette ikke er slutten for WordPress

Andelen faller fordi den nederste delen av markedet, de enkle nettstedene som før ble satt opp på WordPress “bare fordi”, faktisk flytter til AI. Og det er greit. Det var den minst lønnsomme, mest engangsaktige delen av markedet. WordPress mister arbeidet ingen tjente penger på uansett.

Igjen står resten: WooCommerce-butikker med reell omsetning, flerspråklige nettsteder med korrekt hreflang, GDPR-bundne prosjekter, arbeid som skal leve i fem år og overleve et titalls oppdateringer. Dit når ikke vibecoding, for der handler jobben ikke om å generere en skjerm. Det handler om et fundament: sikkerhet, ytelse du kan måle i Core Web Vitals, vedlikehold, og ansvar for hva som skjer klokka to om natta på topplasten under Black Friday.

WordPress vinner ikke fordi det er på moten. Det vinner fordi det har to tiår med økosystem, en forutsigbar vedlikeholdsvei, og et menneske som vet hvorfor noe ble bygd slik det ble.

#Når WordPress heller ikke er svaret

For å være ærlig: ikke ethvert prosjekt er WordPress. Bygger du en sanntidsapplikasjon, et produkt som hviler helt på ett applikasjonsgrensesnitt, et panel med tung logikk på klientsiden eller noe som i sin natur er en applikasjon og ikke et innholdsnettsted, da er andre verktøy bedre. WordPress driver innhold, butikk, integrasjoner og søkesynlighet utmerket. Det er ikke en universalhammer, og å behandle det som en slik ender like galt som å legge en nettbutikk oppå en vibecodet prototype.

Forskjellen er at valget mellom WordPress, en spesialbygd applikasjon eller noe helt annet er en arkitekturbeslutning noen tar bevisst, med konsekvensene klart for seg. Vibecoding tar ikke den beslutningen. Det genererer det som statistisk passer prompten, og lar konsekvensene ligge til senere.

#Hvem har ansvaret når noe går galt

Det spørsmålet kommer som regel for sent, for det kommer først når noe allerede har gått galt. En prompt har ingen vakt. Modellen ringer ikke tilbake når butikken slutter å ta imot betaling en lørdag kveld. Et generert nettsted har ingen teknisk eier som kjenner historien og vet hvor han skal lete.

Et fundament er ikke bare kode. Det er noen som tar ansvar for følgene. I en tid der stadig mer lar seg generere, er det nettopp ansvaret som blir en knapp vare. Poenget er ikke å la være å bruke AI. Vi bruker den selv, hver dag. Poenget er at det mellom den genererte skjermen og den kjørende bedriften skal stå et menneske som forstår forskjellen og svarer for det som havner i produksjon.

#Når vibecoding passer, og når du bør ringe en senior

Enkelt sagt: til en prototype, en MVP, et internt verktøy eller en kampanjeside, vibecod i vei. Raskt, billig, godt nok. Til en butikk, et bedriftsnettsted, eller noe som skal tjene penger og fremdeles finnes om ett år, trenger du et fundament, ikke en generert skjerm.

Så er det spørsmålet om kostnad, det som kommer oftest: når AI-en gjorde det på en dag, burde reparasjonen være billig. Ikke alltid. Innsatsen avhenger av hvor dypt problemene stikker. Mangler det bare et sikkerhetslag og korrekt rendering, mens innhold og data lar seg flytte, er arbeidet begrenset og forutsigbart. Finnes det ikke noe fundament i det hele tatt, og nettstedet allerede har samlet kunder, data og posisjoner i Google, da er en migrering som beholder alt dette et større prosjekt enn å bygge på nytt på ren grunn. Derfor starter gjennomgangen med en diagnose, og prisen settes alltid individuelt: først når vi vet hva som er verdt å redde, kan vi si ærlig hvilken vei som er billigst målt over et år.

Har du allerede et AI-bygd nettsted og noe begynner å ryke, fra lekkasjer til tapt trafikk til “vi får ikke utvidet det”, er det som regel reparerbart, men ikke med enda en prompt. Vi redder AI-bygde nettsteder: en sikkerhetsgjennomgang, SEO fra bunnen, og en avgjørelse om hva som skal skrives om og hva som kan reddes. Arbeidet gjøres av en utvikler som leser koden ingen har lest før.