Nieuws van aanbieders

Ik ben geen developer en bouwde toch een Moodle-plugin

Kun je AI een Moodle-plugin laten bouwen en de uitkomst vertrouwen? Ik probeerde het met een echte klantvraag zonder zelf te kunnen programmeren. In een week had ik een werkende plugin. Niet alles ging in één keer goed. Wat ik leerde van dit experiment kan ik toepassen op elk Moodle-project waarin je AI laat meebouwen.

Het begon met een klantvraag die op het eerste gezicht klein was. Een non-profitorganisatie uit Nederland die haar Moodle-site bij Avetica laat draaien, vroeg om een security.txt op de site. Dat is een klein tekstbestand, vastgelegd in internetstandaard RFC 9116, waarin staat bij wie een beveiligingsonderzoeker terecht kan als hij een kwetsbaarheid vindt. Meer is het niet!. Wanneer beveiligingsscans worden uitgevoerd, via bijvoorbeeld internet.nl, wordt dit bestand vaak als ontbrekend aangemerkt en worden organisaties daar steeds vaker op aangesproken.

Als ondernemer probeer ik altijd te kijken wat wel kan. Ik ben didactisch geschoold als leraar basisonderwijs, ik ken Moodle, ik ken onze klanten en ik heb een stevige IT-achtergrond. Maar een Moodle-plugin schrijven kon ik niet want ik ben geen programmeur. Tot voor kort betekende dit dat zo’n vraag naar een ontwikkelaar ging of niet werd opgepakt.

Wat er veranderde

De belofte van vibecoden is verleidelijk: je beschrijft in gewone taal wat je wilt en AI schrijft de code. Maar ik zag ook iets anders en dat wil ik in dit verhaal vooral meegeven. De vraag is niet of AI een plugin kan schrijven want dat kan. De vraag is of je de uitkomst kunt vertrouwen: is de plugin veilig, en doet hij precies wat er in de specificatie staat?

Ons eigen proces als vertrekpunt

Daar kwam iets bij wat ik niet wilde weggooien: jarenlange ervaring. Bij Avetica werken we al jaren met een proces dat een idee omzet in een werkende Moodle-plugin. Eerst maken we helder wat het probleem is en voor wie. Dan leggen we de eisen, testscenario’s en wireframes vast. Na goedkeuring over inhoud en kosten begint het ontwikkelproces, inclusief codereview, diverse testronden en implementatie.

Met dit proces als fundament ging ik onderzoeken welke stappen AI kon overnemen. Tijdens de eerste experimenten bleek al snel dat de gegenereerde code lang niet altijd deed wat de bedoeling was. De AI maakte op basis van mijn prompts keuzes die technisch wel werkten, maar binnen Moodle niet pasten. Moodle hanteert immers een eigen codestijl en een rijk palet aan standaard API’s. Je wilt voorkomen dat AI zelf functies gaat bouwen die Moodle al kant-en-klaar aanbiedt: de code moet naadloos aansluiten bij wat er al is.

Daarnaast zijn AI-modellen getraind op informatie van maanden tot jaren oud. Er verschijnen continu nieuwe versies en er is voortdurend nieuw inzicht in wat goed werkt. Daarom scherpte ik de instructies aan met strakke kaders. De agent moest verplicht eerst actuele kennis ophalen voordat er ook maar één regel code werd geschreven. Ook Moodle-conventies en de OWASP Top 10 voor informatiebeveiliging legde ik vast als harde randvoorwaarden. Zo ontstond geleidelijk een reeks documenten, samen met mijn werkwijze (in AI-termen een skill), waaraan een AI-agent zich strikt moet houden. Telkens als ik nu iets nieuws leer of hoor, verfijn ik die procedure.

Security.txt als eerste echte experiment

De security.txt-vraag werd mijn eerste experiment met een echte klantvraag. Ik kende de wens van de klant en wist precies hoe een beheerder dit in Moodle zou moeten kunnen instellen. Dat beschreef ik in een prompt en ik vroeg de AI-agent om feedback. Via die dialoog werd de opdracht steeds scherper, totdat alle context en regels helder waren vastgelegd. Pas toen gaf ik de opdracht om de Moodle-plugin te bouwen en te testen.

AI heeft context en een harnas nodig

Ook AI heeft een doel, kaders en richtlijnen nodig. AI is intelligent, maar nog niet wijs. Bovenop de getrainde intelligentie moeten context en een harnas aanwezig zijn. Een harnas hoor ik je denken? Laat ik dit uitleggen. Ik zie een harnas als een bouwplaats. Een vakman kan nog zo goed zijn, maar hij begint pas als hij de bouwtekening heeft: wat wordt er gebouwd, voor wie, op welke grond en volgens welke maten. Dat is de context, alles wat AI moet weten voordat hij begint. Daarnaast gelden er op elke bouwplaats veiligheidsvoorschriften. Je draagt een helm, je werkt op hoogte met valbeveiliging en niets wordt in gebruik genomen voordat het is gekeurd. Dat is het harnas, in het Engels guardrails: regels waar AI niet onderuit kan. De tekening maakt de AI slimmer, het harnas maakt zijn werk veilig.

