I was “just” a CMS developer.
Then came AI

Ik ben ontwikkelaar en ik heb CMS’en gebouwd.

Ik heb er een groot deel van de afgelopen twintig jaar aan gewerkt. CMS betekende vaak WordPress, en WordPress betekende websites. Dat is een begrijpelijke associatie, maar ze vertelt slechts een deel van het verhaal.

Een titel, een foto en een knop ‘Publiceren’ zijn soms alles wat je ziet. Daarachter kunnen redacties, vertalingen, rechten, integraties en jaren aan inhoud schuilgaan die de volgende update moeten overleven. Van het werken aan die problemen heb ik het meest geleerd.

Vandaag kunnen veel meer mensen met AI een applicatie, een bedrijfssysteem of zelfs hun eigen CMS bouwen. Dat vind ik opwindend. En in die projecten herken ik veel van de problemen waaraan we jarenlang hebben gewerkt.

Hoe eenvoudiger software te genereren wordt, hoe nuttiger het is om te weten wat die software op langere termijn moet blijven kunnen. Over die ervaring wil ik het hebben.

Software begint bij de mensen die haar gebruiken

Wie een CMS opent, wil meestal werk afronden: een artikel publiceren, een catalogus bijwerken, een evenement organiseren. Ons datamodel moet op dat werk aansluiten. Een verplicht veld kan in de database volkomen logisch zijn en toch onmogelijk in te vullen als iemand pas een eerste opzet maakt. Vroeg of laat staat er ‘nog te bepalen’, en heeft de beperking slechtere data opgeleverd.

Dat is een productles die meteen architectuur wordt: onderscheid maken tussen een concept en publiceerbare inhoud, informatie op het juiste moment vragen, fouten begrijpelijk maken en herstel mogelijk houden.

Bij bedrijfssoftware zijn koper en gebruiker vaak verschillende mensen. Een werknemer kan jarenlang vastzitten aan een onhandige interface. Bij consumentenproducten, die makkelijker te verlaten zijn, kan datzelfde ongemak een klant kosten. Veel CMS’en zitten ertussenin: werkgereedschap voor mensen met heel verschillende vaardigheden, gewoonten en geduld. Een goede leerschool om structuur en gebruiksgemak te combineren.

In hedendaagse applicaties herken je die vertrouwdheid. Een CRM, een vastgoedbeheersysteem, een beheerpaneel: ik filter informatie, kies een weergave en doe iets. Query, weergave, actie. Een tabel, kalender en kanbanbord kunnen drie manieren zijn om met dezelfde data te werken.

Die grammatica heeft ook wortels in databases en bedrijfssoftware. CMS’en hebben haar lang toegepast voor mensen die er dagelijks mee moesten werken zonder te weten wat vreemde sleutels waren. Met AI kunnen we nu een weergave voor één taak genereren, misschien maar voor tien minuten. Daaronder moeten de betekenis van data en de regels om ze te wijzigen herkenbaar blijven.

Anatomie van een CMS

Neem Directus, omdat ik ermee werk en het van dichtbij kan bekijken. ‘Een database met API’s en een beheerpaneel’ is ongeveer zo nauwkeurig als een dier omschrijven als iets met huid en organen. Om te begrijpen wat we kopen, hergebruiken of met AI willen nabouwen, moeten we de verantwoordelijkheden uit elkaar halen.

Ik begin aan de buitenkant. De huid is de Data Studio: formulieren, weergaven en dashboards maken het systeem bruikbaar. Een veld in een formulier verbergen beschermt het echter niet op de server. Het skelet is het datamodel: SQL-tabellen en relaties, samen met de metadata waarmee Directus velden, interfaces en instellingen beschrijft. Wat ‘klant’, ‘project’ of ‘goedgekeurd’ betekent, moeten wij bepalen. Daarna openen we het konijn.

Het beslissende onderscheid ligt tussen wat Directus kan en de beslissingen die wij zelf moeten nemen. Het biedt collecties, relaties, rechten, versies en automatiseringen. Bepalen wie een uitgave mag goedkeuren, wanneer een concept publiceerbaar is of hoe dezelfde klant in twee systemen herkenbaar wordt, vereist een model van ons werk. Het product biedt middelen om dat uit te drukken; de juistheid van dat model blijft onze verantwoordelijkheid.

Volg een concrete wijziging: een redacteur verandert een productprijs. De Data Studio verzamelt de waarde; de API ontvangt het verzoek; diensten voeren het uit in de context van de gebruiker en diens ingestelde rechten. De database handhaaft eigen beperkingen. De geschiedenis bewaart de wijziging als dat is ingesteld. Een Flow kan een externe catalogus laten bijwerken. Dat zijn verschillende verantwoordelijkheden: reageert die laatste dienst niet, dan kunnen opgeslagen en elders getoonde prijs uiteenlopen. We hebben een herstelregel nodig en een manier om het te merken.

