Het probleem: AI-tools missen context van jouw merk

Je laat een AI een banner of UI maken en krijgt drie keer iets anders terug. Andere kleur, ander gevoel. Niet jouw stijl. Dat is geen bug. AI-tools werken op basis van wat je ze geeft. Zonder merkinformatie gokken ze op iets generieks.

Bij mijn klanten zie ik dit elke week. Vorige week kwam een klant in de hospitality bij me met drie social-posts uit een AI-tool: drie keer dezelfde prompt, drie keer een ander oranje. Hij dacht eerst dat het aan zijn ogen lag , tot ik de hex-codes naast elkaar zette en hij het verschil zwart-op-wit zag.

De fout zit niet in de tool, hij zit in het gebrek aan context. Bij Midjourney, Claude, ChatGPT en Figma AI werkt het allemaal zo. Geen merkinformatie? Dan gokken ze. DESIGN.md vult die context in één keer in en houdt hem voor elke volgende prompt vast.

Wat DESIGN.md is en waarom het werkt

DESIGN.md is een tekstbestand met je merkinfo in een formaat dat AI direct begrijpt. Geen formeel document. Geen technische specificatie. Kleuren als hex-codes, fontnamen, een paar stijlsteekwoorden, korte componentbeschrijvingen. Eén tot twee pagina's max.

Ik gebruik dit zelf voor elk klantproject sinds een half jaar. Het scheelt me makkelijk een uur per ontwerpronde aan corrigeren en herhalen. Werkt in elke AI-tool die tekst als input accepteert: ChatGPT, Claude, Midjourney, Figma AI, Cursor, Lovable.

Het bestand zelf hoef je nergens te uploaden. Je plakt de inhoud aan het begin van je prompt, daarna pas komt je opdracht. Resultaat: consistente output die er elke keer hetzelfde uitziet.

De vier basissecties die je opschrijft

