Ki-drevet WordPress-utvikling: Produktivitet og personlig tilpasning i 2026

Kunstig intelligens er allerede en del av hverdagen for mange WordPress-team: autofullføring i IDE-en, agenter som foreslår endringer i repositoriet, første utkast til tester og dokumentasjon. Det som ikke har endret seg, er hvem som står ansvarlig for resultatet. Hver commit trenger fortsatt noen som forstår den, går gjennom den og ruller den ut.

I denne guiden ser vi på hvor KI-assistert utvikling faktisk hjelper i WordPress, hva målte studier sier om produktivitet, hvilke KI-API-er WordPress leverer fra versjon 6.9 og 7.0, og hvilke markedsføringspåstander du bør legge bort før du planlegger et prosjekt.

#1. KI-verktøy for WordPress-utvikling

Å kode for WordPress med KI ligner mer på å styre og gjennomgå enn på å skrive hver linje fra bunnen av. Utvikleren beskriver oppgaven, assistenten foreslår kode, og utvikleren bestemmer hva som går inn i repositoriet.

#KI-IDE-er som leser koden i prosjektet ditt

Verktøy som Cursor og GitHub Copilot jobber med konteksten i det åpne repositoriet: de leser filene i temaet eller utvidelsen, de registrerte hookene og prosjektets egne konvensjoner. Ingen leverandør oppgir at modellene er trent spesifikt på Gutenberg-kjernen, så kvaliteten på forslagene avhenger av hva assistenten ser i repositoriet ditt, og av hvor godt den eksisterende koden er skrevet.

Funksjoner som hjelper i hverdagen:

• Autofullføring med kontekst: IDE-en foreslår WordPress-hooks og -filtre ut fra konteksten i filen du jobber i
• Generering av blokker: et første utkast til en egen Gutenberg-blokk ut fra en beskrivelse i vanlig språk, som så blir gjennomgått
• Assistert refaktorering: gjøre gammel prosedyrekode om til klasser med streng typing i PHP 8.x
• Markere usikre mønstre: peke ut spørringer uten $wpdb->prepare() eller utdata uten escaping, som støtte til en sikkerhetsgjennomgang og ikke som erstatning for den

#Refaktorering i stor skala

KI-agenter kan hjelpe med å gjøre en eldre utvidelse basert på jQuery om til moderne React-baserte blokker, der logikken beholdes og arkitekturen moderniseres. Det faktiske tempoet avhenger av hvor stor utvidelsen er, og av hvilke tester som finnes før du starter.

Der det virkelig hjelper: i stillaset for en eldre utvidelse, altså når markup og struktur skal over til blokker, og når testene som manglet skal skrives. Forretningslogikken trenger fortsatt menneskelig gjennomgang linje for linje, og der sparer assistenten lite.

#Assistert testgenerering

KI skriver ikke bare kode, den hjelper også med å teste den. Agenter kan foreslå:

• Enhetstester for offentlige funksjoner
• Integrasjonstester for samspill mellom utvidelser
• Lastscenarioer som deretter kjøres med ytelsesverktøy
• Automatiske tilgjengelighetssjekker mot WCAG 2.2, som bare dekker en del av kriteriene

En generert test er bare like mye verdt som en håndskrevet hvis noen sjekker at den feiler når koden er ødelagt.

#2. Hva studier sier om produktivitet med KI

Tallene som sirkulerer om tidsbesparelse med KI, kommer fra studier med svært ulike oppsett. Før du siterer en prosent, bør du vite hva hver studie målte.

#Hvorfor resultatene spriker

De 55,8 % fra Peng mfl. kommer fra en isolert, tydelig avgrenset oppgave som ble startet fra null. Det er det gunstigste scenarioet for en assistent. METR-studien fra 2025 målte det motsatte: utviklere som kjente store repositorier godt, og som jobbet med ekte saker. Der gjorde KI dem tregere, og etter studien trodde de samme deltakerne fortsatt at de hadde blitt 20 % raskere. Det gapet mellom opplevelse og måling er det mest nyttige funnet for alle team som vil vurdere sine egne verktøy.