Grenzen tellen ook wanneer we het platform uitbreiden. De servicedocumentatie vraagt aandacht voor de autorisatiecontext, accountability: weglaten kan de dienst beheerdersrechten geven.³ En een verborgen veld in de Data Studio vervangt geen datapolicy.⁴ De waarde van het platform hangt ook af van hoe goed we zijn grenzen respecteren.

Buiten het dier liggen beheer en onderhoud: database en opslag, geheimen, geteste back-ups, monitoring, updates en compatibiliteit met clients. Een deel kunnen we uitbesteden aan een beheerde dienst. We moeten wel weten wie ervoor zorgt. Een schema migreren of een revisie herstellen lost een deel op en vormt geen volledig herstelplan.

Licentiekeuzes brengen eveneens de totale kosten in beeld. Directus gebruikt momenteel de MSCL, een source-available-licentie: de broncode is in te zien, gebruik hangt af van de toepasselijke voorwaarden.⁵ Wie een alternatief overweegt, moet de blijvende kosten meetellen van de verantwoordelijkheden die hij overneemt.

Gebruiksgemak, ook buiten de browser

Dezelfde zorg moet mensen bereiken die met code, scripts en automatisering werken. Developer experience, of DevEx, is een andere vorm van gebruiksgemak: heldere documentatie, expliciete typen, voorspelbare opdrachten, begrijpelijke fouten. Daarmee kun je nauwkeurig werken en handelingen herhalen met bekende verwachtingen.

In Directus krijgt die aandacht concrete vormen. De JavaScript- en TypeScript-SDK biedt een samenstelbare client voor API’s, authenticatie en realtime, met ondersteuning voor de typen van je eigen schema.⁶ De CLI voor omgevingssynchronisatie laat je schema en configuratie exporteren, verschillen bekijken en op compatibele instanties toepassen, ook in een pipeline.⁷ De MCP-server ontsluit via het Model Context Protocol data en bewerkingen voor AI-assistenten, met inachtneming van de rechten van de identiteit waarmee zij verbinden.⁸

Dat geeft mensen echte keuzevrijheid: het paneel gebruiken, een integratie schrijven, een opdracht uitvoeren of met hun eigen agent in hun eigen omgeving werken. Je kiest hoe je samenwerkt en vindt hetzelfde datamodel, met de autorisaties die elke bewerking vereist. AI komt zo terecht in een systeem dat al structuur en regels heeft.

Voor mij omvat ‘mooi en handig’ ook software die een mens kan orkestreren, ook via zijn eigen agent. Ik kan een proces samenstellen, stappen delegeren, resultaten controleren en ingrijpen. Automatisering wordt een manier om meer grip op het werk te krijgen. Zorgvuldige DevEx maakt dat vandaag al mogelijk.

‘Het is maar een fotogalerij’

Neem een gewoon verzoek: de hoofdafbeelding van een artikel moet een geordende galerij worden. We voegen wat versleepbare miniaturen aan het formulier toe. Klinkt als een rustige middag.

Het model gaat echter van één verwijzing naar een relatie met meerdere afbeeldingen en een volgorde. Bestaande artikelen moeten hun foto behouden. API’s en templates moeten de nieuwe structuur begrijpen. Rechten moeten redacteuren ook de relatie laten beheren, zonder onbedoelde bestandstoegang te geven. Ondertussen blijven de redacteuren werken.

We kunnen stapsgewijs werken: de relatie toevoegen, bestaande verwijzingen omzetten naar de eerste afbeelding van elke galerij, leesbewerkingen aanpassen en het oude veld uitfaseren. Tijdens de overgang moeten we ook nieuwe schrijfbewerkingen regelen: verandert iemand na de eerste migratie de oude afbeelding, dan moet dat in de galerij terechtkomen. Een compatibele release houdt rekening met wat tijdens de uitrol gebeurt.

Schema, data, bestanden en code moeten in elke fase van de verandering samenwerken. Ze mogen op verschillende momenten evolueren, zolang er een pad is dat ze compatibel houdt.

Daarom zijn een schema van ontwikkeling naar productie brengen en inhoud overzetten verschillende bewerkingen.⁹ Daarom kan teruggaan naar de code van gisteren een kapot systeem opleveren als de data intussen zijn veranderd. En daarom is alleen een databaseback-up soms onvoldoende: verwijst die naar verwijderde afbeeldingen, dan hebben we verwijzingen hersteld naar iets dat niet meer bestaat.

