Waarom herkent Ollama je AMD GPU niet?

Lokale AI-tools zoals Ollama en LM Studio zijn gebouwd met Nvidia in gedachten. AMD-ondersteuning is er wel, maar vraagt meer handwerk. De kern van het probleem: ROCm, de software-laag die AMD-GPU’s laat praten met AI-frameworks, herkent niet elke GPU-architectuur automatisch. Nieuwere of minder gangbare AMD-chips krijgen een foutmelding, terwijl de hardware zelf prima modellen kan draaien.

ROCm staat voor Radeon Open Compute. Het is AMD’s antwoord op CUDA, de technologie van Nvidia waarmee GPU’s rekentaken uitvoeren zoals AI. Het probleem: ROCm heeft een lijst van officieel ondersteunde GPU-architecturen. Valt jouw kaart er net buiten, dan crasht de software of negeert hij je GPU gewoon.

De workaround die al jaren de ronde doet op forums: stel de omgevingsvariabele HSA_OVERRIDE_GFX_VERSION handmatig in. Hiermee vertel je ROCm dat jouw GPU zich moet gedragen als een andere, wel ondersteunde architectuur. Werkt prima, maar je moet weten welke waarde je invult. Verkeerde waarde? Crashes, trage output, of een model dat helemaal niet laadt.

Ik heb dit zelf verkeerd ingeschat toen ik voor het eerst een lokaal model probeerde te draaien op een AMD-systeem. Ik dacht dat het een driver-probleem was en heb een uur gezocht in de verkeerde richting. Het was gewoon die ene omgevingsvariabele. Sindsdien check ik dit altijd als eerste bij AMD-hardware.

Meer weten over hoe AI-tools en hardware samenwerken in een development-setup? In dit overzicht over AI code editors vergelijken in 2026 bespreek ik ook hoe de onderliggende hardware je workflow beïnvloedt.

ROCmFix: één commando, GPU herkend

ROCmFix is een Python-script dat de HSA_OVERRIDE_GFX_VERSION-instelling automatisch bepaalt en instelt. Het leest je GPU-informatie uit het Windows-register of via lspci op Linux, zoekt de juiste architectuurwaarde op, en schrijft de variabele permanent weg. Je hoeft geen forumdraden door te spitten voor de juiste waarde.

De tool werkt op zowel Windows als Linux. Op Windows leest hij de PCI-ID van je GPU uit het register. Op Linux gebruikt hij lspci, het standaardcommando om hardware-informatie op te vragen. Op basis van die ID zoekt ROCmFix de juiste GFX-versie op en stelt die in.

Draaien doe je zo:

python rocmfix.py

Wil je eerst checken wat er allemaal geïnstalleerd is? Gebruik dan:

python rocmfix.py doctor

Dat geeft een overzicht van je geïnstalleerde HIP SDK en Vulkan-componenten. Handig als startpunt voordat je begint met modellen laden.

ROCmFix werkt met CMD, PowerShell, Bash, Zsh en Fish. Je stelt de variabele permanent in of alleen voor de huidige sessie, afhankelijk van wat je kiest. Permanent is handig als je altijd met dezelfde GPU werkt. Sessie-instelling is beter als je wisselt tussen systemen of GPU’s.

Let op: ROCmFix is een community-tool, geen officieel AMD-product. Controleer altijd de broncode voordat je een onbekend script uitvoert met systeemtoegang.

ROCm of Vulkan: welke backend is sneller op jouw GPU?

Als je GPU eenmaal herkend is, komt de volgende vraag: draai je je modellen via de ROCm/HIP-backend of via Vulkan? Vulkan is een grafische API die je ook voor compute-taken inzet. ROCm is specifiek gebouwd voor GPU-rekentaken. Welke sneller is, verschilt per GPU-generatie. InferBench meet dit automatisch op jouw systeem.

Vulkan en ROCm/HIP geven op papier andere prestaties. In de praktijk hangt het af van je specifieke GPU, het model dat je draait, en de hoeveelheid VRAM die je tot je beschikking hebt.

InferBench automatiseert het vergelijken. Het werkt zo:

1. Eerst stuurt het een warm-up query, zodat het model volledig in VRAM geladen is.
2. Dan dwingt het een VRAM-unload tussen elke testrun, zodat caching de resultaten niet vertekent.
3. Het berekent de mediaan van tokens per seconde (tok/s) en de TTFT (Time-to-First-Token, de tijd tot het eerste woord verschijnt).

Die twee getallen zeggen je alles. Tok/s bepaalt hoe snel een lang antwoord gegenereerd wordt. TTFT bepaalt hoe snel de tool voelt voor de gebruiker. Een hoge tok/s met een hoge TTFT is frustrerend in gebruik, ook al is de totaalsnelheid goed.

Naar mijn idee is InferBench de ontbrekende schakel die mensen altijd overslaan. Ze draaien een model, het lijkt te werken, en ze stoppen daar. Maar zonder meting weet je niet of je 40% snelheid laat liggen omdat je de verkeerde backend gebruikt. Dat is zonde als je toch al de moeite hebt genomen om alles lokaal op te zetten.

Zie ook hoe lokale AI-tools passen in een bredere developer-workflow in dit artikel over de rol van developers in het AI-tijdperk.

Wanneer kies je voor een lokale LLM-setup op AMD?

Lokaal draaien van een AI-model heeft voordelen: geen API-kosten, geen data die de deur uitgaat, en je kunt offline werken. Maar het vraagt meer technische kennis dan een cloud-API aanroepen. Op AMD-hardware vraagt het nog wat extra stappen. Dit is mijn eerlijke afweging van wanneer het de moeite waard is.

Ik zou een lokale AMD-setup overwegen als je aan drie van de volgende vier punten voldoet:

• Je hebt een AMD GPU met minimaal 8 GB VRAM (minder werkt, maar dan draai je alleen kleine modellen).
• Je verwerkt gevoelige data die je niet naar een externe API wilt sturen.
• Je maakt intensief gebruik van AI en de API-kosten lopen op.
• Je hebt een half uur om de setup te doen en wil geen cloudafhankelijkheid.