METR gjentok eksperimentet med verktøy fra slutten av 2025 og publiserte resultatene i februar 2026. De ti utviklerne fra den opprinnelige studien viste en anslått tidsbesparelse på 18 %, og de 47 nye på 4 %. METR kaller selv disse dataene svært svak evidens, fordi noen av deltakerne nektet å jobbe uten KI på enkelte oppgaver, noe som gjør utvalget skjevt.

De 3 % fra Humlum og Vestergaard måler noe annet: tidsbesparelsen arbeidstakere selv oppgir når de bruker KI-chatboter, i 11 yrker som inkluderer programvareutviklere. Det er ikke en måling av kodeassistenter i IDE-en, og den reviderte versjonen av arbeidet hos NBER (working paper 33777) handler om inntekt og registrerte arbeidstimer.

DORA 2024 fant positive signaler i arbeidet rundt koden: for hver økning på 25 % i KI-bruk stiger dokumentasjonskvaliteten med 7,5 %, kodekvaliteten med 3,4 % og hastigheten på kodegjennomgang med 3,1 %. Samtidig går gjennomstrømning og stabilitet i leveransene ned. 39 % av respondentene oppga lite eller ingen tillit til KI-generert kode.

#Hvor mye tid KI sparer et WordPress-team

Ingen av studiene over måler WordPress-prosjekter spesielt. Det de gjør mulig, er å avvise de runde tosifrede tallene som gjentas uten kilde. I WordPress-arbeid dukker besparelsen opp fire konkrete steder:

• Stillas for temaer og blokker er der assistenten gir tilbake reell tid
• Genererte tester fanger regresjoner som før nådde produksjon
• Feilsøking med kontekst fra repositoriet forkorter letingen, ikke selve rettingen
• Opplæring av nye folk tjener mer på levende dokumentasjon enn på selve assistenten

#3. KI-tilpasning i WordPress

Et WordPress-nettsted kan tilpasse deler av innholdet til den besøkende ut fra kontekstsignaler. WordPress har ikke dette i kjernen: det bygges med egen kode, utvidelser eller logikk på edge.

#Forutsi brukerens intensjon

Med logikk på edge eller på serveren kan nettstedet anslå om en bruker vil kjøpe, undersøke eller sammenligne, og justere rekkefølgen på seksjonene.

Slik fungerer mønsteret:

1. Brukeren kommer inn fra et bestemt søk eller en kampanje
2. Logikken leser tilgjengelige signaler: landingsside, kampanjeparametere, enhetstype
3. En anonym intensjonsprofil blir tildelt (kjøper, researcher, sammenligner)
4. Innholdet tilpasses profilen

#Endre rekkefølgen på Gutenberg-blokker etter bruker

Gutenberg-seksjoner kan endre rekkefølge eller fremheve bestemte funksjoner ut fra profilen som er tildelt. Funksjonene i eksemplet hører til prosjektet, de er ikke en del av WordPress.

Praktisk implementering:

// Mønster for intensjonsbasert tilpasning.
// detect_user_intent() og prioritize_blocks() er prosjektets egne funksjoner.
function personalize_gutenberg_layout( $blocks ) {
    $intent = detect_user_intent();

    if ( $intent === 'buyer' ) {
        return prioritize_blocks( $blocks, [ 'pricing', 'testimonials', 'cta' ] );
    }

    if ( $intent === 'researcher' ) {
        return prioritize_blocks( $blocks, [ 'features', 'comparison', 'documentation' ] );
    }

    return $blocks;
}

#Tilpasning og personvern

Hvis profilen beregnes i nettleseren eller på edge uten å lagre personidentifikatorer, forlater færre personopplysninger enheten. Det fritar ikke fra GDPR: bruker tilpasningen informasjonskapsler eller identifikatorer, trenger du fortsatt et rettslig grunnlag og i mange tilfeller samtykke. Den juridiske vurderingen gjøres per prosjekt.

#4. RAG og vektorsøk i WordPress

Det innebygde søket i WordPress er fortsatt en SQL-spørring mot titler og innhold, og det finner ord som matcher, ikke mening. Vektorsøk og RAG (Retrieval-Augmented Generation) legges til med utvidelser eller eksterne tjenester på nettsteder med mye innhold.

#Kunnskapsbaser med KI

Når du indekserer innholdet ditt i en vektordatabase, kan søkefeltet på nettstedet fungere som en assistent. Det gir svar hentet fra innleggene dine, med lenker til kildene.

