DrupalCon Rotterdam 2026
In mijn professionele leven (oh Breuls, wat klinken we weer pretentieus) ben ik al aardig wat steden af geweest voor tech-conferenties. Meestal was dat Amsterdam (ik kan de RAI inmiddels dromen, dankzij Dutch PHP Conference, AWS Summit en een paar andere evenementen, maar ook de Kromhouthal is inmiddels bekend terrein, dankzij React Summit en JSNation), maar ook Maastricht (CodeConnexx), Utrecht (Pfcongres), Antwerpen (eigenlijk Edegem) voor PHPBenelux of Londen voor muCon (een Microservices-conferentie) of een aantal MySQL-conferenties staan in mijn conferentie-geschiedenis. Altijd vereist het enige reistijd, en soms zelfs een vlucht (vroeger, toen ik nog naar London City Airport vloog).
Daarom was het deze week extra leuk om gewoon in mijn eigen Rotterdam te kunnen blijven om DrupalCon bij te wonen. Ook voor DrupalCon ben ik wel eens naar Amsterdam en zelfs naar Wenen geweest, maar dit rondreizende circus deed nu Rotterdam aan en ik kon voor het eerst gewoon lekker op de fiets, naar het World Trade Center.
Drupal is in gebruik bij Shift2 als het CMS achter alle websites die we leveren. Dat is al een jaar of acht het geval en het is in die tijd een krachtig, veelzijdig en vaak uitdagend platform geweest om mee te werken. We staan ook op het punt een nieuw, op Drupal gebaseerd CMS-platform te ontwikkelen en in dat licht is het extra interessant om op een event als DrupalCon te bekijken wat de actuele ontwikkelingen zijn en erover van gedachten te wisselen. Het nog redelijk nieuwe, maar steeds volwassener wordende Drupal Canvas maakt enthousiast; zowel de klanten aan wie wij de websites mogen leveren als de developers in ons website-team die de integraties bouwen zien de meerwaarde en natuurlijk is het ook gewoon leuk speelgoed. In ons team kijken we momenteel naar hoe de kennis die we in het huidige Next.js-websiteframework hebben opgedaan hier gebruikt kan worden; vooral de vraag of we React kunnen blijven gebruiken of 'terug' moeten naar Twig houdt ons heel erg bezig. De presentaties over Canvas laten zien dat het nog volop in beweging is en we vooral niet te vroeg conclusies moeten trekken. Blijf ontdekken!
Het zal niemand verbazen dat kunstmatige intelligentie vanuit verschillende perspectieven een terugkerend onderwerp is op conferenties zoals deze. De meeste developers (in mijn bubbel, althans) hebben de afgelopen tijd hun IDE vervangen of aangevuld met een coding agent, en de worstelingen die dat oplevert kwamen ook hier ter sprake. Maar Drupal zelf biedt ook steeds meer AI-mogelijkheden voor gebruikers, zowel aan de beheerskant (AI die je helpt met het maken van wijzigingen) als aan de bezoekerskant (bezoekers gebruiken hun AI-agents om informatie van een website te halen en te interpreteren). Waar "AI in Drupal" ruim een jaar geleden nog zoiets was als "genereer een alt-tekst bij deze afbeelding", gaat het nu meer richting "controleer of de pagina's op mijn website wel geschreven zijn volgens de tone of voice van onze organisatie" of "pas deze foutieve informatie aan op alle pagina's waar het voorkomt". Veel meer inhoudelijke automatisering van je werk in een CMS dus, en het is goed dat Drupal hier zo actief in doorontwikkelt. (Zouden ze dat niet doen, dan komt er natuurlijk gewoon een concurrent die het wél kan, maar toch, goed!)
De aandacht voor "AI voor developers" was eigenlijk volgens de lijnen van wat ik online en in gesprekken met andere developers ook regelmatig tegenkom: wat laat je door een LLM doen en wat doe je zelf? Waar trek je de grens en op basis van welke opvattingen doe je dat? Zo kun je op zich al je code laten schrijven door een chatbot, maar hoe ga je om met die code? Lees je elke regel code? Met welk doel doe je dat?
Zelf ben ik nog van de school die vindt dat als je code oplevert, ook al is die door een LLM geschreven, je moet staan achter wat je oplevert. Als een collega je benadert met een vraag over gemaakte keuzes, wil je die kunnen beantwoorden, en dan bedoel ik natuurlijk niet dat je die vraag moet doorspelen aan je LLM en het antwoord meat-proxyen naar je collega. Ik vind ook dat het reviewen van code, of het nu code van een LLM of van (de LLM van) een collega is, niet alleen dient om de code 'goed te keuren', maar ook om er kennis van te nemen; te weten wat er speelt in de ontwikkeling van de applicatie en te leren van gemaakte keuzes en toegepaste technieken. (Eén van de presentaties op DrupalCon leek dit vraagstuk te adresseren, maar bleek inhoudelijk weinig meer toe te voegen dan "blijf de code lezen, zorg dat je het begrijpt" en hoewel helemaal mee eens, dat is precies waar ik deze alinea mee begon.)
Maar het kan goed dat ik hier uiteindelijk, op termijn, in opschuif naar de opvatting dat als een LLM de code schrijft, en er is iets mis, dan kun je de LLM het ook wel weer laten oplossen. Dat is wat vibe coders ook doen en de grens tussen agentic coding en vibe coding wordt de komende tijd misschien steeds dunner. Dat opschuiven zal wellicht niet met een enorme snelheid gaan; in mijn dagelijkse werk zie ik wat een LLM goed doet en wat niet, waar ik nog moet bijsturen en waar niet, en gevoelsmatig duurt het nog even voordat je een chatbot kunt vertrouwen om het allemaal in z'n eentje te doen.
Maar tot we zo ver zijn kunnen we wel proberen om te proberen fouten te verminderen. Natuurlijk heb je daar rules en skills en hooks (de 'guardrails') voor, maar een interessante talk tijdens DrupalCon benadrukte het belang van good ol' Uncle Bob en zijn Clean Code. Een beetje developer kent dit boek of heeft het zelfs gelezen, en volgt een groot deel van de richtlijnen die eruit voortkomen. Het punt dat Len Swaneveld in zijn presentatie maakte is: blijf die richtlijnen volgen. Zelfs als jij of je organisatie helemaal zijn opgeschoven naar AI-coding, en je nog maar heel weinig code onder ogen krijgt, helpt het voorkomen dat een LLM fouten maakt (en fouten op fouten stapelt die je pas doorhebt nadat je vele wijzigingen verder bent) of te veel tokens verbrandt. Eigenlijk helpt clean code een agent gewoon exact zoals het een echte developer helpt: duidelijke code is een betere basis voor verdere ontwikkelingen. Moeten we junior developers nog wel iets leren, anno 2026? Jazeker, ze moeten Clean Code leren. En agents ook.
Het accepteren dat je werk door AI verandert, een transitie naar automatisering die eindelijk ook developers heeft bereikt (wij dachten altijd dat we veilig waren, want wij automatiseerden altijd andermans werk), is een proces dat per persoon verschilt. Een workshop hierover was ook onderdeel van de conferentie en dat geeft mij de komende tijd nog stof tot nadenken. Tech-conferenties die ook aandacht hebben voor 'soft skills' of de menselijke kant van de techniek voelen toch altijd als de meer complete conferenties, qua breedte van het aanbod.
DrupalCon is sowieso een breed gedragen conferentie. Al is het maar dankzij het grote aantal aanwezigen. Maar ook qua onderwerpen: developers, gebruikers, strategische beslissers; iedereen kan hier iets leren en geïnspireerd naar huis gaan.
En wat is het WTC (of het Postillion Convention Center) een leuke locatie, zeg! Ik kende het eigenlijk voornamelijk van de Sport Expo tijdens de Rotterdam Marathon, maar op die momenten kom ik er alleen voor het ophalen van een startnummer, waarna ik me verplicht door een fuik van een beursvloer moet worstelen omdat dat de enige weg naar buiten is. Niet bepaald bevordelijk voor een positieve houding ten aanzien van de locatie.
Volgend jaar is de Europese editie van DrupalCon in Edinburgh (van 25 t/m 28 oktober). Een mooi excuus om die Schotse stad eens te bezoeken!