Mijn meest voorkomende use-case: overgenomen WordPress-sites

Een klant stapt over van een vorige developer naar mij. Hij heeft een WordPress-site met aanpassingen die niemand meer kan uitleggen. Mijn eerste week is dan: AI gebruiken om de code te lezen en de waarheid van de fictie te scheiden.

Concreet vorige maand: een klant met een functions.php van 600 regels van een developer die er drie jaar geleden mee gestopt is. De klant kon niet uitleggen wat de helft deed, en sommige regels deden duidelijk niets. Voor de overdracht moest ik weten welke regels essentieel zijn en welke gewoon dood gewicht.

Mijn aanpak: in 30 minuten plakte ik blokken van 50 regels in Claude en vroeg hem per blok om uitleg, plus een advies over of het in 2026 nog werkt zoals het is geschreven. Wat normaal twee dagen leeswerk was, was een ochtend werk plus een middag verifiëren in de browser.

Wat AI bij WordPress-code wel en niet goed doet

Wel: bekende patronen herkennen, deprecated functies signaleren, security-zorgen aanwijzen. Niet: bugs vinden die afhankelijk zijn van runtime-staat, wat alleen optreedt bij specifieke gebruikersinput, of plugin-conflicten in een volle stack.

Bij mij in de praktijk: een AI vindt zonder problemen een gebroken nonce, een ontbrekende sanitize-call of een functie die in WordPress 6.4 is verwijderd. Dat soort lookup-werk is precies waar AI sterk in is: pattern-matching tegen een bekende kennisbank.

Wat AI minder goed doet: ingewikkelde plugin-conflicten waar twee plugins dezelfde hook overschrijven, of bugs die alleen optreden bij een specifieke combinatie van gebruikersinstellingen. Daar moet je nog steeds zelf debuggen, eventueel met een AI als sparringpartner.

Hoe ik AI integreer in mijn dagelijkse WordPress-werk

Twee tools, twee rollen. Claude voor codeanalyse en refactor-voorstellen, ChatGPT voor snelle "hoe doe je dit ook alweer in WP"-vragen. Beide actief tijdens het werken in mijn editor, niet alleen achteraf.

Ik gebruik dit dagelijks in een paar concrete patronen. Bij het beoordelen van een nieuwe plugin van een klant: één Claude-sessie open met de hele plugin-code geladen, dan vraag ik per functie om uitleg en risicoanalyse. Bij het schrijven van een custom blok: ChatGPT staat open in een tab voor snelle syntax-vragen die ik niet meer in mijn hoofd heb.

Wat ik bij klanten merk: een AI als sparringpartner versnelt het werk veel meer dan een AI als productiemiddel. Het idee dat AI volledig zelf code schrijft past niet bij hoe WordPress-werk in elkaar zit, omdat WP zoveel context-specifieke conventies heeft. Maar als sparringpartner is hij goud waard.

De grens: wat ik nooit aan AI overlaat in WordPress

Database-migraties, security-kritieke functies (login, betaalflows, gebruikersdata) en alles wat met klantgegevens te maken heeft. Daar kijk ik altijd zelf, eventueel met AI als tweede paar ogen.

Mijn vuistregel: hoe directer iets impact heeft op data of veiligheid, hoe minder ik AI alleen laat. Een nieuwe display-functie voor een productlijst? Prima, AI mag voorstellen doen die ik scan. Een aanpassing in hoe gebruikers worden geauthenticeerd? Daar zit ik bovenop, AI mag commentaar geven maar niet leiden.

Concreet bij een klant met WooCommerce: ik laat AI kijken naar de presentatie van producten, niet naar hoe betalingen worden afgehandeld. Het verschil tussen een lelijke productpagina en een gehackte webshop is groot. Voor het eerste accepteer ik snelheid, voor het tweede niet.

Je hebt Claude Code geïnstalleerd in één commando

Open je terminal en draai `npm install -g @anthropic-ai/claude-code`. Klaar. De installatie duurt minder dan een minuut. Wat je nodig hebt: Node.js 18 of nieuwer, een werkende npm en een Anthropic-account.

Voor wie nog geen Node.js heeft draaien: installeer eerst nvm (Node Version Manager) op macOS of Linux, of download de Node-installer voor Windows. Met nvm kun je later makkelijk wisselen tussen Node-versies, wat handig is als je meerdere projecten hebt.