Arkitektur for RAG-søk i WordPress:

1. Vektorindeksering: hvert innlegg, hver side og hvert produkt gjøres om til vektor-embeddings
2. Lagring: vektorene lagres i spesialiserte databaser (Pinecone, Weaviate eller pgvector)
3. Semantisk spørring: når en bruker søker, gjøres søket om til en vektor, og innholdet som ligger nærmest i betydning hentes ut
4. Generering av svar: en LLM skriver et svar med de hentede fragmentene som kontekst
5. Kildehenvisning: hvert svar lenker til de opprinnelige sidene på nettstedet

#Kontekstuell hjelp

På store bedriftsportaler kan KI-assistert navigasjon foreslå det whitepaperet eller den kundecasen som passer til siden brukeren ser på.

Der det merkes: færre gjentatte henvendelser til support, lengre økter i dokumentasjonen og færre som forlater hjelpesidene. Vi publiserer ikke egne prosenttall uten en måling vi kan vise frem.

#Samtalebasert søk

RAG-søk gir dialog over flere runder, der systemet husker konteksten fra tidligere spørsmål. Risikoen er den samme som med enhver LLM: et selvsikkert svar som ikke står i dokumentene dine. Derfor bør hvert svar lenke til kilden, og systemet bør si “vet ikke” når det ikke finner noe relevant.

#5. KI-innholdsflyt i Gutenberg-editoren

KI har endret arbeidet i editoren: utkast, sammendrag, titler og alternativ tekst lages på sekunder, og den redaksjonelle gjennomgangen blir den delen som tar mest tid.

#Gjennomgang av E-E-A-T-signaler

Mens du skriver i Gutenberg, kan en KI-assistent gå gjennom innholdet med tanke på E-E-A-T-signaler, foreslå kilder du bør sitere, eller peke ut steder der egen erfaring mangler.

Nyttige funksjoner i en slik assistent:

• Markerer faktapåstander uten oppgitt kilde
• Foreslår relevante interne lenker som styrker den tematiske autoriteten
• Peker ut steder der du kan legge til førstehåndserfaring
• Anbefaler endringer i strukturen for bedre lesbarhet

#Multimodal generering

Fra et webinaropptak kan en KI-pipeline lage en transkripsjon, et utkast til et oppsummeringsinnlegg og klipp til sosiale medier. Dette er ikke en funksjon i WordPress-kjernen: det settes sammen av transkripsjonstjenester og en LLM, og resultatet går gjennom menneskelig redigering.

Multimodal arbeidsflyt:

1. Inndata: webinaropptak
2. Behandling: automatisk transkripsjon med tidsstempler
3. Generering: innleggsutkast med hovedpunkter og sitater som er sjekket mot opptaket
4. Strukturerte data: schema markup som passer innholdet (for eksempel VideoObject)
5. Distribusjon: korte klipp med undertekster til sosiale medier
6. SEO: metabeskrivelser og alternativ tekst til miniatyrbilder, gjennomgått manuelt

#Oversettelse og lokalisering

KI oversetter ikke bare: med gode instruksjoner kan den tilpasse eksempler og tone til hvert marked. For et byrå som WPPoland, som jobber med kunder i Polen, Tyskland, Østerrike og resten av Europa, gjør dette det første utkastet raskere. Tall, navn og sitater sjekkes på hvert språk, for det er nettopp der maskinoversettelse finner på detaljer.

#6. Personvern ved bruk av KI i WordPress

“Ansvarlig KI” er et krav til arkitekturen, ikke et valgfritt tillegg. Selskaper som overser KI-etikk, tar på seg juridisk, omdømmemessig og operativ risiko.

#Datasuverenitet

Vi tar i bruk lokale LLM-er eller private API-instanser slik at sensitive kundedata aldri forlater bedriftens miljø for å brukes til trening.

Arkitektur for privat KI:

• LLM-er on-premise: åpne modeller som Llama 3 som kjører på egen infrastruktur
• Sikre API-gatewayer: en proxy som filtrerer bort sensitive data før de sendes til eksterne API-er
• Kryptert lagring: vektor-embeddings krypteres under overføring og ved lagring
• Revisjonslogger: hver interaksjon med KI logges for å oppfylle regelverket

