Senior WordPress-utvikler med AI: hva ser et byrå som kaller seg AI-first etter?

I slutten av september 2026 lette Blacksmith Agency, et fjernbasert amerikansk WordPress-byrå som i annonsene kaller seg AI-first, etter en senior til å lede prosjekter. Byrået ville ha to ting av kandidaten samtidig: at vedkommende brukte AI til å jobbe raskere, og at vedkommende fortsatt skrev og gjennomgikk kode selv. Samme firma lette i tillegg etter en AI Engineer til å bygge interne verktøy. Alle tre annonsene er lukket nå, men de viser godt hvordan et byrå som har satset på AI, fordeler arbeidet mellom mennesker og modeller.

Dette er ett firmas eksempel, ikke en markedsundersøkelse. På den offisielle tavlen WordPress.org Jobs lå det i midten av oktober fire annonser fra 5.-13. oktober: frilansere til kundenettsteder, integrasjoner av utvidelser, en WooCommerce-butikk og en teknisk leder i deltid. Ingen hadde AI i tittelen.

#Hva krever en stilling som senior WordPress-utvikler med AI?

Stillingen Senior WordPress Developer fra 27. september og varianten WordPress Development Lead fra 30. september beskriver samme rolle. Senioren skal:

• avklare arbeidsomfanget med kunden og knytte det til et forretningsmål,
• lede egne WordPress-prosjekter: temaer, maler, utvidelser og blokker,
• få teamet til å jobbe raskere ved hjelp av AI,
• være den kunden snakker med om det tekniske, og ta vare på nettstedene etter lansering.

Kravene er solid WordPress og PHP, moderne HTML, CSS og JavaScript, svært god engelsk og erfaring med å lede prosjekter, «ikke bare med å lukke saker» (egen oversettelse). Jobben er fjernarbeid fra USA, Canada, Latin-Amerika eller Sør-Afrika, og kundene er spredt over hele USA.

Rollebeskrivelsen avsluttes med denne setningen:

«Øk effektiviteten med AI og led prosjekter som er raske, ryddige og skreddersydde. Du skriver og gjennomgår fortsatt ekte kode selv.»

Kilde: Blacksmith Agency-annonsen på remoteitjobs.app, 27. september 2026, egen oversettelse

Versjonen for lederrollen legger til at alle i teamet har tilgang til de beste AI-verktøyene, «så du bruker mindre tid på rutinearbeid og mer på beslutningene som betyr noe» (egen oversettelse).

#Hva betaler et AI-first-byrå en WordPress-senior, og hva får en AI Engineer?

Siden med Senior-stillingen oppgir ingen lønn. Kopien av lederrollen hos aggregatoren jobfound.org oppgir 80-120 000 USD i året. En AI Engineer i samme firma skulle tjene 3-4 500 USD i måneden, altså 36-54 000 USD i året.

AI Engineer-rollen gikk ut på å bygge agentbaserte arbeidsflyter med LangChain eller LangGraph, og interne verktøy som kutter manuelt arbeid i design og utvikling. Kravet var to års programmering i Python eller Node.js og integrasjon med API fra OpenAI eller Anthropic. WordPress og PHP var bare et pluss. Byrået betalte altså mest til personen som kan WordPress, snakker med kunden og står ansvarlig for koden, ikke til personen som bygger agenter.

Lønnsspennet kommer fra en aggregator, ikke fra byråets egen side, og stedene stillingen er åpen for har svært ulike levekostnader. Ikke overfør beløpene direkte til det norske markedet. Våre priser finner du på prissiden.

#Krever stillingsannonser for WordPress-utviklere AI i dag?

Det kan man ikke si ut fra tre annonser fra ett firma. Tavlen WordPress.org Jobs hadde i samme periode ikke en eneste annonse med AI i tittelen. Det annonsene derimot viser, er hvordan et firma som selger seg som AI-first, setter opp stillingene sine. Det byttet ikke ut senioren med en agent. Det delte arbeidet i to roller: et menneske som står ansvarlig for prosjektet og koden, og en spesialist som bygger automatisering for teamet.

En lignende fordeling ser vi i små team i Polen. Én person har ansvaret for arkitektur, kodegjennomgang, WooCommerce og blokker. En annen bruker AI til første versjon av koden, tester og dokumentasjon, under oppsyn av den første. Problemet oppstår når begge rollene legges på én junior med Cursor og kunden blir lovet seniornivå.