Heb je een Nvidia GPU? Dan is de setup aanzienlijk eenvoudiger. CUDA werkt zonder gedoe, en Ollama herkent de meeste Nvidia-kaarten direct. AMD vraagt die extra ROCmFix-stap.

Heb je geen eigen GPU of wil je niet sleutelen? Dan is een cloud-API gewoon sneller en goedkoper voor de meeste use cases. De tools die hier besproken worden zijn voor developers die bewust kiezen voor lokaal draaien en de technische overhead accepteren.

Als je al werkt met lokale AI in je projecten, bekijk dan ook hoe je van het ene LLM-model naar het andere migreert zonder dat je applicatie omvalt.

Wat doet DeerFlow precies?

DeerFlow staat voor Deep Exploration and Efficient Research Flow. Dat klinkt ingewikkelder dan het is. In de kern is het een orkestratielaag: één hoofdagent die meerdere sub-agents aanstuurt, elk met een eigen taak. Eén zoekt informatie op, een tweede vat samen, een derde schrijft code op basis van die samenvatting. Allemaal gecoördineerd door DeerFlow, zonder dat jij dat handmatig hoeft te regelen.

Normaal betekent multi-agent (meerdere AI-agents die samenwerken) een berg custom code om context door te sturen, fouten op te vangen en de volgorde te bewaken. DeerFlow neemt dat van je over.

Het framework biedt drie dingen die ik direct interessant vind:

• Sub-agent orkestratie: je definieert wie wat doet, DeerFlow regelt de handoff.
• Geheugenbeheer: zowel kortetermijncontext (lopend gesprek) als langetermijngeheugen, zodat agents kunnen leren van eerdere runs.
• Sandboxing: agent-gegenereerde code voer je niet zomaar uit op je server. DeerFlow isoleert die uitvoering in een lokale omgeving, Docker-container of Kubernetes-pod.

Dat laatste is voor mij het meest waardevol. Als een agent code produceert die je niet 100% vertrouwt, wil je niet dat die zomaar op je productieserver draait. Met de instelling auto_approve_permissions: false in je config gaat er niets door zonder jouw goedkeuring. Eén regel, grote impact.

DeerFlow is ontwikkeld door ByteDance en bereikte in februari 2026 de eerste plek op GitHub Trending na de lancering van versie 2. Of dat betekent dat het de standaard wordt? Dat weet ik nog niet. Maar de technische basis is serieus genoeg om te testen.

Opzetten in minder dan 10 minuten: hoe werkt dat?

Je kloont de repo, typt drie regels en een wizard regelt de rest. Dat is het. DeerFlow vraagt je welke LLM je wilt gebruiken, of je web search wilt, en welke sandbox-modus je kiest. Daarna schrijft het zelf een config.yaml en slaat API-keys op in een .env bestand. Voor developers die graag zelf alles instellen: er is ook een uitgebreid template beschikbaar.

De setup ziet er zo uit:

git clone https://github.com/bytedance/deer-flow.git
cd deer-flow
make setup

De make setup wizard doorloopt de belangrijkste keuzes: LLM-provider, web search, sandbox-modus en schrijftoegang tot bestanden. Binnen een paar minuten heb je een werkende basisinstallatie.

Wil je meer controle? Dan gebruik je make config, dat kopieert het volledige configuratietemplate zodat je alles handmatig kunt aanpassen: subagent runtime-limieten, modelconfiguraties per agent, sandbox-instellingen.

Er is ook een ingebouwde health check:

make doctor

Dat commando controleert of alles klopt en geeft concrete suggesties als er iets mist. Klinkt als een detail, maar als je met Docker-containers en API-keys werkt, is een geautomatiseerde check een stuk betrouwbaarder dan zelf uitzoeken wat er misgaat.

Voor Docker-ontwikkeling:

make docker-init
make docker-start

Dit start je services met hot-reloading, zodat je config-wijzigingen direct worden opgepikt zonder handmatige herstart. Prettig als je iteratief werkt.

Welke AI-modellen werken met DeerFlow?

Vrijwel alles. GPT-4o, Gemini 2.5 Flash via OpenRouter, lokale modellen via vLLM, en zelfs CLI-gebaseerde tools zoals Claude Code. Je koppelt elk model aan een specifieke sub-agent, zodat je de goedkopere of snellere optie kunt inzetten voor eenvoudige taken en het zwaardere model reserveert voor de moeilijke stappen.

DeerFlow gebruikt langchain_openai:ChatOpenAI als basis voor OpenAI-compatibele providers. Dat betekent dat alles met een OpenAI-compatibele API direct werkt, inclusief OpenRouter (die toegang geeft tot honderden modellen) en lokale vLLM-deployments.

Een voorbeeld uit de config.yaml:

models:
  - name: gpt-4o
    use: langchain_openai:ChatOpenAI
    model: gpt-4o
    api_key: $OPENAI_API_KEY

  - name: openrouter-gemini
    use: langchain_openai:ChatOpenAI
    model: google/gemini-2.5-flash-preview
    api_key: $OPENROUTER_API_KEY
    base_url: https://openrouter.ai/api/v1

  - name: lokaal-qwen
    use: deerflow.models.vllm_provider:VllmChatModel
    model: Qwen/Qwen3-32B
    api_key: $VLLM_API_KEY
    base_url: http://localhost:8000/v1

Elk model wijs je toe aan een specifieke sub-agent. Dat is slim: je kunt de goedkopere Gemini Flash inzetten voor het samenvatten van bronnen, en GPT-4o alleen gebruiken voor de stap die echt redenering vereist. Zo houd je de kosten in de hand.

Mijn voorkeur zou zijn om te beginnen met één model, de workflow stabiel te krijgen, en dan pas te differentiëren per agent. Direct met vijf verschillende modellen starten maakt debuggen lastig. Kies voor de eerste tests een model dat je al kent.

Als je meer wilt weten over het switchen tussen AI-modellen in een bestaande setup, is het artikel over LLM model migratie zonder gedoe een goede aanvulling.

Hoeveel server heb je nodig voor een stabiele DeerFlow-omgeving?

