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 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.

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.