Je kent het probleem. Je weet precies waar klanten vastlopen. Je ziet hoe een betere oplossing eruitziet. Je weet welk formulier drie stappen te veel heeft. Maar tussen jouw kennis en een werkend product zit een muur van developers, backlogs en technische afhankelijkheden. Jouw idee belandt op plek 17 of het wordt gebouwd door iemand die de context niet heeft. En dan krijg je iets dat technisch klopt, maar de verkeerde dingen doet.
Jarenlang was dat de realiteit. Je kon als niet-developer het probleem haarscherp begrijpen en toch afhankelijk blijven van iemand anders om het op te lossen. Die afhankelijkheid is aan het verdwijnen. Niet omdat AI kan programmeren, maar omdat jij als domeinexpert nu zelf kunt bouwen. Met AI als je developer, en jouw kennis van het probleem als belangrijkste ingrediënt. Syntax leer je onderweg. Context niet.
Dat is een machtsverschuiving. Weg van wie kan bouwen, naar wie begrijpt wat gebouwd moet worden. Dit is geen theorie. Ik heb het gedaan. En jij kunt het ook.
Geen demo, geen speeltje
Ik had nog nooit een regel TypeScript geschreven. Ik wist niet hoe een terminal werkte, had geen idee wat een commit deed, en als iemand over serverless functions begon, haakte ik mentaal af. Nu draai ik een productieplatform met honderdduizenden regels code, meer dan tienduizend tests, tientallen backend-functies en een eigen contentsysteem dat strenger is dan de meeste redacties waar ik ooit mee heb gewerkt. Gebouwd door mijzelf. Met AI.
En nee, dan heb ik het niet over een ‘leuk demootje’ of een AI-speeltje dat het drie prompts volhoudt. Ik heb het over iets dat draait, gebruikt wordt, stukgaat, getest wordt, weer gefixt wordt en ondertussen gewoon doorbouwt.
Ik ben niet opeens developer geworden. Dat ben ik niet. Maar voor het eerst blijkt dit geen harde voorwaarde meer te zijn om serieuze software te bouwen. Dat is nieuw. Of preciezer: dat is de nieuwe realiteit waar veel organisaties nog naar kijken alsof het een gimmick is, terwijl het voor domeinexperts een complete machtsverschuiving is.
Eerst magie, dan chaos
Mijn eerste ervaring met AI-code voelde als valsspelen. Ik beschreef iets in gewone taal. De machine spuugde code terug. Ik plakte het in een project en het werkte.
Dat gevoel is verslavend. Zeker als je, zoals ik, jarenlang meer ideeën hebt gehad dan ontwikkelcapaciteit. Ineens valt die klassieke tussenlaag weg. Je hoeft niet meer eerst iemand anders mee te krijgen in jouw hoofd. Je kunt gewoon beginnen. En dus deed ik wat bijna iedereen doet: veel te hard gaan.
Feature na feature. Koppeling na koppeling. Nog een slimme laag erbovenop. Het voelde alsof ik eindelijk rechtstreeks kon bouwen zonder eerst door een trechter van resources, prioriteiten en technische afhankelijkheden te hoeven. Tot het onvermijdelijke moment waarop alles begon te rammelen. De code werkte nog wel. Het systeem niet meer.
Na drie weken had ik een verzameling losse onderdelen die elk op zichzelf functioneerden, maar niet als geheel. Dezelfde gegevens op vijf plekken. Dezelfde bug voor de derde keer gefixt. Geen idee meer waarom iets ooit zo was gebouwd. Dat is het moment waarop je leert dat AI je razendsnel productief kan maken, maar je ook met dezelfde snelheid een moeras in kan trekken.
Code was niet het probleem
Ik dacht dat mijn achterstand zat in programmeerkennis. Dat ik syntax, tooling en technische begrippen moest inhalen. Dat bleek maar half waar. Het echte omslagpunt zat ergens anders: ik moest leren denken als systeembouwer.
Niet: kan AI deze feature maken?
Maar: waar staat de waarheid in mijn systeem?
Niet: krijg ik dit scherm werkend?
Maar: wat breekt er als ik dit later aanpas?
Niet: kan ik iets publiceren?
Maar: onder welke voorwaarden mag iets live?
Dat zijn andere vragen. En precies daar gebeurt iets interessants. Want dat soort vragen liggen vaak dichter bij domeinexperts dan bij mensen die puur technisch naar software kijken.
Mijn voorsprong was domeinkennis
Ik ben al twintig jaar lid van Flying Blue, het loyaliteitsprogramma van KLM en Air France. Ik kende de logica, frustraties en onduidelijkheden van binnenuit. Ik wist waar mensen vastlopen, wat slecht wordt uitgelegd, welke keuzes slim zijn. Dat was mijn echte voorsprong. Niet dat ik kon programmeren, maar dat ik precies wist wat er inhoudelijk moest kloppen.
Op basis van die domeinkennis bouwde ik een analyticsplatform dat statusvoortgang voorspelt, ROI op miles berekent en de verborgen logica van het programma inzichtelijk maakt. Maar mijn diepste frustratie zat in mijn werk als Director of Content. Elk CMS die ik ooit gebruikte, deed hetzelfde: content invoeren en publiceren. Maar het vertelde je nooit of die content goed genoeg was. Geen scoringssysteem. Geen kwaliteitscontrole. Geen systeem dat zegt: dit is niet klaar.
Dat probleem wordt alleen maar urgenter. Mensen zoeken niet meer, ze vragen. Aan ChatGPT, aan Perplexity, aan Google AI Overviews. De vraag is niet meer hoe je hoger rankt. De vraag is: word je geciteerd door AI? En AI citeert niet de site met de meeste backlinks, maar de site die het antwoord het duidelijkst, het meest feitelijk en het best gestructureerd presenteert.
Dat verandert fundamenteel hoe content moet worden gemaakt. En ik wilde een systeem bouwen dat die verandering afdwingt. Niet als theorie. Als werkend product.
De machine die nee zegt
Wat de bezoeker ziet: een helder artikel. Nette opmaak. Actuele cijfers. Wat de bezoeker niet ziet, is wat er onder water gebeurt.
In een artikel staat: “je hebt 180 XP nodig voor Gold status.” Dat getal staat niet als losse tekst in het systeem. Het is een verwijzing naar een centrale bron. Verandert Flying Blue die drempel morgen? Dan hoef ik dat maar op één plek aan te passen en zijn alle 156 pagina’s in vier talen direct correct.
Waarom dat ertoe doet? Omdat mensen vergeten. Systemen niet. Een redacteur die handmatig 156 pagina’s moet bijwerken, vergeet er drie. Of, laten we eerlijk zijn: allemaal. Een systeem vergeet er nul.
Dat principe zit in het hele platform ingebakken. Het systeem blokkeert publicatie als content niet door 48 automatische checks komt. Te weinig woorden? Geblokkeerd. Geen bronvermelding? Geblokkeerd. Niet genoeg feitelijke ankers voor AI om te citeren? Geblokkeerd. De machine zegt nee. Niet de redacteur, niet de projectmanager. Het systeem. Die controles draaien niet in de interface, maar in de kern van het systeem: als harde poortwachter die je niet kunt omzeilen.
Waarom tests alles veranderen
AI kan geweldig programmeren. Maar is ook meedogenloos volgzaam. Je geeft een opdracht, het systeem gaat aan de slag. Zonder de kritische vraag of je wel zeker weet wat je vraagt. Want jouw nieuwe functie raakt onder water ook B, C en D. Alleen zie je dat als niet-developer vaak pas als het breekt.
Daar loopt elke starter op vast. Het systeem blijft breken. Het antwoord? Tests. Het klinkt technisch. Het is het tegenovergestelde.
Een test is een verwachting die je opschrijft. “Als iemand 180 XP heeft, moet het systeem Gold teruggeven.” Je beschrijft wat je verwacht in gewone taal. De AI schrijft de technische test. Vanaf dat moment controleert het systeem bij elke wijziging of die verwachting nog klopt.
Ik heb er 10.388.
Niet omdat ik testtheorie beheers, maar omdat tests het vangnet zijn dat mij als niet-developer in staat stelt om met vertrouwen wijzigingen door te voeren. Breekt er iets? De test vangt het op. Niet na een week in productie. Direct. Het is het verschil tussen ‘ik hoop dat het werkt’ en ‘ik weet dat het werkt’.
Mijn duurste les
Ik bouwde elf AI-agents die elke nacht de site controleerden. SEO-problemen, kapotte links, verouderde content. Het klonk perfect. Volledige automatisering. Met zelfs een intern ticketsysteem voor de agents onderling.
30 procent van de output was onzin. Verzonnen problemen. Verkeerde paginanamen. Fouten die al lang gefixt waren. Ik had een heel slim ogend circus gebouwd dat me vooral meer ruis gaf. Mijn oplossing: alle elf geschrapt. Vervangen door een simpel script dat dezelfde checks doet, maar voorspelbaar werkt. Nul valse meldingen. Tien seconden draaitijd.
De les: AI is niet altijd het antwoord. Soms is een dom, strak, voorspelbaar script beter dan een slim model. Niet verliefd worden op de tool. Kijken naar wat werkt. Die les geldt breder. Achteraf bleek de verdeling van mijn werk niet te zijn wat ik had verwacht. Niet 90 procent bouwen en 10 procent onderhoud. Eerder: 50 procent voorbereiding, 10 procent code schrijven, 40 procent bewaking en kwaliteitscontrole. Code schrijven bleek het kleinste deel.
Waarom domeinexperts nu winnen
AI kan coderen. AI kent jouw klanten niet, jouw processen niet, jouw frustraties niet. Een developer zonder domeinkennis bouwt iets dat technisch klopt, maar de verkeerde dingen doet. Een domeinexpert met de juiste tools bouwt iets dat het juiste probleem oplost. Die combinatie was altijd theoretisch. Nu is het praktisch.
De barrière is verschoven. Niet van ‘kan ik programmeren’ naar ‘hoef ik niet te programmeren’. Maar naar: begrijp ik mijn domein goed genoeg om er een systeem voor te ontwerpen? En heb ik de discipline om dat gestructureerd aan te pakken?
Wat je morgen kunt doen
Open een gesprek met AI en stel je eerste vraag
Claude Code, ChatGPT/Codex of Cursor zijn gemaakt om je te begeleiden, ook als je geen idee hebt waar je moet beginnen. Beschrijf je probleem in gewone taal. Stel elke vraag die je hebt. De drempel is niet kennis, maar durven starten.
Begin met je eigen irritatie
Niet ‘mensen willen vast wel X’, maar ‘ik word gek van Y’. Jouw dagelijkse frustratie is je oneerlijke voordeel. Je weet precies wanneer iets half werkt en wanneer het echt klopt.
Bouw één ding, niet een platform
Pak niet het hele probleem, maar één scherm. Eén flow. Eén berekening die klopt. Pas als dat ene onderdeel stabiel is, ga je uitbreiden. Niet eerder.
Leg vast wat altijd waar moet zijn
Welke regels gelden er? Wat mag nooit stukgaan? Wanneer moet het systeem ‘nee’ zeggen? Dat is geen documentatie. Dat is kennisarchitectuur. En het is precies waar domeinexperts beter in zijn dan developers.
Laat de machine controleren, niet jezelf
Schrijf verwachtingen op en laat het systeem bij elke wijziging checken of ze nog kloppen. Dat is wat tests doen. Niet technisch. Fundamenteel.
Wees niet verliefd op AI
Soms is een simpel script beter dan een slim model. De vraag is niet ‘kan AI dit?’ maar ‘wat werkt het meest betrouwbaar?’
Dit is pas het begin
Veel organisaties zien AI nog als versneller van bestaande rollen: sneller schrijven, sneller coderen, sneller analyseren. Dat is de helft van het verhaal. De interessantere helft is dat hele nieuwe groepen mensen nu dichter op uitvoering komen te zitten. Contentmensen. Specialisten. Productdenkers. Iedereen die jarenlang precies wist waar het pijn deed, maar voor de vertaling naar software afhankelijk was van anderen.
Niet de dood van de developer. Wel de opkomst van de domeinexpert als bouwer. Ik was niet de meest logische persoon om dit te bouwen, maar ik was de persoon die het probleem het best begreep. Dat bleek genoeg.