Van een galerij zijn we bij disaster recovery beland. We moeten weten welke bestanden te bewaren, welke codeversies de data kunnen openen en hoe integraties opnieuw kunnen starten zonder uitgevoerde acties te herhalen. Een verstuurde e-mail of externe handeling draait niet mee terug met de database.

Hier komt de werkplaats rond het CMS in beeld: infrastructuur, CI/CD-pipelines, observability en herstelproeven. Daarmee kun je in de juiste volgorde uitrollen, verkeerde rechten onderscheiden van een uitgevallen dienst en vaststellen hoeveel werk bij een incident verloren kan gaan. Dan zijn er de mensen: wie keurt de wijziging goed, wie grijpt in, wie weet waarom die vreemde regel bestaat?

Bij welance maken onze cloud en de processen eromheen deel uit van deze gezamenlijke ervaring. Wie complexe CMS’en heeft begeleid, brengt vaak een volledige manier van werken mee, veel minder zichtbaar dan een scherm.

AI kan ook helpen migraties, tests en herstelprocedures te schrijven. Ervaring helpt bepalen welke nodig zijn en of de tests echt aantonen wat ons interesseert. Het prototype laat zien dat iets kan werken; het vervolg bepaalt onder welke voorwaarden het blijft werken.

De C staat voor content

Tot nu toe ging het over artikelen en foto’s. Maar inhoud kan ook een eis, een pand, beschikbaarheid, een beslissing of de relatie tussen een project en een persoon zijn. Die openheid heeft me altijd aangetrokken in CMS’en.

Een voldoende flexibel systeem kan de basis zijn van vastgoedbeheer, een CRM of onderdelen van een ERP. Het biedt al een plek om entiteiten te beschrijven, te verbinden, toegang toe te kennen en interfaces te bouwen. Daar komt domeinkennis bij: een boeking moet overlap voorkomen, ook bij twee gelijktijdige verzoeken; een boekhoudkundige beslissing kent andere beperkingen dan een artikel.

Juist als ruimte voor die mogelijkheden interesseert het CMS me. Veel bedrijfssoftware structureert informatie en laat de juiste mensen ermee handelen. Met AI komt er een deelnemer bij die kan lezen, voorstellen en handelen. De kwaliteit van de structuur wordt nog belangrijker.

Wanneer geheugen operationeel wordt

Gedeeld geheugen wordt operationeel wanneer we data tot hun bron, beslissingen tot hun redenen en acties tot de regels die ze toestaan kunnen herleiden.

Kennis wordt rationeel voor zover we haar kunnen reconstrueren en verifiëren. Een vastgelegde transactie, een schatting en een modelconclusie moeten onderscheidbaar blijven. Rekenregels en verbindingen moeten inspecteerbaar zijn. Zo kunnen verschillende mensen met verschillende agents aan dezelfde feiten werken en interpretaties bespreken.

Hier zie ik een verband met de LLM Wiki die Andrej Karpathy voorstelde: een model leest bronnen en onderhoudt blijvende kennis met samenvattingen en verbindingen die met de tijd veranderen.¹¹ In een CMS kunnen we die kennis aan projecten, verantwoordelijkheden en statussen koppelen: welke eis is goedgekeurd, wie mag die veranderen, welke taak hangt ervan af?

Bronnen kunnen documenten, opnamen of foto’s zijn. Hulpmiddelen die ze interpreteren moeten de herkomst bewaren, zodat een mens de samenvatting kan controleren en corrigeren. Het model kan veranderen; data, beslissingen en relaties moeten kunnen blijven. Zo wordt het systeem deel van de intelligentie van het bedrijf.

Handelen vraagt precieze autorisatie. Een eis mogen lezen geeft niet automatisch het recht een project te wijzigen of iets naar een klant te sturen. Elke connector moet de gevraagde actie controleren en passende inloggegevens op de externe dienst gebruiken. MCP biedt een gezamenlijke manier om tools te verbinden; de koppeling tussen rechten in verschillende systemen moet worden ontworpen. Ook een samenvatting uit vertrouwelijke documenten moet die grenzen respecteren.¹²

Die ontwikkeling bedoel ik met een AI Management System, of AI MS: bedrijfssoftware waarin mensen en agents met hetzelfde operationele geheugen werken. Ieder kan op zijn eigen manier omgaan met het systeem, terwijl regels, verantwoordelijkheden en wijzigingsgeschiedenis verifieerbaar blijven. Het is een werknaam voor een richting die ik veelbelovend vind.

Het CMS zou juist het onderdeel kunnen zijn dat weg moet

Het sterkste bezwaar tegen mijn betoog is dat AI data en regels belangrijker kan maken, en het CMS dat ze samenbrengt minder noodzakelijk. De verantwoordelijkheden uit de anatomische plaat kunnen anders worden samengesteld. De beschreven vaardigheden horen bij software engineering. Dat ik ze met CMS’en leerde, bewijst niet dat een CMS nog altijd de beste keuze is.