Voor productie raadt ByteDance 8 vCPU en 16 GB RAM aan als startpunt. Bij zware workflows, zoals meerdere agents tegelijk met actieve sandbox, heb je al snel 16 vCPU en 32 GB RAM nodig. Op minder dan 8 vCPU krijg je bottlenecks zodra de sandbox actief is. Linux met Docker is de meest stabiele deploymentkeuze.

Dit is het onderdeel dat veel tutorials overslaan, maar dat je later duur kan komen te staan. DeerFlow is geen lichtgewicht tool. De sandbox-modus voert code uit in geïsoleerde containers, en dat kost resources.

Richtlijnen voor productie:

• Minimaal: 8 vCPU, 16 GB RAM, 40 GB vrije SSD
• Intensief gebruik: 16 vCPU, 32 GB RAM (voor multi-agent runs of rapportgeneratie)
• OS: Linux met Docker is de aanbevolen combinatie

Voor development werkt Docker uitstekend en geeft het je isolatie zodat je lokale machine niet vervuild raakt met dependencies.

Naar mijn idee is dit ook het punt waar DeerFlow verschilt van simpelere AI-tools: het is infrastructuur, geen plugin. Je zet het op zoals je een backend-service opzet, niet zoals je een Chrome-extensie installeert. Dat vraagt een andere manier van denken.

Als je nu al nadenkt over de bredere verschuiving in hoe developers met AI werken, is het artikel over de developer rol in het AI-tijdperk een eerlijke blik op wat er verandert.

Is DeerFlow iets voor jou als developer?

DeerFlow is interessant als je complexe, meertraps AI-workflows wilt bouwen waarbij meerdere agents samenwerken. Het is niet geschikt als je simpelweg een chatbot wilt of een API wilt aanroepen. De leercurve is reëel, de infrastructuurvereisten zijn serieus, maar de controle die je terugkrijgt over hoe agents samenwerken is het waard als dat je use case is.

Eerlijk oordeel: DeerFlow is geen beginnersspeeltje. De setup is redelijk toegankelijk dankzij de wizard, maar zodra je meerdere agents met verschillende modellen gaat configureren en de sandbox serieus gaat inzetten, ben je bezig met infrastructuur.

Voor wie het wél interessant is:

• Developers die AI-workflows bouwen waarbij stappen van elkaar afhankelijk zijn
• Teams die agent-gegenereerde code veilig willen uitvoeren zonder hun productieserver te riskeren
• Projecten waarbij je wilt schakelen tussen LLM-providers per taak, voor kosten- of kwaliteitsoptimalisatie

Voor wie het minder geschikt is:

• Je wilt snel een chatbot of eenvoudige AI-assistent bouwen
• Je hebt geen server met minimaal 8 vCPU beschikbaar
• Je bent niet bekend met Docker en wil dat ook niet worden

Wat ik zelf zou doen: het lokaal opzetten met make setup, één eenvoudige workflow testen met twee agents en één model, en dan evalueren of de complexiteit gerechtvaardigd is voor het project. Niet direct in productie gooien.

Ben je ook bezig met het bouwen van AI-agents voor specifieke taken? Het artikel over AI-agents als ontwikkelteam laat zien hoe zo’n opzet er in de praktijk uitziet.

Wat is digital signage eigenlijk?

Digital signage is het aansturen van schermen op afstand. Denk aan de menukaart bij een café, een welkomstscherm in een kantoor of een promobord in een winkel. Normaal betaal je maandelijks voor de software die dat regelt. Visio-Display gooit dat model om: je host het zelf, betaalt niets per maand en hebt volledige controle.

De meeste digital signage-oplossingen werken als een SaaS-abonnement: je betaalt per scherm, per maand, voor software die op andermans servers draait. Dat klinkt prima tot je zes schermen hebt en de factuur oploopt naar honderden euro’s per jaar.

Visio-Display pakt dit anders aan. Het is een digital signage open source platform (de broncode is vrij beschikbaar en je mag het gratis gebruiken en aanpassen) dat je op je eigen server installeert. Technisch draait het op Python, Flask en PostgreSQL, met Docker Compose voor de deployment. Je beheert alles via een webinterface: welk scherm toont wat, wanneer en hoe lang.

Wat opvalt is dat het project verder gaat dan alleen een filmpje op een scherm zetten. Het dekt de hele operationele kant: planning op datum en tijd, prioriteitscampagnes die automatisch terugvallen op het normale schema, een ingebouwde editor voor aankondigingen en een QR-codegenerator. Dat is meer dan je verwacht van een gratis project. De vraag is wel hoe stabiel dit is op de lange termijn als de ontwikkelaar ermee stopt, maar dat geldt voor elk open-source project.

Hoe werkt de installatie in de praktijk?

Eén commando en de installer regelt de rest: prerequisites checken, repository klonen, secrets genereren, containers bouwen en opstarten. In de praktijk heb je wel een Linux-server nodig met Docker en Docker Compose al geïnstalleerd. Voor iemand die dat gewend is, duurt de installatie tien minuten.

De installatie start je met dit commando op je Linux-server:

