Toevoegen als voorkeursbron op Google
AI verandert de manier waarop WordPress ontwikkelaars werken. Het kan code schrijven, helpen fouten op te sporen, onbekende API’s uitleggen en van een verzoek in gewone taal een prototype maken. Maar code maken is iets anders dan beslissen of die code op een live website thuishoort.
Juist bij WordPress is dat verschil belangrijk. Voor beslissingen over architectuur, prestaties, beveiliging, toegankelijkheid en onderhoudbaarheid moet je het project begrijpen. Een ontwikkelaar moet inschatten hoe code van AI past bij de plugins, thema’s en API’s van de site, en bij de zakelijke eisen.
AI kan helpen een oplossing te bedenken en uit te werken. Toch moet de ontwikkelaar nog steeds de aanpak beoordelen, onjuiste aannames ter discussie stellen en controleren of het resultaat echt het probleem oplost waar het om ging.
Voor dit artikel spraken we met vier WordPress ontwikkelaars over hoe zij dat oordeel gebruiken in hun werk met AI.
Ook code van AI moet je controleren
AI kan functies en API’s voorstellen die niet bestaan, projecteisen verkeerd begrijpen, onjuiste aannames doen en ongemerkt bugs toevoegen.
Gegenereerde code kan ook beveiligingsmaatregelen overslaan, zoals invoervalidatie, sanitization of output escaping. Die controles horen nog altijd bij de beveiligingsrichtlijnen van WordPress, hoe de code ook tot stand is gekomen.
Een concreet voorbeeld staat in Kinsta’s uitleg over AI-tools gebruiken om een WordPress plugin te bouwen. De plugin maakte een gebruikersrol met beperkte rechten. Toen Cursor de Quick Edit link probeerde te verwijderen, haalde het soms ook de Edit functie weg. De gevraagde wijziging in de interface was dus niet genoeg: de rol moest ook blijven doen waarvoor hij bedoeld was.
De les is niet dat je AI simpelweg opnieuw laat proberen. Als ontwikkelaar controleer je ook of het gedrag dat hetzelfde moest blijven nog klopt, niet alleen de feature die de tool moest aanpassen.
Eerst het probleem begrijpen, dan pas de code
Code schrijven is maar een deel van professionele WordPress ontwikkeling. Een ervaren ontwikkelaar moet ook het probleem begrijpen en zakelijke eisen vertalen naar een technische oplossing.
Dat betekent bepalen wat er gebouwd moet worden, hoe de onderdelen op elkaar aansluiten en hoe de oplossing het bedrijf op lange termijn helpt. Je kiest een geschikte architectuur, weegt voor- en nadelen af en denkt vooruit over onderhoud.
De ervaring van Mark Szymanski laat zien hoe dat werkt. Hij vertelt hoe hij verder is gegaan dan “pixel pushing” en AI nu inzet om complexere zakelijke applicaties te bouwen. Het doel is niet simpelweg om sneller een werkende website op te leveren. Het gaat erom te bepalen met welke combinatie van technologieën je het onderliggende bedrijfsprobleem het beste oplost.
Jos Velasco gebruikt AI om serverdata te analyseren en patronen te vinden die je handmatig veel tijd zouden kosten. Zo’n voorgesteld patroon moet de ontwikkelaar wel nog toetsen aan het gedrag van de site, voordat hij beslist wat er moet veranderen.
Van code schrijven naar code beoordelen
Als AI sneller wijzigingen genereert dan een team ze kan beoordelen, loopt alles vast op de beoordeling.
Het gaat niet alleen om de vraag of code van AI draait. Iemand moet bepalen of die code doet wat de bedoeling is, voldoet aan de juiste WordPress codeerstandaarden, past binnen de rest van de applicatie en klaar is voor productie.
Jos Velasco wijst op een verwant probleem: het beoordelen van code die met hulp van AI is geschreven en bij het WordPress project wordt ingediend. AI kan helpen een patch te maken, maar contributors en committers moeten nog steeds bepalen of die in het project thuishoort.
De AI-richtlijnen van WordPress leggen de verantwoordelijkheid duidelijk bij de contributor: de ingediende code begrijpen, die beoordelen en valideren, en de relevante tests draaien. Die verantwoordelijkheid begint al voordat een patch bij een maintainer terechtkomt.
Ontwikkelaars zetten AI ook in bij het beoordelingsproces zelf. Rich Tabor heeft beschreven hoe hij Claude Code en Copilot gebruikt als tools die elkaar aanvullen: hij laat de ene het werk beoordelen dat met de andere is gemaakt, terwijl hij zelf de technische beslissingen neemt. Ook Mike Auteri heeft geautomatiseerde codebeoordeling in zijn workflow opgenomen.
Auteri werkt testgestuurd: de mens schrijft de tests, de AI schrijft de implementatie. Doordat het verwachte gedrag vooraf vastligt, bepaalt de ontwikkelaar waaraan de implementatie moet voldoen. Zo hoeft de AI niet zelf zowel de eisen als de oplossing te raden.
Geslaagde tests of een positieve beoordeling door AI garanderen niet dat een wijziging klaar is voor productie. Volgens de richtlijnen van GitHub over Copilot kan geautomatiseerde beoordeling problemen missen of fouten melden die er niet zijn. Zo’n beoordeling hoort menselijke beoordeling aan te vullen, niet te vervangen.
Met prompt engineering ben je er nog niet
Leren hoe je goed met AI communiceert is waardevol. Maar een slimme prompt kunnen schrijven is niet de vaardigheid die een AI-ondersteunde ontwikkelaar onderscheidt.
Belangrijker is weten welke context AI nodig heeft, binnen welke grenzen het moet werken en hoe een geslaagd resultaat eruitziet.
Mark Szymanski pakt het contextprobleem aan met wat hij een AI Operating System (AIOS) noemt. Een deel daarvan is een verzameling bestanden met bedrijfsinformatie, ontwikkelprincipes, klantgeschiedenis en andere kennis over het project. In plaats van AI telkens met een algemene prompt aan het werk te zetten, geeft hij context over het project en het bedrijf erachter.
Die context neemt niet weg dat je de output moet begrijpen. Wie geen basiskennis van WordPress en webontwikkeling heeft, kan misschien werkende code maken. Maar die ziet dan niet welke compromissen erin zitten, en kan niet beoordelen of de code wel bij het project past.
Wat betekent dit voor de WordPress ontwikkelaar?
AI maakt niet vanzelf elke WordPress ontwikkelaar waardevoller. Wel kun je er meer mee gedaan krijgen, zolang je het oordeel behoudt dat nodig is om een aanpak te kiezen, de implementatie te beoordelen en het resultaat te onderhouden.
AI kan helpen de oplossing te bouwen. Maar de ervaren ontwikkelaar blijft verantwoordelijk voor de vraag of het ook de juiste oplossing is.
Bij Kinsta ondersteunen we dat werk met testomgevingen, waarin je wijzigingen test voordat ze op je live site komen, ingebouwde prestatiemonitoring om trage pagina’s te onderzoeken, en WordPress engineers die 24/7 klaarstaan voor hostingsupport. Bekijk onze WordPress Hosting en ontdek hoe die past bij je volgende project.
Bud Kraus werkt sinds 2009 met WordPress, als docent (zowel klassikaal als online), sitebouwer en contentmaker. Hij heeft instructievideo's geproduceerd en talloze artikelen geschreven voor WordPress-bedrijven.