#Revisjon av skjevheter

Tilpasning trenger en gjennomgang for skjevheter, som ethvert system som bestemmer hva hver bruker ser. Dette omfatter:

• Rettferdighetsanalyse av innholdsanbefalinger
• Oppdagelse av diskriminerende mønstre i segmentering av målgrupper
• Kontroll av at tilpasningen ikke skaper “filterbobler”
• Gjennomgang av skjevheter før publisering, ikke bare ved prosjektslutt

#Algoritmisk åpenhet

Brukere bør vite når de møter innhold som er generert eller tilpasset av KI. Vi innfører:

• Tydelig merking av KI-generert innhold
• Forståelige forklaringer på hvorfor tilpasset innhold vises
• Mulighet for brukere til å slå av tilpasning
• Arbeid i tråd med EUs KI-forordning, med det konkrete omfanget fastsatt per prosjekt

#7. Automatisere CI/CD for WordPress med KI

KI kommer også inn i utviklingspipelinen for WordPress, alltid bak testene og en menneskelig gjennomgang.

#CI/CD med KI

Pipelines for kontinuerlig integrasjon kan bruke KI til å:

• Prioritere tester: kjøre de testene som er mest relevante for endringene først
• Oppdage regresjoner: markere endringer som kan påvirke ytelsen før merge
• Gå gjennom kode: automatiske kommentarer i kodegjennomgangen som går lenger enn vanlig linting

#Overvåking med KI

KI kan analysere mønstre i trafikk og ytelse for å varsle før et problem når brukerne:

• Varsler om svekket ytelse
• Prognoser for trafikktopper basert på historiske mønstre
• Tidlig oppdagelse av angrep ut fra unormale mønstre

#Assistert dokumentasjon

KI-agenter hjelper med å holde dokumentasjonen oppdatert:

• API-dokumentasjon for egne endepunkter
• Brukerveiledninger for egne Gutenberg-blokker
• Endringslogger basert på commits
• Arkitekturdiagrammer generert fra kildekoden

Det er her DORA 2024 målte den tydeligste positive effekten: 7,5 % høyere dokumentasjonskvalitet for hver økning på 25 % i KI-bruk.

#8. Hvilke KI-API-er WordPress 6.9 og 7.0 leverer

Frem til 2025 integrerte hver KI-utvidelse sin egen leverandør og sitt eget format. Core AI-teamet i WordPress har publisert et sett felles byggeklosser, som teamet beskriver i sin oppsummering etter seks måneder.

#Abilities API i WordPress 6.9

Abilities API er tilgjengelig fra WordPress 6.9. Det er et sentralt register over “abilities”: funksjonsenheter med navnet namespace/ability-name, en kategori, JSON Schema-definisjoner for inndata og utdata (input_schema, output_schema), en utførelsesfunksjon og en valgfri permission_callback. Det uttalte målet er at utvidelser, temaer og eksterne systemer, som KI-agenter, skal kunne finne ut hva et bestemt nettsted kan gjøre.

En minimal registrering, basert på eksemplet i den offisielle dokumentasjonen:

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category( 'site-information', array(
        'label'       => __( 'Site Information', 'textdomain' ),
        'description' => __( 'Abilities that provide information about the WordPress site.', 'textdomain' ),
    ) );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'my-plugin/site-info', array(
        'label'               => __( 'Site Info', 'textdomain' ),
        'category'            => 'site-information',
        'execute_callback'    => 'wporg_get_siteinfo',
        'permission_callback' => function () {
            return current_user_can( 'manage_options' );
        },
        'meta'                => array( 'show_in_rest' => true ),
    ) );
} );

For sikkerheten er permission_callback den viktigste delen: en ability som gjøres tilgjengelig for en agent uten kontroll av rettigheter, er et åpent endepunkt med et annet navn.

#MCP Adapter

MCP Adapter er en pakke fra Core AI-teamet som kobler Abilities API til Model Context Protocol. Registrerte abilities dukker opp som MCP-verktøy, -ressurser eller -prompter, slik at en klient som Claude Code eller Cursor kan bruke dem mot et WordPress-nettsted. Pakken er ikke en del av kjernen. Et praktisk eksempel på denne tilnærmingen finner du i artikkelen vår om agentisk WordPress med MCP.