Als gespecialiseerde tools goedkoper te bouwen worden, verandert het voordeel van aanpassen aan een algemeen platform. Een kleine applicatie rond het eigen werk kan beter passen dan een CMS vol extensies. SDK, CLI en MCP ondersteunen ook dat alternatief: ze maken producten toegankelijk en combineerbaar zonder ze noodzakelijk een centrale rol te geven.

Een gedeeld model heeft eveneens een prijs. Een project voor de werkplanner en een opdracht voor de facturering kunnen verschillende grenzen hebben. Domain-driven design behandelt juist die veelheid: modellen afbakenen en hun onderlinge relaties expliciet maken.¹³ Ze in één structuur dwingen kan kwetsbare vertalingen, verouderde kopieën en een punt creëren waar elke wijziging doorheen moet.

Een zinvol alternatief laat gezaghebbende systemen binnen hun eigen domein en verbindt ze via expliciete contracten. De agent coördineert; diensten handhaven hun eigen regels. Het CMS blijft waar redacteuren het nodig hebben of verdwijnt helemaal uit dat proces. Ik moet dat overwegen, ook om in de toekomst niet vooral het gereedschap te herkennen dat ik het beste ken.

Voor mij verdient een CMS die plek wanneer gedeelde relaties, rechten en redactionele processen een wezenlijk deel van het werk zijn. Als ik daarvoor elders betrouwbare regels moet dupliceren en voortdurend synchronisaties onderhouden, kan het voordeel verdwijnen. De concrete toets is het wegdenken: welke verantwoordelijkheden moet ik opnieuw bouwen, welke integraties vervallen en hoeveel moeilijker wordt een fout begrijpen of herstellen? De beste keuze vermindert het totale werk en behoudt de noodzakelijke garanties.

De tools die ik morgen zou willen gebruiken

Dit perspectief bepaalt welke tools me aantrekken. Bij Railway zijn diensten en omgevingen zichtbare delen van het project; dat spreekt me aan. Lovable begint bij de applicatie en biedt ook een beheerde backend met database, authenticatie en opslag.¹⁴ Het zijn verschillende manieren om een systeem toegankelijk te maken dat onder de oppervlakte afhankelijkheden blijft hebben.

Ik geef de voorkeur aan platforms die die afhankelijkheden begrijpelijk maken en helpen beheren. Ik zie bouwen via gesprekken als één mogelijkheid binnen een breder platform dat software na de eerste release blijft begeleiden.

Ik wil kunnen vragen ‘maak van deze afbeelding een galerij’ en zien welke data veranderen, hoe bestaande data worden behandeld, welke diensten meedoen en waar goedkeuring nodig is. Ook wil ik weten hoe we herstellen als iets fout gaat. Componenten op een canvas tekenen is een goed begin; de waarde zit in het beheren van de verandering die erdoorheen loopt.

Daaruit kan het volgende CMS ontstaan, of uit de verdere ontwikkeling van bestaande tools. Ik vind het belangrijk dat mensen hun interface en agent kunnen kiezen en op een gedeelde basis blijven werken. Het verschil zit in het begeleiden van een verandering vanaf de bedoeling van de aanvrager tot de gevolgen voor het systeem.

Lang leve het CMS

Ook in de CMS-wereld gebeurt veel werk op de automatische piloot: een thema installeren, plugins opstapelen en opleveren zonder te vragen hoe het systeem zich zal houden. Met CMS’en gewerkt hebben is op zichzelf geen teken van zorg of vakmanschap. Een lage instapdrempel kan zowel nieuwsgierigheid als gemakzucht aanmoedigen.

Als ik kijk naar wat we vandaag met AI bouwen, valt me vooral iets op dat altijd al duidelijk was: goede software is goede software. Je herkent haar aan hoe goed ze de mensen helpt die haar gebruiken en hoe ze zich door de tijd en bij veranderingen houdt. Namen, afkortingen en de technologie van het moment zeggen op zichzelf weinig.

Aan wie nu met AI eigen bedrijfssoftware bouwt, zou ik vier vragen meegeven, dezelfde die ik mezelf blijf stellen:

• Welke regels moeten waar blijven terwijl het systeem verandert?
• Wie mag handelen, met welke data en met welke gevolgen?
• Wat hebben we na een fout daadwerkelijk geprobeerd te herstellen?
• Wat weten de mensen die na ons komen?

CMS’en waren de omgeving waarin ik deze vragen leerde stellen. Wat ik leerde neem ik mee, ook wanneer het me helpt een andere architectuur te kiezen.

CMS is dead. Long live the CMS.