Vier secties zijn genoeg. Kleuren als hex-codes (niet "donkerblauw" maar #0A1F44). Fonts met gewicht ("Inter Regular 400"). Drie tot vijf stijlsteekwoorden. Korte componentbeschrijvingen voor je terugkerende UI-elementen.

Concrete waarden zijn het belangrijkst. Niet “warm oranje” maar #F5821F. Niet “modern blauw” maar #0A1F44. AI vertaalt jouw woorden naar pixels, en die vertaling werkt alleen voorspelbaar bij exacte waarden.

Mijn eigen fout in het begin: te veel willen vastleggen. Ik schreef pagina’s vol met uitzonderingen, edge cases en gedragsregels per component. De AI raakte juist meer in de war en mengde regels door elkaar. Sinds ik me beperk tot een halve A4 met alleen de essentials, werkt het tien keer beter.

Voor componenten geef je één regel per type: “Primaire knop: oranje achtergrond, witte tekst, 4px border-radius, geen schaduw.” Dat is genoeg. Te veel detail laat de AI dwalen.

Werkend voorbeeld: DESIGN.md voor een bouwbedrijf

Dit is de DESIGN.md die ik gebruik voor een klant in de bouw. Concreet, in dezelfde structuur die ik altijd hanteer. Gebruik 'm als template: vervang de waarden door die van jou en je hebt binnen tien minuten een werkend bestand.

De fictieve klant heet “Bouwbedrijf Janssen”. De structuur hieronder werkt 1-op-1 voor elke andere branche, alleen de waarden verschillen.

# DESIGN.md ,  Bouwbedrijf Janssen

## Kleuren
- Primair: #1B3A57 (donkerblauw, voor headers en knoppen)
- Accent: #E8A33D (warm geel-oranje, voor CTA's en hover-states)
- Tekst: #1A1A1A op #FFFFFF
- Achtergrond licht: #F5F2ED (gebroken wit, geen plat wit)
- Lijnen en borders: #D4CFC4

## Typografie
- Headings: Montserrat SemiBold 600
- Body: Inter Regular 400
- Captions: Inter Light 300, 14px
- Knoppen: Montserrat Medium 500, all caps

## Stijl in steekwoorden
Solide, ambachtelijk, betrouwbaar, ruime witregels, geen schaduwen, foto's altijd warm-getint.

## Componenten
- Primaire knop: #1B3A57 achtergrond, witte tekst, 4px border-radius, hover #E8A33D
- Secundaire knop: transparant, 1px border #1B3A57, blauwe tekst
- Kaart: #FFFFFF achtergrond, 8px border-radius, 1px border #D4CFC4, geen schaduw
- Foto's: altijd 16:9, warme tint via 5% sepia-overlay

## Tone of voice
Direct, geen jargon, jij/je-vorm, korte zinnen. Vermijd: "innovatief", "passie", "kwaliteit". Gebruik: "we bouwen", "we leveren op tijd".

Plak deze inhoud aan het begin van je prompt en je AI-tool weet direct wat hij wel en niet moet doen. Een UI-generator levert nu een knop op met #1B3A57, niet met een willekeurig blauw.

Hoe je DESIGN.md in de praktijk gebruikt

In de praktijk: open je AI-tool, plak de DESIGN.md, daarna pas je opdracht. Werkt voor afbeeldingen, UI, code en zelfs teksten als je een tone of voice-sectie toevoegt. Maak twee versies: een korte voor snelle prompts, een complete voor diepere opdrachten.

Voorbeeld voor een UI-generator: “[DESIGN.md inhoud] Maak nu een contactformulier met deze stijl. Velden: naam, e-mail, bericht.” Je krijgt een formulier in jouw kleuren, met jouw font, met de juiste border-radius. Geen willekeur meer.

Voor afbeeldingsgeneratoren werk je met een ingedikte versie. Niet de hele DESIGN.md, alleen de relevante regels: primaire en accent-kleur, drie stijl-steekwoorden, eventuele foto-stijl. Vier regels meegeven werkt vaak beter dan twintig.

Voor AI-codeertools zoals Cursor of Claude Code sla je het bestand op in je projectmap. Tools die met repositorybestanden werken pikken het automatisch op als context. Wat ik bij klanten doe: bouw DESIGN.md in de eerste week van een project en sla hem op naast de README. Geen overleg meer over kleuren, geen “welk geel was het ook alweer?”. Het bestand is de bron van waarheid.

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.

Wat is er precies veranderd

Anthropic heeft de capaciteit voor Claude Code uitgebreid na deals met grote afnemers. Concreet betekent dat hogere usage-limieten op alle abonnementsniveaus, plus minder snel ratelimit-fouten tijdens lange coding-sessies.

De aanleiding is enterprise-vraag: SpaceX en een paar andere grote afnemers hebben deals gesloten die de capaciteit aan de Anthropic-kant flink omhoog hebben getrokken. Die extra ruimte komt deels ook beschikbaar voor de gewone Pro- en Max-abonnementen.

Eerlijk gezegd merkte ik de oude limieten alleen wanneer ik een hele middag aan één klantproject werkte met veel grote files in context. Wie Claude Code een paar keer per dag gebruikt voor losse vragen, loopt ze nooit aan. Voor de zware gebruikers verandert het wel iets.

Voor wie is dit relevant

Vooral voor developers die Claude Code als hoofdtool gebruiken bij grote refactors of in agentische workflows met meerdere parallelle taken. Voor occasionele gebruikers is het verschil nauwelijks merkbaar.

Bij mijn klanten zie ik dat de meeste developers Claude Code een paar uur per dag inzetten, met regelmatige pauzes. Die groep merkt geen verschil, want zij hebben de limieten zelden geraakt.

Wat wel verandert: agentische workflows die zelfstandig meerdere stappen uitvoeren (lees, schrijf, test, commit) werken nu langer door zonder onderbreking. Dat is winst voor wie Claude in CI/CD-pijplijnen gebruikt of als achtergrond-assistent op meerdere repositories tegelijk laat draaien.

Wat Mariner was en wat het deed

Project Mariner was een Chrome-extensie die je AI-opdrachten kon geven in natuurlijke taal: "vergelijk deze drie webshops op prijs", "vul dit formulier in met mijn gegevens", "boek deze vlucht". De AI navigeerde dan zelfstandig door websites om de taak uit te voeren.

Ik heb Mariner een paar weken getest in december 2025. Mijn favoriete use-case: prijsvergelijking. Geef de opdracht "vergelijk drie hosting-aanbieders op prijs en maandelijkse limieten", laat hem doen, krijg een overzichtje terug. Werkte beter dan ik had verwacht.

Wat minder werkte: alles wat met inloggen of betalen te maken had. Mariner stopte vaak halverwege omdat de site een captcha gaf, of hij twijfelde of hij wel met je accountgegevens mocht werken. Begrijpelijk vanuit veiligheidsperspectief, frustrerend in de praktijk.

Waar de functionaliteit naartoe is verhuisd

De agent-features zijn opgegaan in Gemini Agent (de chatbot die ook taken kan uitvoeren) en in Google Search (waar AI-Overviews ook meer taken uitvoeren). Voor de gewone gebruiker is dat een verbetering: minder losse tools, meer geïntegreerd.

Wie Mariner miste vindt het meeste terug in Gemini Agent. Het kan vergelijkbare taken: prijzen vergelijken, samenvattingen maken van meerdere bronnen, simpele formulieren invullen. De agent leeft binnen de Gemini-app of -webinterface, niet als browserextensie.

De andere kant: Google Search zelf wordt agentischer. Als je iets vraagt zoals "wat is de beste hosting voor een WordPress-site", krijg je geen lijstje meer maar een uitgewerkt antwoord met directe links. Dat is voor ondernemers waarschijnlijk het meest direct merkbare verschil.

Wat dit zegt over Google's AI-strategie

Google bundelt zijn AI-experimenten richting twee productlijnen: Gemini en Search. Losse experimenten zoals Mariner verdwijnen of worden geïntegreerd. Dat is goed nieuws voor focus, minder goed nieuws voor wie graag met early-stage tools werkt.

Een paar jaar geleden had Google soms drie verschillende AI-producten die hetzelfde leken te doen. Inmiddels lijkt het bedrijf intern de keuze gemaakt te hebben: Gemini is de assistent, Search is de antwoordmachine, en alles wat daar niet in past wordt opgegaan of opgeheven.

Wat je hier als ondernemer aan hebt: je hoeft minder verschillende Google-tools tegelijk in de gaten te houden. Wat je niet meer hebt: de speeltuin van early-stage experimentele tools zoals Mariner. Wie van die fase houdt zit beter bij Anthropic of OpenAI, die nog wel rauwere bèta-features uitbrengen.

Het kostenplaatje dat klanten verrast

De software is goedkoop. Een AI-tool kost per medewerker meestal tussen de 20 en 50 euro per maand. Wat klanten verrast: de tijd om de tool zinvol in hun werkproces te krijgen kost vaak meer dan de licentie zelf.

Vorig jaar adviseerde ik een ondernemer met acht medewerkers over een AI-schrijftool voor de klantenservice. De licentie was 35 euro per gebruiker per maand. Hij dacht dat hij voor 280 euro per maand klaar was.

De realiteit: drie weken om het team te trainen, twee dagen om de tool aan zijn helpdesk-systeem te knopen, en daarna nog wekelijks bijsturen omdat de AI antwoorden gaf die niet bij zijn merkstem pasten. Bij elkaar zat er aan zijn kant zo’n 40 uur in voor hij de tool echt productief had.

Niet ongewoon. Bij vrijwel elke klant die ik begeleid is de implementatietijd het grootste kostenpost, niet de tool zelf.

Waarom Anthropic en OpenAI nu consultancy aanbieden

Beide grote AI-bedrijven zijn aparte takken gestart die ondernemingen helpen met implementatie. Niet omdat hun tooling zo moeilijk is, maar omdat de implementatie-uren vaak buiten hun klanten hun bereik vallen.

Anthropic en OpenAI hebben in 2026 elk een professional services arm opgetuigd. Voor enterprise-klanten heel logisch: een MKB-bedrijf dat ChatGPT op zijn factuurproces wil zetten, weet vaak niet waar te beginnen.

Voor de gemiddelde Nederlandse ondernemer is dit pakket waarschijnlijk te zwaar (en te duur, denk in tonnen, niet in honderden euro’s). Maar het signaal is wel duidelijk: de AI-bedrijven zelf erkennen dat hun software alleen niet genoeg is om resultaat te halen. Daar zit een hint voor jou: investeer ook in begeleiding aan jouw kant.

Wat dit betekent voor je budget-planning

Plan voor elke AI-tool drie kostenposten: de licentie, de implementatie-uren en het onderhoud. Vergeet de derde post niet, die telt jaar na jaar door.

Mijn vuistregel als ik klanten een AI-tool aanraad:

Licentie: wat het bedrijf op de website vraagt, per maand maal twaalf.

Implementatie: tussen tweemaal en vijfmaal de jaarlicentie. Twee voor een eenvoudige use-case zoals klantenservice-mails, vijf voor iets dat in meerdere systemen moet haken.

Onderhoud: minimaal 10 procent van de jaarlicentie per kwartaal. Modellen veranderen, prompts moeten bijgewerkt, integraties breken. Dit kostenpost vergeten klanten consequent en het wreekt zich na zes maanden.

Mijn werkwijze bij klanten

Ik adviseer klanten altijd om eerst klein te beginnen: één proces, één tool, drie maanden uitproberen. Pas daarna opschalen. Dat voorkomt dat je vastzit aan een dure tool die niet bij je werk past.

Wat ik zelf doe bij elke klant: we kiezen één proces dat duidelijk afgebakend is en waar de pijn voelbaar is. Vaak klantenservice of routinematige tekstwerk. Daar zetten we drie maanden lang één AI-tool op, met een vast budget voor zowel software als implementatie.

Na drie maanden meten we: scheelt het echt tijd, klopt de kwaliteit, vinden de medewerkers het werkbaar. Pas als het antwoord drie keer ja is, breiden we uit. Dat scheelt veel achteraf-wisselen, en het maakt de echte kosten zichtbaar voordat je je hele bedrijf eraan vasthecht.

De klant die me hier serieus over leerde nadenken

Vorig jaar bouwde ik een MKB-site af waar de klant na lancering een feedback-mail kreeg van een potentiële koper: hij kon de bestelflow niet voltooien met zijn screenreader. Die mail was confronterend en heeft hoe ik nu werk veranderd.

Ik dacht dat ik het goed deed. ARIA-labels op de juiste plek, semantische HTML, focus-states. Maar in de echte test bleek dat één formulier-stap met een dropdown gewoon niet aan te roepen was zonder muis. Ik had het zelf nooit getest, want ik gebruik altijd een muis.

Sinds die mail test ik elke nieuwe site met alleen het toetsenbord, en open ik VoiceOver of NVDA op mijn machine voor minimaal vijf minuten per project. Niet omdat het verplicht is (dat is het in 2026 wel), maar omdat ik niet meer iemand wil weigeren die mijn site wel zou willen gebruiken.

De drie checks die ik standaard doe

Toetsenbord-navigatie (met Tab door alle interacties heen), tekstgrootte (vergroten tot 200 procent zonder dat de layout breekt), en kleurcontrast (controleren met een tool zoals WebAIM Contrast Checker). Drie minuten werk per pagina, vangt de meeste issues.

Mijn workflow per pagina, in volgorde: één: klik op het eerste interactieve element, druk Tab tot ik op het laatste interactieve element ben. Werkt elke link, elk formulier, elke knop? Twee: in browser-instellingen tekst op 200 procent zetten en kijken of er nog iets afgeknipt of overlappend is. Drie: elke tekst-kleur tegen elke achtergrond-kleur door de WebAIM-checker halen. Eis: minimaal AA-niveau (4.5:1 voor body-tekst).

Bij mijn klanten levert deze drie-check meestal vier tot acht concrete issues op een nieuwe site. Lost de helft op met simpele CSS-aanpassingen, andere helft vraagt om kleine HTML-aanpassingen.

Wat klanten vaak niet beseffen over de doelgroep

In Nederland heeft ongeveer 1 op de 8 mensen een vorm van beperking die hun online ervaring beïnvloedt. Dat is geen niche-doelgroep, dat is een ander klantsegment dat je nu mogelijk niet bereikt. Voor MKB-bedrijven is dat een reëel commercieel argument naast het ethische.

Wat ik bij klanten zie: ondernemers denken vaak dat toegankelijkheid alleen over blinde mensen gaat. In de praktijk gaat het ook over mensen met dyslexie (waar leesbare typografie veel uitmaakt), mensen met motorische beperkingen (waar grote klikvlakken cruciaal zijn), en oudere bezoekers (waar contrast en lettergrootte het verschil maken).

Voor een MKB-site met 1.000 bezoekers per maand betekent dit dat 100 tot 150 mensen een aangepaste ervaring nodig hebben om optimaal te functioneren. Wie die groep negeert laat een serieus stuk omzet liggen, en dat is naast de wettelijke verplichting (EN 301 549) een commercieel argument.

Wat ik klanten meegeef voor zelfonderhoud

Een korte checklist van vijf punten die ze elke nieuwe pagina kunnen aflopen. Plus duidelijke regels voor afbeeldingen (altijd alt-tekst), formulieren (altijd labels) en video (altijd ondertitels). Het gaat niet om perfectie, het gaat om consistentie.

Mijn standaard-checklist die ik elke klant in een PDF meegeef: één: elke afbeelding heeft een beschrijvende alt-tekst (geen “afbeelding van” voor de zekerheid). Twee: elke videobestand heeft ondertitels of een geschreven samenvatting. Drie: elk formulier-veld heeft een zichtbaar label, niet alleen een placeholder. Vier: elke link heeft een tekst die los van de context begrijpelijk is (geen “klik hier”). Vijf: elke knop is groot genoeg om met een vinger te raken (44×44 pixels minimum).

Vijf regels, drie minuten per pagina. Het is geen complete WCAG-audit, maar voor een MKB-bedrijf dat zelf content beheert is dit een prima dagelijkse ondergrens.

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.