#AI Client og Connectors i WordPress 7.0

WordPress 7.0 “Armstrong” kom ut 20. mai 2026. Ifølge den offisielle kunngjøringen inneholder den:

• AI Client i kjernen: et felles lag som lar WordPress og utvidelser kommunisere med generative KI-modeller uten at hver utvidelse integrerer sin egen leverandør
• Connectors-skjermen: ett sted i kontrollpanelet for å administrere eksterne tilkoblinger, med tre forhåndsoppsett og mulighet for å legge til flere
• Client-Side Abilities: en JavaScript-motpart til Abilities API, med eget grensesnitt og kommandopalett
• Egen KI-utvidelse: lager og redigerer bilder, lager titler eller utdrag og foreslår alternativ tekst

For et utviklingsteam endrer dette én konkret beslutning: en ny utvidelse som trenger KI, kan bygge på AI Client og tilkoblingene administratoren har satt opp, i stedet for å be om sin egen API-nøkkel.

#9. KI-stakk for WordPress-utvikling

#KI-verktøy og hvordan de kobles til WordPress

#Slik måler du om KI sparer teamet ditt tid

Studiene over gir en metode som ethvert WordPress-team kan kopiere i liten skala:

1. Fordel oppgaver tilfeldig. METR avgjorde ved loddtrekning, sak for sak, om KI var tillatt. Slik havner ikke alle de enkle oppgavene i samme gruppe.
2. Mål tid, ikke følelse. I METR 2025 trodde deltakerne at de hadde vunnet 20 %, mens de hadde tapt 19 %.
3. Se også på leveransene. DORA måler gjennomstrømning og stabilitet: et team som skriver kode raskere, men leverer flere regresjoner, har ikke vunnet noe.
4. Skill mellom oppgavetyper. Stillaset for en ny blokk og en feil i en ti år gammel utvidelse bør ikke tas med i samme gjennomsnitt.

#10. WordPress-byrå for KI-integrasjon

Hos WPPoland bruker vi KI i det daglige arbeidet og bygger den inn i kundeprosjekter når den løser et konkret problem.

1. Integrasjon av KI-arbeidsflyt: vi hjelper teamet ditt med å ta i bruk KI-verktøy i innholds- og utviklingssyklusene, fra oppsett av IDE til automatiserte pipelines.

2. Skreddersydde RAG-løsninger: vi gjør WordPress-nettstedet ditt til en søkbar kunnskapsbase med vektorsøk, med svar som lenker til dine egne sider.

3. Tilpasning: vi bygger frontender som tilpasser innholdet til målgruppen, med respekt for personvern og gjeldende regelverk.

4. KI-revisjon: vi vurderer den tekniske stakken din og viser hvor KI hjelper på en etisk, trygg og lønnsom måte, og hvor den ikke gjør det.

Les mer om hvordan du gjør en WordPress-side raskere og hvordan KI passer inn i ytelsesarbeidet.

#11. Oppsummering

KI gjør bestemte deler av WordPress-utviklingen raskere: stillas, tester, dokumentasjon og første innholdsutkast. I målingene fra METR, Humlum og Vestergaard og DORA er den samlede effekten på produktiviteten langt mindre enn kunngjøringene lover, og i moden og kompleks kode kan den være negativ. Fra WordPress 6.9 og 7.0 gir kjernen et felles grunnlag for KI-integrasjon (Abilities API, AI Client, Connectors), noe som kutter integrasjonsarbeidet i nye utvidelser.

KI-funksjoner i WordPress blir først nyttige når de henger sammen med innholdsmodellen og ikke bare limes på i frontend. Skal en slik løsning bygges på din egen installasjon, tar vi den fra idé til drift i KI-nær WordPress-utvikling.

Vil du ta KI inn i WordPress-arbeidet med ekte målinger? Kontakt WPPoland.

På leveransesiden holder vi dette temaet under GEO og LLMO.

#Relaterte ressurser

• WordPress-utvikler - Utvikling med høy ytelse
• WooCommerce-utvikling - Netthandel med WordPress
• KI-handel med WordPress - Handelsstrategier med kunstig intelligens
• Sikkerhetsrevisjon av WordPress - Sikkerhet for moderne nettsteder