Bij mij staat Claude Code op alle drie mijn werkmachines (laptop, desktop, server) en de installatie gaat overal precies hetzelfde. Geen platform-specifieke trucs.

Je bent ingelogd en hebt het juiste model gekozen

Eerste keer Claude Code starten doet hij een login-flow via je browser. Je kiest welk model standaard wordt: Sonnet voor algemeen werk, Opus voor zware taken, Haiku voor snelle hulp. Voor de meeste werkdagen werk ik op Sonnet.

Het login-proces opent een browser-tab waar je je Anthropic-account koppelt. Voor Pro- en Max-abonnees werkt dit direct, geen API-key gedoe. Voor enterprise-gebruikers met een eigen API-key voer je die in via een omgevingsvariabele: export ANTHROPIC_API_KEY=jouwkey.

Modelkeuze in het kort: Sonnet 4.5 of 4.6 is mijn dagelijkse paard, voldoende voor 90 procent van het werk. Opus zet ik aan voor complexere refactor-taken of architectuur-vragen, hij denkt langer en grondiger maar is duurder en trager. Haiku gebruik ik voor snelle eenmalige vragen waar volledigheid niet zo belangrijk is.

Je draait `claude` in je projectmap en hij begrijpt je code

Open je terminal in de map van je project en typ `claude`. Hij start een interactieve sessie waar je vragen kunt stellen over de code, wijzigingen kunt voorstellen of nieuwe features laten bouwen. Hij leest standaard de bestanden in de huidige directory.

Voor de allereerste sessie raad ik aan om iets kleins te doen: vraag Claude om een functie te leggen die hij vindt, of om een README te schrijven voor je project. Dan zie je hoe hij praat en hoe diep hij in je code duikt zonder dat je risico loopt op kapotte code.

Een paar handige toetsen tijdens een sessie: /clear begint opnieuw zonder context, /model wisselt van model, /permissions stelt in welke acties hij wel of niet zelfstandig mag uitvoeren. Bij klantprojecten zet ik permissions altijd op handmatig voor file-edits.

Je hebt een CLAUDE.md aangemaakt met je projectcontext

Een CLAUDE.md is een tekstbestand in de root van je project dat Claude bij elke sessie automatisch leest. Erin zet je je tech-stack, codeer-conventies, wat hij wel en niet mag doen, en eventuele klant-specifieke regels. Vergelijkbaar met DESIGN.md voor designtools.

Mijn standaard CLAUDE.md voor een Laravel-project ziet er ongeveer zo uit:

# CLAUDE.md

## Stack
- PHP 8.3, Laravel 11, MySQL 8
- Frontend: React 18, TypeScript, Tailwind, Vite

## Conventies
- PSR-12 voor PHP
- Eslint + Prettier voor TS
- Componentnamen in PascalCase
- Database-migraties altijd reversible

## Wat NIET
- Geen raw SQL, gebruik Eloquent
- Geen any-types in TypeScript
- Geen wijzigingen in /vendor of /node_modules

Per project pas ik dit aan naar de specifieke setup. Voor wie hier verder over wil lezen: de aanpak lijkt op die van DESIGN.md voor AI-designtools, maar dan voor code in plaats van visuele stijl.

Je hebt een werkroutine die past bij jouw projecten

Hoe ik Claude Code dagelijks gebruik: ochtends voor pull-request reviews en testen, middags voor het schrijven van nieuwe code in samenwerking, einde dag voor documentatie en cleanup. Niet alles tegelijk, niet bij elke regel code.

Concreet mijn werkdag bij een klantproject: ik begin met een prompt zoals “lees alle bestanden in /src en geef een overzicht van wat we nog moeten doen volgens de issues in /docs/todos.md”. Daar krijg ik een lijst en een aanpak. Daarna pak ik de eerste taak en bouw die samen met Claude.

Bij mij is het ritme: drie tot vier productieve coding-sessies van een uur per dag, met pauzes ertussen waarin ik Claude even uitzet en zelf nadenk. Volledig leunen op AI maakt me lui en haalt de scherpte uit mijn code-reviews. Pauzes nemen blijft belangrijk.