bash <(curl -fsSL https://raw.githubusercontent.com/woofix/visio_display/main/server-install.sh)

De installer doorloopt de volgende stappen: hij checkt of Docker en Git aanwezig zijn, kloont de repository, genereert beveiligingstokens, maakt een beheerdersaccount aan en start de hele stack op. Je kiest tussendoor de taal (Frans of Engels) en geeft een paar basisinstellingen in. Daarna heb je een werkende omgeving.

Let op: je hebt een server nodig die 24/7 online is. Een goedkope VPS van vijf euro per maand werkt prima als je maar een paar schermen hebt. Maar die server moet je zelf bijhouden, patchen en monitoren. Als je liever focust op je eigen werk en niet op serveronderhoud, is een betaalde SaaS-oplossing alsnog goedkoper dan het klinkt.

Er is ook een handmatige Docker Compose-installatie gedocumenteerd voor mensen die elke stap zelf willen controleren. Dat is de veiligere keuze als je weet wat je doet.

Hoe beheer je schermen op afstand?

Elk scherm draait als een Linux-kiosk-client en stuurt elke 30 seconden een heartbeat naar de server. Valt het scherm weg? Na vijf minuten markeert de server het als offline. Komt het terug online, dan herkent de server het automatisch. Geen handmatig opnieuw koppelen.

Remote beheer van schermen is normaal een gedoe: een scherm valt weg, iemand moet er fysiek naartoe, opnieuw inloggen, opnieuw koppelen. Visio-Display lost dat op met een systemd-service (een achtergrondproces dat automatisch start bij het opstarten van de computer) op elke client.

Die service stuurt elke 30 seconden een signaal naar de server. Valt het scherm weg door stroomuitval of een netwerkprobleem? De server markeert het na vijf minuten als offline. Zodra het scherm herstart en weer online komt, pakt de service het gewoon op. Geen handmatige tussenkomst.

Via de webinterface zie je per scherm: is het online, welk scherm laat het zien, en je kunt een screenshot opvragen. Remote acties als herstarten, afsluiten, opnieuw installeren of updaten doe je ook vanuit de interface. Deployment van nieuwe Linux-clients gaat via SSH (een beveiligde verbinding om op afstand in te loggen op een server).

Vergelijk dit met hoe je WordPress-infrastructuur op afstand monitort en automatiseert: het principe is hetzelfde. Ik vraag me af hoe dit werkt met grote aantallen schermen, zeg vijftig of meer. De documentatie geeft daar geen antwoord op.

Voor wie is self-hosted digital signage een goed idee?

Ben je technisch onderlegd, beheer je al een server en vind je privacy of databeheer belangrijk? Dan is Visio-Display interessant. Ben je ondernemer die gewoon wil dat zijn schermen werken zonder erover na te denken? Dan is een betaalde dienst eerlijker. Self-hosting is geen gratis lunch, het is een andere manier van betalen: met tijd in plaats van geld.

De eerlijke afweging is deze: self-hosted software is alleen gratis als je eigen tijd niets waard is. En dat is zelden zo.

Visio-Display is een goede keuze voor:

• Developers of IT-beheerders die toch al een server runnen
• Organisaties met strikte eisen aan dataopslag (geen data op externe servers)
• Projecten met veel schermen waar een SaaS-abonnement snel duur wordt
• Mensen die willen experimenteren en leren

Het is geen goede keuze voor:

• Ondernemers zonder technische achtergrond die gewoon een scherm willen aansturen
• Situaties waar 99,9% uptime kritisch is (je bent zelf verantwoordelijk)
• Teams zonder iemand die Docker en Linux begrijpt

Er zijn betaalde alternatieven zoals ScreenCloud, Yodeck of Screenly die voor 10 tot 20 euro per scherm per maand alles regelen inclusief support. Als je twee schermen hebt, is dat 240 tot 480 euro per jaar. Dat is wat het je kost om er niet over na te hoeven denken. Soms is dat de betere investering.

Wil je weten hoe zulke afwegingen voor andere development-tools uitpakken? Mijn vergelijking van AI-code-editors Cursor, Windsurf en Zed gaat over hetzelfde principe: gratis vs. betaald, en wat het je in de praktijk kost.

Waarom een standaard portfolio je niet meer opvalt?

De meeste developer-portfolio’s zien er hetzelfde uit. Hero-sectie, zwevende mockups, contactformulier. Dat was drie jaar geleden al saai. Wil je opvallen, dan bouw je iets dat mensen niet verwachten. Een IDE-interface is zo’n keuze: die laat direct zien hoe je denkt als developer, nog voor iemand een regel code leest.

Ik begrijp waarom de meeste portfolios op elkaar lijken. Je zoekt een template, past de kleuren aan, voegt je projecten toe en klaar. Werkt ook prima als je gewoon een URL wilt sturen. Maar als je echt wilt laten zien dat je code schrijft en systemen bouwt, is een generieke pagina een gemiste kans.

Een IDE-stijl portfolio doet iets anders. Het laat de manier zien waarop je werkt, niet alleen de uitkomsten. Bezoeker klikt op about.html in een file-tree aan de linkerkant, en de inhoud verschijnt rechts. Dat voelt als VS Code. Voor een developer-doelgroep is dat onmiddellijk herkenbaar.

Dit is de sterkste route als je solliciteert bij een tech-bedrijf of freelance-klanten aantrekt die zelf ook technisch zijn. Voor een kapper of een coach raad ik dit af, want die doelgroep heeft er niets aan. Maar voor een developer? Perfect. Check ook hoe AI-code-editors zoals Cursor en Windsurf je bouwtijd flink kunnen verkorten.

Welke tech stack gebruik je voor een IDE-portfolio?

De kern is Next.js voor routing en componentstructuur, Tailwind CSS voor de strakke geometrische styling, en GSAP voor animaties. GSAP staat voor GreenSock Animation Platform: een JavaScript-bibliotheek waarmee je complexe, vloeiende animaties bouwt die je met gewone CSS niet voor elkaar krijgt. DotLottie verzorgt lichte vectoranimaties voor de laadschermen.

Next.js is hier de logische keuze. Je krijgt automatisch routing op basis van je bestandsstructuur, en Vercel deployt het zonder configuratie. Dat scheelt je minstens een uur aan deployment-gedoe.

Tailwind CSS zorgt voor de strikte CSS grid die het IDE-gevoel geeft. Geen flexbox-gedoe waarbij de sidebar ineens over de content schuift op mobiel. Met Tailwinds utility-classes bouw je exact de layout die je wilt, en je stelt de breakpoints strak in.

Dan GSAP. Dit is waar de magie zit. De preloader gebruikt een zogenaamde split-gate reveal: twee donkere vlakken die van het scherm schuiven, omhoog en omlaag, zodat de IDE eronder tevoorschijn komt. Dat bouw je met een GSAP-timeline, zo:

gsap.timeline()
.to('.gate-top', { y: '-100%', duration: 0.8, ease: 'power2.inOut' })
.to('.gate-bottom', { y: '100%', duration: 0.8, ease: 'power2.inOut' }, '<')

De '<' laat beide animaties tegelijk starten. Simpel maar effectief. Voor de knipperende terminal-cursor gebruik je gewoon een CSS keyframe-animatie op een solid blok: geen extra library nodig.

Hoe bouw je de file-tree navigatie die als router werkt?

De file-tree is de kern van de interface. Bestanden zoals about.html of projects.js staan in een linker sidebar. Klik erop en de rechter weergave wisselt van inhoud. In Next.js implementeer je dit met een state-variabele die bijhoudt welk bestand actief is, gecombineerd met conditionele rendering van je content-componenten.

De file-tree zelf bouwen is niet het moeilijkste. Je maakt een array van objecten met bestandsnamen en bijbehorende componenten, en rendert die als een lijst. Klikken zet de actieve state, en de content-zone toont het bijbehorende component.

Schematisch ziet dat er zo uit:

const files = [
{ name: 'about.html', component: <About /> },
{ name: 'projects.js', component: <Projects /> },
{ name: 'experience.ts', component: <Experience /> },
];

// In de content-zone:
{active.component}

Let op: op mobiel blijft de standaardfout dat de sidebar open blijft na het klikken op een bestand. De content staat dan half verborgen achter de navigatie. De oplossing is een state-dispatcher die de sidebar automatisch sluit zodra je een bestand selecteert. Één regel extra logica in je click-handler, maar het scheelt veel frustratie bij gebruikers op telefoon.

Voor de styling gebruik je CSS grid met een vaste breedte voor de sidebar (w-48 of w-64 in Tailwind) en de rest voor de content. Zorg dat de grid niet breekt op kleinere schermen door de sidebar op mobiel standaard verborgen te zetten.

Hoe deploy je dit zonder hoofdpijn op Vercel?

Vercel en Next.js zijn gemaakt voor elkaar. Je pusht naar GitHub, Vercel detecteert automatisch dat het een Next.js-project is en bouwt het. Geen serverconfig, geen pipeline handmatig instellen. Je koppelt je domein aan Vercel’s nameservers en HTTPS is direct geregeld. Voor .dev-domeinen is HTTPS trouwens verplicht, niet optioneel.

De deployment is het makkelijkste deel van dit project. Maak een Vercel-account, koppel je GitHub-repository en Vercel doet de rest. Bij elke push naar je main-branch bouwt Vercel automatisch een nieuwe versie en zet die live. Geen handmatige FTP-uploads, geen server die je zelf beheert.

Eén ding om op te letten: gebruik je een .dev-domein, dan is HTTPS verplicht. Dat zit ingebakken in de TLD zelf. Browsers weigeren HTTP-verbindingen naar .dev-adressen. Vercel regelt dit automatisch via hun edge-netwerk, dus je hoeft er niets voor te doen.

Wil je het repository privé houden? Dat kan gewoon. Vercel heeft toegang tot je GitHub-repo voor de build, maar de code blijft privé voor de buitenwereld. Handig als je werk voor klanten in de repo hebt staan dat je niet wil delen.

Vergelijk je dit met traditionele WordPress-hosting: dit is sneller, goedkoper voor een statische site, en je hebt geen plugin-updates of beveiligingslekken om je druk over te maken. Voor meer context over WordPress beveiligingsupdates en wat je daarmee moet heb ik eerder geschreven.

Is dit voor elke developer de juiste keuze?

Eerlijk antwoord: nee. Een IDE-portfolio is indrukwekkend als je doelgroep technisch is. Maar bouw je websites voor lokale ondernemers of werk je als freelance designer voor niet-technische klanten, dan slaat dit concept de plank mis. Ken je doelgroep voordat je 60 uur in een custom preloader stopt.

Mijn onderbouwde standpunt: ik zou dit type portfolio alleen bouwen als je weet dat de mensen die het bekijken er iets mee kunnen. Een CTO die een developer aanneemt? Die snapt de file-tree direct en is onder de indruk. Een MKB-ondernemer die een website wil laten bouwen? Die raakt verdwaald en klikt weg.

Wees ook realistisch over de bouwtijd. GSAP leren, de split-gate animatie debuggen op Safari (want Safari doet altijd iets anders), de mobiele sidebar goed laten werken: reken op 40 tot 80 uur als je dit from scratch bouwt en GSAP nog niet kent. Ken je GSAP al, dan kom je eerder uit op 20 tot 30 uur.

Wil je sneller resultaat? Gebruik een bestaande template als startpunt en pas die aan. Dat levert in 8 tot 10 uur een werkende versie op. Minder origineel, maar wel sneller live.

Wil je AI inzetten bij het bouwen van dit soort animaties? Ik heb goede ervaringen met Claude Code voor web-animaties. Het schrijft GSAP-code op basis van een beschrijving, wat je veel trial-and-error bespaart. En als je wil weten hoe de rol van developers verandert in het AI-tijdperk, dat is ook de moeite waard om te lezen.

Wat zit er precies in WordPress 7.0.3?

WordPress 7.0.3 lost twaalf beveiligingsproblemen op in één keer. Dat is ongewoon veel. Normaal zijn het er één of twee per release. Drie van de twaalf zijn serieus genoeg om direct aandacht aan te geven: een XSS-lek op de inlogpagina, een SSRF-probleem in URL-validatie, en een privilege-escalatie op multisite-installaties. De rest is minder urgent maar alsnog de moeite van patchen waard.

Twaalf kwetsbaarheden in één release is niet normaal voor WordPress core. De meeste lekken zitten in blokken die bijdragers kunnen gebruiken, zoals de Post Date block, Post Content block en de Quick Edit-functie. XSS staat voor Cross-Site Scripting: een aanval waarbij kwaadaardige code de pagina ingaat en de browser van een nietsvermoedende gebruiker die code dan uitvoert.

De meeste van die twaalf vereisen een account met minimaal de rol Contributor, wat het risico beperkt. Maar drie kwetsbaarheden vallen in een andere categorie. Die bespreek ik hieronder apart.

Overigens heeft de toename van gevonden lekken deels te maken met AI-gestuurde beveiligingstests. Beveiligingsonderzoekers gebruiken AI-tools om code sneller te scannen op patronen die mensen missen. Goed voor de veiligheid op lange termijn, maar het betekent ook dat het aantal meldingen de komende tijd niet daalt.

Het XSS-lek op de inlogpagina scoort 8.9/10. Hoe werkt dat?

Dit is het gevaarlijkste lek van de batch. Het zit op de inlogpagina van WordPress en heeft een ernstscore van 8.9 op 10. Een aanvaller heeft geen account nodig om het lek te triggeren, vandaar de naam ‘pre-auth’. Toch is de kans op misbruik beperkt, want de aanval werkt alleen als iemand met een account op jouw site op een speciaal geconstrueerde link klikt.

Stel je voor: een aanvaller bouwt een nep-website met een link die eruitziet als jouw WordPress-inlogpagina. Als een beheerder of redacteur op die link klikt, draait er kwaadaardige code in zijn browser. In het ergste geval escaleert dat naar Remote Code Execution (RCE), wat inhoudt dat code op jouw server actief wordt.

Dat klinkt alarmerend, en dat is het ook, maar de aanval vereist social engineering. De aanvaller moet de juiste persoon overtuigen om op de juiste link te klikken. Beveiligingsonderzoekers schatten de kans op actief misbruik als laag in, juist omdat die menselijke stap er altijd tussen zit.

De fix gaat terug tot alle WordPress-versies vanaf 4.7. Draai je nog een oudere versie, dan is de patch er alsnog, maar je moet wel updaten.

Voor wie zijn WordPress-installaties beheert: AI inzetten om WordPress-code te analyseren en te verbeteren helpt je sneller onveilige patronen te spotten in custom code die je zelf hebt toegevoegd.

SSRF en privilege-escalatie: ook serieus nemen?

Naast het XSS-lek zijn er twee andere kwetsbaarheden die aandacht verdienen. SSRF staat voor Server-Side Request Forgery: een aanval waarbij de server verzoeken stuurt naar interne netwerkadressen. De derde is een privilege-escalatie op multisite-installaties waarbij een gewone gebruiker een nieuwe site kan aanmaken.

SSRF in URL-validatie klinkt technisch, maar de kern is dit: als een aanvaller de server laat communiceren met interne IP-adressen (link-local ranges), kan gevoelige informatie uitlekken die normaal niet van buitenaf bereikbaar is. Denk aan configuratiedata van je server of interne services. Hoe ernstig dit precies is voor standaard WordPress-hosting is nog niet volledig gedocumenteerd, maar de patch is er en dat telt.

De privilege-escalatie op multisites is relevant als je WordPress Multisite draait met open gebruikersregistratie. Een normale gebruiker kan dan een nieuwe subsite aanmaken op jouw netwerk. Voor een universiteits-intranet of een platform met honderden subsites is dat een echt probleem. Voor een standaard WordPress-site met één domein speelt dit niet.

Ga naar je WordPress-dashboard, klik op Instellingen, dan Netwerk als je multisite draait. Staat gebruikersregistratie aan en weet je niet waarom, zet hem dan uit.

Wat ik in mijn eigen werk zie veranderen

Ik ben zelf developer en ik werk dagelijks met AI-tools voor klantprojecten. Het verschil met twee jaar geleden: ik typ minder code, ik review meer. Ik schrijf minder algoritmes, ik schrijf meer specificaties. De rol is niet kleiner geworden, hij is verschoven. Wie nog elke regel zelf wil typen omdat dat "echt programmeren" is, loopt achter.

Twee jaar geleden begon ik een feature met een lege editor en een idee. Nu begin ik met een prompt: hier is de huidige code, hier is wat ik wil, schrijf de eerste versie. De AI tikt het in 30 seconden uit. Daarna komt mijn werk: kloppen de assumpties, zit er geen verzonnen library in, hoe gaat dit zich gedragen onder load.

Niet elke developer ervaart dit zo. Sommige collega’s negeren AI bewust. Anderen accepteren elke gegenereerde regel klakkeloos. Beiden lopen risico. De eerste groep raakt achter omdat AI-tools zo sterk worden dat handmatig coderen straks duurder is. De tweede groep stopt productie-bugs in hun software omdat ze de output niet snappen.

Wat blijft, en zelfs belangrijker is geworden: weten waarom code werkt. Niet alleen of het werkt. Bij mijn klanten zie ik dat de developers die het beste presteren, de developers zijn die kritisch lezen en doorvragen op de output. Niet de developers die het hardst typen.

Welke skills écht waarde toevoegen in 2026

Architectuur, systeemontwerp, security en het schrijven van heldere specificaties. Dat is waar de waarde nu zit. AI bouwt componenten, jij ontwerpt het systeem. AI schrijft de query, jij beoordeelt of de query veilig is. Skills die niet goed door AI worden ingevuld zijn de skills die je doelgericht moet bijspijkeren.

De skills die in mijn ervaring nu het zwaarst wegen, in volgorde:

Systeemontwerp. Een AI kan een loginscherm bouwen, maar niet bedenken hoe authenticatie samenhangt met sessions, met de cache-laag, met de e-mailprovider, met je hosting. Dat overzicht moet uit een mensenhoofd komen.

Code reviewen met aandacht voor wat er níét staat. AI vergeet edge cases. AI verzint soms dependencies die niet bestaan. AI gebruikt soms verouderde APIs. Een goede review controleert wat ontbreekt, niet alleen wat er staat.

Security en privacy. AI-tools genereren regelmatig code met onveilige defaults: hardcoded secrets, ontbrekende input-sanitisatie, te brede CORS-headers. Wie dat herkent, voorkomt incidenten. De Autoriteit Persoonsgegevens publiceerde richtlijnen voor AI-gebruik waar elke developer met klantdata mee bekend hoort te zijn.

Specificaties schrijven. Een AI doet alleen wat je vraagt, en een vage vraag levert vage code op. Helder kunnen formuleren wat je wilt is geen managers-skill meer maar core developer-werk.

Wat dit betekent als jij een developer of freelancer inhuurt

Ondernemers die freelance-developers of een dev-team inhuren, kijken nu naar andere signalen dan vijf jaar geleden. Niet meer "kan deze persoon snel typen", maar "begrijpt deze persoon mijn business en kan hij de AI-output beoordelen". Een developer die alle code uit ChatGPT haalt zonder review levert je een tijdbom. Een developer die AI bewust inzet en de output kritisch leest, levert je in dezelfde tijd meer waarde op.

Drie concrete dingen die je nu anders moet doen bij het inhuren of werken met developers:

Vraag naar AI-werkwijze, niet naar AI-vermijding. Iemand die zegt "ik gebruik geen AI" is in 2026 vaak duurder dan iemand die het slim inzet. Niet omdat AI gratis is, maar omdat de eerste groep langer doet over hetzelfde werk. Vraag liever: hoe gebruik je AI in je workflow, en wat doe je om niet in valkuilen te trappen.

Reken op review-tijd, niet alleen bouwtijd. Vroeger schatten developers bouwtijd. Nu is bouwtijd korter en review-tijd langer. Een feature van twee weken oude stijl is misschien drie dagen bouwen plus drie dagen review. Plan beide in.

Eis documentatie van AI-keuzes. Welke libraries gebruikt de developer, welke daarvan zijn AI-suggesties, en welke tests zitten erop. Dit is je verzekering voor als de developer wegloopt en jij straks zelf de code moet onderhouden of overdragen.

Wat ik adviseer aan junior developers en ondernemers met een dev-team

Junior developers: leer de fundamenten zoals datastructuren, algoritmen en systeemontwerp. Daar bouw je je AI-werk bovenop. Ondernemers met een dev-team: investeer in pair-programming en code-review-cultuur, niet in meer AI-licenties. Tools maken het werk niet beter, kritisch denken doet dat.

Voor junior developers die net beginnen: laat AI niet je leerproces overnemen. Genereer code, ontleed hem, schrijf hem opnieuw vanaf scratch zonder AI, vergelijk. Dat is hoe je AI gebruikt om sneller te leren in plaats van langzamer.

Voor ondernemers met een eigen dev-team of freelance-developers: de grootste winst zit niet in betere tools maar in betere werkprocessen. Een uur per week pair-programmen levert meer op dan een nieuwe AI-licentie. Een verplichte code-review op AI-gegenereerde features voorkomt incidenten die je later weken kosten.

Voor ZZP’ers die zelf bouwen: het is geen schande om de AI te gebruiken voor je klantenwebsite. Het is wel een probleem om de output blind te plaatsen. Schrijf een korte review-checklist en ren die door op alles wat AI voor je maakt: input-validatie, foutmeldingen, edge cases, security-headers. Vijf minuten controle voorkomt een uur incident-respons.

Cursor: de veilige keuze die gewoon werkt

Cursor is een fork van VS Code met sterke AI-integratie ingebouwd. Het werkt direct goed zonder config-bestanden te moeten aanraken. AI-completions zijn snel, het Composer-paneel voor multi-file edits is intuïtief, en de agent-mode kun je op klantenprojecten gebruiken zonder bange momentjes.

Ik gebruik Cursor sinds een half jaar dagelijks voor klantprojecten. Wat ik fijn vind: het is gewoon VS Code met AI erop, dus al mijn extensies werken nog en mijn keybindings ook. Geen leercurve.

De AI-integratie is volwassen: tab-completion is snel, in-editor chat begrijpt context van het hele bestand, en agent-mode kan zelfstandig multi-file changes doen die ik daarna review. Voor klantcode hou ik agent-mode op handmatige bevestiging, laat de AI niet ongezien door productiecode banjeren.

Prijs: 20 dollar per maand voor Pro. Dat is gelijk aan ChatGPT Plus, maar je krijgt er een werkende editor bij. Als je dagelijks codeert verdient dat zich snel terug.

Windsurf: voor wie verder wil dan completions

Windsurf is gemaakt voor agentische workflows. Het verschil met Cursor: de AI denkt vooruit en stelt zelf vervolgstappen voor. Voor 15 euro per maand een sterke optie, vooral als je AI als junior collega wilt inzetten op grotere taken.

Wat Windsurf onderscheidt is hoe diep de AI in je workflow zit. Bij een wijziging stelt hij vaak proactief voor om de bijbehorende tests, documentatie of types ook bij te werken. Dat is meer dan completions, het voelt als een collega die meedenkt.

De keerzijde: meer keuzes, dus meer ingrijpen om te voorkomen dat hij dingen wijzigt die jij niet wilde. Voor mij persoonlijk werkt dat minder fijn dan Cursor’s terughoudendere aanpak. Maar ik ken developers die er juist voor kiezen omdat het ze sneller maakt op grote refactors.

Zed: snelheid boven alles, nog ruw aan de randen

Zed is een editor in Rust gebouwd, met realtime collaboration en native AI-integratie. Voor het openen en doorzoeken van grote codebases is hij merkbaar sneller dan Cursor of VS Code. Maar het ecosysteem is jong en de AI-features zijn nog niet zo geslepen als bij de concurrentie.

Wat me bij Zed steeds opvalt: het opent een grote repository in een seconde, terwijl Cursor 5 tot 10 seconden nodig heeft. Voor wie veel met grote codebases werkt is dat een groot verschil over een werkdag.

Maar de AI-integratie loopt achter. Tab-completions zijn er, multi-file agentic edits zijn beperkter. Voor pure tekst-editing op snelheid is Zed top, voor zwaar AI-werk pak ik nog Cursor erbij. Beide naast elkaar werkt prima, ze gebruiken dezelfde keybindings als VS Code.

Wat "zelfverbetering" in AI nu echt is

Het mooie verhaal: AI traint AI, dus elke generatie wordt exponentieel beter. De realiteit: AI-modellen helpen met het genereren van trainingsdata en het destilleren van kleinere modellen. Echte recursive zelfverbetering bestaat niet, daar staat de vakwereld nog ver vanaf.

De marketing-versie van dit verhaal klinkt als sciencefiction: AI bouwt AI, en straks zijn we niet meer nodig. De technische realiteit is veel saaier. AI-modellen worden gebruikt om trainingsdata te labellen, om edge cases te genereren en om kleinere modellen te trainen op de output van grotere. Dat heet distillatie en het is geen magie.

Wat ik er bij klanten van merk: de tools die ik vorig jaar adviseerde zijn nu verouderd. Niet omdat AI zichzelf overtroffen heeft, maar omdat er gewoon snel nieuwe modellen worden uitgebracht en de prijzen schuiven. Dat is geen exponentiële zelfverbetering. Dat is een markt in beweging.

Het effect dat je écht merkt: tooling-instabiliteit

Wat ondernemers in 2026 voelen is geen exponentiële sprong, maar instabiele tooling. Een tool die zes maanden geleden goed werkte heeft nu een ander prijsmodel, andere features of is opgekocht door een groter bedrijf.

Concreet bij mij: ik adviseerde vorig jaar een klant om een specifieke AI-schrijftool te gebruiken voor zijn klantenservice-mails. Drie maanden later kocht een groter platform de tool, twee maanden later werd de prijs verdubbeld en verdween een feature die hij dagelijks gebruikte.

Dat is wat "exponentiële versnelling" in de praktijk betekent: niet dat alles beter wordt, maar dat alles sneller verandert. Voor een ondernemer is dat een planning-probleem, niet een opportunity-probleem.

Wat dit betekent voor je AI-strategie

Drie principes die ik bij elke klant inbouw: geen langlopende contracten op AI-tools, modulaire setups die makkelijk wisselbaar zijn, en niet je hele bedrijf bouwen op één leverancier. Dat klinkt voor de hand liggend, maar ik zie regelmatig anders.

Wat ik concreet doe: voor elke klant die AI integreert kies ik tools met een API die op meerdere providers werkt. OpenAI-compatible APIs van Anthropic, Google en open-source-modellen. Dat scheelt straks veel pijn als één leverancier zijn prijzen verdubbelt.

Voor klanten zonder eigen IT-team: kies maand-tot-maand abonnementen, niet jaarcontracten. De besparing van een jaarcontract is meestal 10 tot 20 procent. Het risico op vastzitten aan een tool die over zes maanden niet meer past, is veel groter dan die besparing.

Hoe je rustig blijft tussen alle hype

Ik heb een filter ontwikkeld voor AI-nieuws: lees pas de hands-on reviews na drie maanden, niet de launch-aankondigingen. Dat scheelt een hoop adrenaline en je mist niets dat er echt toe doet.

Wat ik bij mezelf merk: in het begin volgde ik elke launch live. Ik wilde direct testen, direct adviseren. Inmiddels wacht ik standaard drie maanden voordat ik een nieuwe tool serieus oppak. Driekwart van de hyped tools is dan al weer vergeten of merkbaar tegengevallen.

Mijn praktische tip aan klanten: abonneer je niet op AI-nieuws. Kies twee mensen die jij vertrouwt op het vak (geen AI-influencers, maar echte gebruikers) en lees alleen wat zij delen. Dat geeft je tijd terug en het signaal-naar-ruis-verhouding is veel beter.

Het patroon dat ik altijd gebruik bij animaties

Beschrijf wat de gebruiker zou moeten zien (niet de techniek), geef context over de stack en kies een animatie-bibliotheek. Drie zinnen prompt, een halve pagina werkende code terug.

Concreet bij een klant: hij wilde dat zijn productkaarten “subtiel oprijzen” als de gebruiker er overheen beweegt. Mijn prompt aan Claude: Ik werk in React 18 met Tailwind CSS en framer-motion. Maak een ProductCard component die een subtiele lift-animatie heeft op hover: 4px omhoog, lichte schaduw, 200ms duur, ease-out timing.

Resultaat: een werkend component dat ik direct kon gebruiken. Twee minuten finetune nodig om de schaduwsterkte iets minder zwaar te maken. Werk dat me vroeger een halve middag kostte aan tutorials kijken en code aanpassen, nu een kwartier.

Welke bibliotheken werken het beste

Voor React: framer-motion, sterk en goed gedocumenteerd. Voor vanilla JS: GSAP voor complexere flows, of pure CSS-keyframes voor eenvoud. Vermijd jQuery-animaties, dat is achterhaald en Claude voelt dat ook aan in zijn voorstellen.

Mijn ervaring per stack: framer-motion is voor React-werk een veilige eerste keuze omdat Claude er heel veel voorbeelden van kent en dus zelden onzin produceert. GSAP is breder en krachtiger maar vraagt meer instelwerk. Pure CSS-animaties zijn voor simpele effecten ideaal en kosten geen extra bibliotheek.

Bij klanten kies ik per project. Een marketing-landingspagina: pure CSS plus eventueel framer-motion voor één of twee key-momenten. Een interactieve webapp: framer-motion of GSAP afhankelijk van de complexiteit. Niet alles op één bibliotheek bouwen, niet alles los oplossen.

De finetune-fase die niemand overslaat

Animaties die op de eerste try goed voelen zijn zeldzaam. Timing, easing en delay zijn drie kleine knoppen waarmee je een animatie van "OK" naar "echt goed" brengt. Plan tijd in voor deze finetune, anders levert je werk halve kwaliteit op.

Wat ik bij elke animatie doe: nadat Claude code heeft opgeleverd, draai ik hem in de browser en kijk drie keer. Eerste keer voor de timing (te snel of te traag?), tweede keer voor de easing (voelt het natuurlijk of mechanisch?), derde keer voor de afstemming met andere elementen op de pagina. Per check minimaal één micro-aanpassing.

Tip uit eigen ervaring: animaties die op een snel scherm goed voelen, voelen op een traag scherm vaak haperig. Ik test bij klanten altijd op minimaal twee apparaten voordat ik iets als af bestempel.

Toegankelijkheid: het stuk dat AI vergeet

Claude denkt niet automatisch aan gebruikers die animaties willen uitschakelen. De CSS-mediaquery <code>prefers-reduced-motion</code> moet je zelf vragen. Bij elke animatie doe ik dat als laatste stap.

Wat ik standaard doe bij elke animatie: na de eerste werkende versie voeg ik handmatig de respect voor prefers-reduced-motion toe. Een gebruiker die deze instelling heeft staat (vaak vanwege vestibulaire klachten) krijgt dan geen of veel kortere animaties.

Een typische CSS-versie ziet er zo uit:

.product-card {
  transition: transform 200ms ease-out;
}

@media (prefers-reduced-motion: reduce) {
  .product-card {
    transition: none;
  }
}

Bij framer-motion is er een ingebouwde useReducedMotion-hook die hetzelfde doet. Vraag Claude er expliciet om, anders vergeet hij het. Toegankelijkheid en animaties zijn een paar dat je actief moet bewaken.

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.