#Hva gjør AI i et WordPress-prosjekt, og hva gjør den ikke?

15. oktober oppdaterte WordPress.com sin Agent. Å generere et nettsted tar nå under halvparten så lang tid som før, og de fleste nettsteder er ferdige på under fire minutter. Agenten anbefaler utvidelser, installerer og aktiverer dem fra chatten, og oppdaterer på forespørsel dem som allerede er installert. Siden mars 2026 har WordPress.com også MCP-verktøy som lar en AI-assistent lagre innlegg og sider, som standard som utkast. Detaljene står i artikkelen om Agent og MCP write.

Sikkerhetstiltakene i MCP write er fornuftige. Ifølge kunngjøringen fra WordPress.com 20. mars 2026 bekrefter assistenten hvert steg før en endring, og kategorier og stikkord forsvinner for godt først etter en ekstra bekreftelse. Kunngjøringen nevnte også 30 dager i papirkurven for slettede innlegg, sider, kommentarer og mediefiler, men den gjeldende dokumentasjonen av MCP-verktøyene gir papirkurv bare til innlegg, sider og kommentarer: en fil som slettes fra mediebiblioteket, forsvinner for godt, og innhold som brukte den, mister bildet. Alle endringer vises i aktivitetsloggen. Skrivefunksjonene virker på alle betalte WordPress.com-planer. Dette er gode sikkerhetstiltak for innhold. De gjelder ikke kode i tema, utvidelser eller integrasjoner, fordi MCP write ikke endrer dem i det hele tatt, og de gjelder ikke nettsteder på eget webhotell.

En kunde som har sett en slik demo, spør: hvorfor betale en senior? WebDevStudios svarte på det 6. oktober:

«AI er svært god på de synlige 20 % av et nettsted. Den leverer ikke de usynlige 80 %, altså det som gjør at nettstedet blir funnet, holder seg sikkert, beskytter besøkendes data og lar markedsteamet jobbe uten å melde inn saker.»

Kilde: WebDevStudios, 6. oktober 2026, egen oversettelse

I praksis er disse 80 % integrasjonen mellom nettbutikk, lager og regnskapssystem, sikkerhetskopier, brukerrettigheter, språkversjoner og tester etter hver oppdatering. WordPress.com-agenten oppdaterer en utvidelse når du ber om det i chatten, men går ikke gjennom kjøpsprosessen i butikken etterpå, sjekker ikke om fakturaen kom fram til regnskapssystemet, og merker ikke at kontaktskjemaet har sluttet å sende meldinger. Noen må føre disse kontrollene opp på en sjekkliste og gå gjennom dem etter hver oppdatering.

Samme uke slo Gutenberg 24.2 på et eksperiment med React 19 i utvidelsen, med mindre et aktivt tema eller en aktiv utvidelse har kjente kompatibilitetsproblemer. Egne blokker skrevet for React 18 kan etter en slik endring slutte å fungere i redigeringsverktøyet. En AI-assistent merker ikke det, fordi den ikke vet at noe er endret. Det merker utvikleren som tester blokkene på en testkopi av nettstedet før produksjonen oppdateres. Mer i notatene om Gutenberg 24.2.

#Hva ødelegger React 19 i egne Gutenberg-blokker?

React 19 fjerner flere API-er som i årevis har vært merket som utdaterte, men som fortsatt finnes i eldre blokker og utvidelser. Migreringsveiledningen for React 19 nevner blant annet:

• ReactDOM.render og ReactDOM.hydrate, utdatert siden React 18. I stedet finnes createRoot og hydrateRoot.
• ReactDOM.unmountComponentAtNode, erstattet av root.unmount().
• ReactDOM.findDOMNode, utdatert siden 2018. I stedet brukes refs.
• Kontroll av propTypes og defaultProps i funksjonskomponenter. Standardverdier flyttes til funksjonens parametere.
• Refs i form av tekststrenger (string refs) i klassekomponenter.

I WordPress-kode møter man oftest det første tilfellet. Eldre blokker og paneler i administrasjonspanelet monterer komponenter med funksjonen render fra pakken @wordpress/element, som i bakgrunnen kaller ReactDOM.render. Fra WordPress 6.2 har pakken createRoot, og det er den som må brukes. Det andre vanlige tilfellet er defaultProps i funksjonskomponenter som er laget av en eldre blokkmal eller av en modell trent på gammel kode.

Kontrollen tar vanligvis en time per prosjekt:

1. Søk i koden til temaet og egne utvidelser etter: render(, findDOMNode, unmountComponentAtNode, defaultProps, propTypes.
2. Installer Gutenberg 24.2 på en testkopi av nettstedet, og åpne hver egen blokk og hver innstillingsside i redigeringsverktøyet.
3. Følg med i nettleserkonsollen. Monteringsfeil og advarsler om fjernede API-er dukker opp med en gang.
4. Rett feilene før produksjonen oppdateres, ikke etter at kunden melder at redigeringsverktøyet ikke virker.

En AI-assistent klarer første steg og foreslår rettelser. Steg to til fire krever noen som kjenner prosjektet og vet hvilke blokker som er viktige for kunden. Det er det samme arbeidet som Blacksmith-annonsen beskriver som gjennomgang av ekte kode.

#Hvordan sjekker man om en WordPress-utvikler faktisk gjennomgår AI-generert kode?

Spørsmålet «bruker du AI?» gir ingenting, for alle svarer ja. Det er bedre å teste det stillingen krevde: om kandidaten kan lese kode og finne feil i den. Intervjuet kan bygges opp i fire steg:

1. Gi en kort beskrivelse av nettstedet og en liste over tre utvidelser som kan brukes.
2. Be om en plan: hva AI gjør, hva mennesket gjør, og når en endring går ut på produksjonsnettstedet.
3. Vis et stykke AI-generert kode med en bevisst feil, for eksempel et skjema uten nonce-sjekk eller utskrift av brukerdata uten escaping.
4. Spør hva kandidaten gjør når butikken skal kobles til lageret: blir den på WordPress.com eller flyttes den til eget webhotell?

Et eksempel på kode til tredje steg, slik modeller ofte leverer den:

add_action( 'admin_post_save_note', function () {
    update_option( 'client_note', $_POST['note'] );
    wp_redirect( admin_url( 'options-general.php?page=client-note' ) );
} );

add_action( 'admin_notices', function () {
    echo '<div class="notice">' . get_option( 'client_note' ) . '</div>';
} );

En erfaren utvikler peker her på fire problemer. Det er ingen nonce-sjekk, så skjemaet kan sendes fra et annet nettsted i navnet til en innlogget administrator. Det er ingen rettighetssjekk med current_user_can(), så enhver innlogget bruker kan lagre notatet. Data fra $_POST går rett inn i databasen uten sanitize_textarea_field(). Notatet skrives ut uten esc_html(), så et innsmuglet skript kjører i panelet til hver administrator. I tillegg mangler exit etter wp_redirect().

En kandidat som gjennomgår kode til daglig, finner feilen på noen minutter og forklarer hvordan den rettes. En kandidat som bare limer inn svar fra modellen, begynner som regel å snakke om modeller. I tillegg kommer spørsmål om hvordan arbeidet gjøres i praksis:

• Hvilke endringer kan AI gjøre uten at et menneske godkjenner dem, og hvilke ikke?
• Hvem gjennomgår koden før den går til produksjon?
• Hvem tar telefonen når en endring ødelegger nettstedet en fredag ettermiddag?
• Hvordan vet dere at AI sparer tid? Måler dere det, eller føles det bare slik?

På det siste spørsmålet inneholder et godt svar tall: tid fra oppdrag til første versjon, tid fra testversjon til publisering og antall endringer som er trukket tilbake.

#Hvordan bør veien fra AI til produksjon se ut i WordPress?

Setningen i annonsen om at du «fortsatt skriver og gjennomgår kode selv» gir bare mening hvis teamet har en fast vei der gjennomgangen skjer. For et WordPress-prosjekt holder det med fem elementer:

1. En egen gren i kodelageret for hver oppgave. Kode fra AI havner der, aldri rett på serveren.
2. Automatisk kontroll før gjennomgangen. WordPress Coding Standards for PHP_CodeSniffer har regler som fanger manglende nonce, manglende escaping og usanerte inndata, altså nøyaktig feilene i eksempelet over. I tillegg kommer statisk analyse, for eksempel PHPStan.
3. Gjennomgang av endringene ved et menneske. Noen leser forskjellene linje for linje og står ansvarlig for det som slippes gjennom.
4. En testkopi av nettstedet med data som ikke bryter personvernregelverket (GDPR/EØS, tilsyn Datatilsynet). Endringer testes på kopien, og kundedata fra nettbutikken anonymiseres før kopieringen.
5. Sikkerhetskopi og plan for tilbakerulling før lansering. Det er avklart hvem som gjenoppretter forrige versjon, og på hvor mange minutter.

Denne veien avhenger ikke av om koden er skrevet av et menneske eller en modell. Forskjellen er at med AI kommer det mer kode raskere, så punkt 2 og 3 belastes mer enn før. Et team som har fått fart på skrivingen uten å styrke gjennomgangen, leverer bare feil raskere. Har du ikke en slik vei i eget firma, er en sikkerhetsrevisjon av WordPress eller fast vedlikehold en måte å få den på plass med et eksternt team.

#Hva sier Anthropics studie om ansettelse av tekniske juniorer?

Oppdatering, 18. oktober 2026. 16. oktober publiserte Anthropic en studie av sysselsettingen i eget selskap. To funn er viktige for denne artikkelen. Innen august var timene til interaktive AI-agenter seks ganger så mange som de ansattes timer. I samme periode fikk tekniske juniorstillinger en stadig mindre andel av ansettelsene, og innen april hadde ingeniør- og forskningsteamene redusert rekrutteringen til lavere tekniske nivåer. Studien måler andelen av ansettelser og oppgir ingen absolutt nedgang i antall juniorer.

Funnene må leses med begrensningene forfatterne selv peker på. Det er ett selskap som studerer seg selv, helt fremme i bruken av AI, og forfatterne presenterer det høyst som en mulig ledende indikator for resten av økonomien. Produktivitetssammenligningene bygger på ansatte som selv valgte når de tok i bruk agenter, og forfatterne påpeker at valget ikke var tilfeldig, så tallene beviser ikke at det var agentene som førte til endringen. For et WordPress-byrå er den nyttige lærdommen smalere: når rutinekoding flyttes til agenter, er juniorstillingen den første som endrer seg, og derfor veier opplæringen, som neste avsnitt handler om, tyngre nå enn for et år siden.

#Hvordan lærer man opp en WordPress-junior som jobber med en AI-assistent?

En junior med Cursor skriver en blokk på en time. Før vedkommende får tilgang til et kundenettsted, også en testkopi, må fire ting sitte:

1. Escaping av data, nonce og sjekk av rettigheter, uten unntak av typen «det var modellen som skrev det».
2. Lese endringene linje for linje før de slås sammen med hovedgrenen.
3. Kjenne igjen oppgaver AI ikke skal få: passord og nøkler, endringer i produksjon, databasemigreringer.
4. Alle databasespørringer går gjennom $wpdb->prepare(). Modeller limer gjerne sammen en SQL-spørring med en verdi fra $_GET, fordi halvparten av de gamle veiledningene de har lært av, så slik ut. Én slik linje i en spørring mot WooCommerce-bestillinger er nok til at en utenforstående kan lese butikkens kundedata.

Uten dette produserer junioren bare feil raskere. Med dette kan junioren etter halvannet til to år lede egne prosjekter. Den forskjellen er grunnen til at AI-first-byrået i eksempelet krevde kodegjennomgang av senioren: noen må lære juniorene hva som er galt i den genererte koden.

#Ansetter bedrifter som bruker KI færre juniorer?

Oppdatering 24. oktober 2026. Anthropic-studien beskriver ett selskap. Arbeidsnotatet How Does AI Change Labor Demand? Evidence from 41 Countries fra Stanford Digital Economy Lab, skrevet av Bharat Chandar og Bouke Klein Teeselink (PDF, 21. september 2026), bygger på 1,25 milliarder stillingsannonser og 154 millioner ansettelsesoppføringer fra 41 land mellom januar 2021 og mars 2026. Forfatterne leser KI-bruk ut fra stillingsannonser som krever arbeid med generativ KI, og sammenligner utenlandske datterselskaper av konsern som tok teknologien i bruk, med lignende datterselskaper som ikke gjorde det. Fram til mars 2026 falt juniorandelen hos brukerne med 1,9 prosentpoeng. Det skyldtes mest ansettelser over juniornivå (pluss 6,7 prosent), ikke kutt blant juniorer: nedgangen i juniorsysselsettingen på 2,5 prosent er ikke statistisk signifikant, og den samlede sysselsettingen økte med rundt 3,3 prosent, et resultat forfatterne kaller marginalt signifikant. Data- og matematikkyrker, gruppen som er mest utsatt for KI, økte sin andel av sysselsettingen med 0,8 prosentpoeng, mens juniorandelen innenfor gruppen falt med 3,3 poeng. Juniorandelen falt i 23 av de 31 landene som ble anslått hver for seg.

Forfatterne oppgir selv begrensningene: dataene kommer hovedsakelig fra LinkedIn-profiler, som overrepresenterer ledere og fagfolk; bedriftene i studien er store multinasjonale konsern, ikke WordPress-byråer; og perioden dekker drøyt tre år etter ChatGPT. Sammen med Anthropic-tallene peker det i samme retning: utviklingsarbeidet vokser, men færre kommer inn i faget nedenfra. Når du velger byrå, bør du derfor spørre hvem som gjennomgår koden, og hvor mange år vedkommende har gjort det. Et byrå som ikke finner en senior til å gjennomgå KI-kode, kan hente inn en uten å ansette via white label-utvikling for byråer.

#Hvordan velger man et WordPress-byrå som jobber med AI?

De samme spørsmålene byrået stiller kandidaten, kan kunden stille byrået. Be om fire ting før du signerer avtalen:

• En beskrivelse av veien en endring går: fra AI via testkopi og kodegjennomgang til produksjon. Hvem tar beslutningen på hvert trinn?
• Et eksempel på en endring som ødela nettstedet og ble trukket tilbake. Hvor lang tid tok det?
• En bestemmelse i avtalen om at koden og tilgangene tilhører deg, ikke bare en lisens til det ferdige nettstedet.
• Informasjon om hvordan byrået tester blokker og tema etter oppdateringer av Gutenberg og React.

Bestemmelsen om kode og tilganger bør deles opp i konkrete punkter i avtalen, for «vi overleverer alt når prosjektet er ferdig» garanterer ingenting:

• kodelageret med koden til temaet og egne utvidelser ligger på kundens konto, og byrået har tilgang til det, ikke omvendt,
• kunden har egen administratorkonto i WordPress og tilgang til webhotell, domene og DNS,
• en liste over betalte utvidelser med opplysning om hvem lisensene står på og når de fornyes,
• hvor sikkerhetskopiene lagres og hvordan de gjenopprettes, testet minst én gang,
• en liste over eksterne tjenester koblet til nettstedet (betaling, e-postutsendelser, analyse, API-nøkler til AI-modeller) med opplysning om hvem som betaler for hver av dem.

Det siste punktet er nytt. Nettsteder der byrået har koblet på sin egen API-nøkkel til en AI-modell, for eksempel for å lage produktbeskrivelser, slutter å virke den dagen byrået slår av nøkkelen. Kunden bør vite om hver slik nøkkel og kunne erstatte den med sin egen.

Vær også varsom med rabatt «fordi AI gjør halvparten av jobben». Et redelig byrå kan sette ned prisen for trinn AI faktisk har gjort kortere, for eksempel første versjon av en mal. Det bør ikke sette ned prisen for kodegjennomgang, sikkerhet og vakt, for der tar ikke AI over ansvaret. Et byrå som gir rabatt på hele prosjektet, sparer som regel på testingen.

Team fra EU og EØS har her konkrete fordeler sammenlignet med team spredt fra California til Sør-Afrika: samme tidssone som kunder i Norden og Tyskland, personvernregelverket under Datatilsynet som utgangspunkt og mulighet til å møtes fysisk. Mot team fra billigere land vinner man ikke på timepris, så i tilbudet er det bedre å beskrive disse fordelene enn å love lavere pris.

#Når bør man sette bort et prosjekt i stedet for å ansette en senior fast?

Ikke alle firmaer har arbeid nok til en senior i full stilling. Da ser du etter et byrå som i praksis gjør det Blacksmith-annonsen beskriver: bruker AI til første versjoner og rutinearbeid, mens et menneske står ansvarlig for arkitektur, integrasjoner og publisering av endringer.

Be om et prisoverslag når:

• du trenger en WordPress-utvikler som tar over koden og gjennomgangene, ikke bare legger inn innhold,
• du skal innføre en MCP- eller AI-integrasjon på eget webhotell,
• konkurrenten lover at «Agenten gjør alt», og du vil vite hva det egentlig koster å drifte.

Beskriv i forespørselen mål, teknisk plattform, om WooCommerce er med, antall språkversjoner og om du har en testkopi av nettstedet. Prisen settes individuelt etter omfang. Skjemaet finner du på kontaktsiden.