Voor de plugin kreeg de AI een bouwtekening met de klantvraag, de Moodle-versie en de volledige tekst van de standaard RFC 9116, zodat hij niet op zijn geheugen hoefde te vertrouwen. Mijn harnas bestond onder andere uit de coderichtlijnen van Moodle, de controle op rechten, de privacy-API en de OWASP-lijst met beveiligingsrisico’s. Daarbij kwamen een paar werkafspraken, zoals een test door een tweede AI-agent als keuring en een mens die meekijkt (human in the loop).

Een regel die klonk alsof hij klopte

Een van mijn eigen regels liet zien hoe verraderlijk een richtlijn is die logisch klinkt. In mijn harnas stond dat elk bestand van de plugin met dezelfde beveiligingscontrole moet beginnen. Het is een bekende Moodle-gewoonte en hij klonk veilig. Ik had hem zelf zo opgeschreven, dus de AI-agent deed precies wat ik vroeg en zette hem overal neer.

Daarna liet ik de code controleren met het gereedschap dat Moodle zelf gebruikt om codestijl te toetsen. Dat gaf negen meldingen: op negen plekken hoorde die controle er helemaal niet. Moodle vraagt die controle alleen in bestanden die direct iets uitvoeren, en niet in bestanden die slechts iets beschrijven. De fout zat dus niet bij de AI, maar bij mij. Ik had een regel die logisch klonk niet naast de bron gelegd.

Gelukkig gebeurde dit bij een kleine plugin en niet in een groot project. Ik paste de regel aan. Een paar dagen later bleek ook een kennisartikel van onszelf over Moodle-codestijl een paar fouten te bevatten, die ik alleen vond door het naast de officiële documentatie van Moodle te leggen. Sindsdien geldt: een regel in mijn harnas is pas goed als Moodle zelf het ermee eens is. De documentatie van Moodle is leidend, niet mijn prompt.

Ten slotte iets wat ik pas laat doorhad: een harnas is nooit af. Moodle verandert met elke release en zo ook de beveiligingsrisico’s. Daarom werk ik de skill elke maand bij. Dan laat ik een AI-agent controleren of de regels in mijn werkwijze nog kloppen met de nieuwste coderichtlijnen en beveiligingsmeldingen, en laat ik voorstellen wat er moet worden aangepast.

Wat het mij opleverde

Ik dacht dat ik alle specificaties vooraf goed had beschreven, maar bij het testen van de Moodle-plugin zag ik toch dat er dingen ontbraken. Ik paste de specificaties aan, gaf dat terug aan de AI-agent en een paar minuten later kon ik een nieuwe versie testen. Zo werd iteratief werken, met volop ruimte voor voortschrijdend inzicht, opeens heel makkelijk om direct toe te passen. Tussen de start van het project en de uiteindelijke oplevering van local_securitytxt zat slechts een week. Alle stappen kon ik zelfstandig doorlopen.

Voor de klant was het resultaat een veilige plugin op maat die ruim binnen budget bleef. Voor mij betekende het iets anders. Ik merkte dat ik niet de programmeur werd, maar de opdrachtgever en product owner die helder krijgt wat er moet gebeuren, wat de grenzen zijn en wie controleert. Dat blijkt precies het werk te zijn waar ik al jaren goed in ben.

Een leeromgeving op maat

Dat dit kan, heeft ook met Moodle zelf te maken. Moodle is open source en modulair opgebouwd. Bijna elk onderdeel is een plugin die je kunt toevoegen, vervangen of aanpassen, en er zijn vaste afspraken over hoe zo’n plugin in het systeem past. Daardoor kan een AI-agent heel gericht één onderdeel bouwen zonder de rest van het LMS aan te raken. Voor zover ik weet is er geen ander LMS waarin je zo eenvoudig functionaliteit kunt toevoegen. De plugin voor security.txt is daar een klein voorbeeld van.

Het betekent vooral dat organisaties weer de volledige regie over hun eigen leeromgeving terugkrijgen. Een leeromgeving op maat maken die precies aansluit bij hoe een organisatie leert en werkt, wordt zo veel toegankelijker en betaalbaarder. Wat vroeger een groot, kostbaar maatwerktraject was, kan nu een compacte en goed afgebakende toevoeging zijn.

Wij blijven onze kennis delen

Ik heb geleerd van anderen, mijn eigen ervaring toegevoegd en dat wil ik weer delen met andere Moodlelaars. Daarom staan zowel de code van de plugin als de hele werkwijze (de skill) op GitHub. Tevens ben ik bezig het publiceren van de plugin in de Moodle Marketplace. Op MoodleMoot Europe 2026 verzorg ik hierover een presentatie onder de titel “Own Your LMS: How to Get from Idea to New Functionality as a Non Coder“, waarin ik deze aanpak laat zien. De opgebouwde kennis wil ik daarnaast vaker inzetten bij onze klanten.

Heb je zelf een specifieke wens of een ontbrekende schakel in Moodle die je met een gerichte plugin wilt oplossen? Neem gerust contact op met Avetica, dan kijken we samen hoe we jouw idee veilig en werkend realiseren.

Het bericht Ik ben geen developer en bouwde toch een Moodle-plugin verscheen eerst op Avetica.

Lees het hele artikel