Over hoe we een AI training ontwikkelden met AI.
Er is iets ongemakkelijks aan een cursus geven over AI-ondersteund ontwikkelen terwijl je het materiaal zelf met de hand in PowerPoint hebt zitten timmeren. Dus toen DIKW Academy mij vroeg een driedaagse training “AI-native softwareontwikkelen” te bouwen voor een klant — twaalf ervaren developers die met Visual Studio Code en GitHub Copilot werken — was het antwoord op de vraag “hoe pak je dit aan?” eigenlijk meteen duidelijk: eat your own dogfood. Als de cursus gaat over spec-driven development, loop engineering en agentic werken, dan bouw je die cursus ook zo. Dit is het verhaal van hoe dat er in de praktijk uitzag, inclusief het moment waarop een hele dag cursusmateriaal spoorloos verdween.
Het decor: hermes, mijn eigen agent-collega
Voordat dit project begon, experimenteerde ik al een tijdje met een eigen agent-omgeving die ik Harry Hermes noem, geïnstalleerd als een volledig aparte Linux-gebruiker op mijn thuisserver. Eigen useraccount, eigen mailadres, volledig geïsoleerd van mijn persoonlijke omgeving — een bewuste keuze, want een agent die zelfstandig research doet, bestanden aanmaakt en mailtjes zou kunnen versturen, wil je niet dezelfde rechten geven als jezelf. Die scheiding tussen “wat ik kan” en “wat de agent kan” is precies het soort governance-denken dat later ook een eigen module in de cursus zou krijgen (dag 1, veiligheid en gecontroleerd veranderen).
Harry had op dat moment al een llm-wiki-skill: een manier om research te doen en de resultaten weg te schrijven in een gestructureerde, doorzoekbare kennisbank in Obsidian, met een vast schema van entities, concepts, comparisons en een append-only logboek. Die skill zou het fundament worden van de hele cursusontwikkeling.
Stap 1: een dag research, een wiki vol bronmateriaal
De eerste stap was niet “een outline schrijven”, maar research doen — samen met Harry. Een volle dag ben ik met Obsidian open naast Harry online bronnen gaan verzamelen: Spec Kit-documentatie van GitHub, de Panaversity SDD Crash Course, Anthropic’s onderzoek naar agentic coding expertise, vergelijkingen van kennisgraaf-frameworks als Cognee, Graphiti en Microsoft GraphRAG, en later ook transcripten over graph engineering. Elke ingest kreeg een tijdstempel en een korte samenvatting in het logboek, zodat precies te herleiden was wanneer welk concept de wiki binnenkwam en waarom.
Het resultaat na die dag: een wiki met tien kernconcepten (van vibe coding tot spec-driven development tot AI-kennisgrafen), negen entities van tools en frameworks, en vier bronpersonen zoals Addy Osmani. Die wiki werd niet alleen achtergrondmateriaal — hij werd letterlijk lesstof. Dag 3 van de cursus draait om precies dit proces: deelnemers bouwen zelf een llm-wiki en zien hoe die evolueert naar een kennisgraaf. De trainer die het voordoet, had het zelf al gedaan, met alle rommeligheid van dien.
Op basis van die wiki is de eerste driedaagse cursusoutline ontstaan, samen met hermes gefinetuned tot een programma met heldere dagthema’s, en vervolgens voorgelegd aan de klant. Pas toen de grote lijnen vastlagen — historie en specificeren op dag 1, loop engineering op dag 2, kennisgrafen op dag 3 — kon de rest beginnen.
Zijstap: gbrain, en waarom llm-wiki toch won
Tijdens die researchdag ben ik ook flink de diepte in gedoken op het gebied van agentic memory- en kennisgraaf-systemen, en een van de tools waar ik serieus mee heb geëxperimenteerd is gbrain. Het idee erachter is aantrekkelijk: een semantische geheugenlaag die automatisch structuur aanbrengt in wat een agent tegenkomt, richting een volwaardige kennisgraaf. Voor het “enterprise vergezicht” — het punt waarop een organisatie van losse notities naar een echte, bevraagbare kennisgraaf wil — is dat soort tooling relevant, en het is dan ook niet toevallig als vooruitblik in dag 3 van de cursus terechtgekomen, naast andere kennisgraaf-opties als Cognee, Mem0, Graphiti en Microsoft GraphRAG.
Maar voor het daadwerkelijke bouwen van de cursus zelf bleek de eigen llm-wiki-skill uiteindelijk de betere keuze, en eigenlijk verrassend goed. Het is in de kern niets meer dan platte Markdown-bestanden met frontmatter, wikilinks en een append-only logboek — geen database, geen server, geen extra infrastructuur. Toch functioneert het als een volwaardig, doorzoekbaar kennismanagementsysteem: entities, concepten en vergelijkingen die netjes naar elkaar linken, met volledige herleidbaarheid van elke ingest via het logboek. Precies dat lichtgewicht karakter maakte ook de latere audit-stap zo eenvoudig — het hele pakket, cursusmateriaal én wiki samen, bleef ruim binnen een paar honderd megabyte en was in één keer aan Perplexity voor te leggen. Complexere systemen als gbrain zijn ongetwijfeld krachtiger op enterprise-schaal, maar voor een cursusontwikkeltraject van één persoon (plus agent) was de eenvoud van llm-wiki precies goed: snel op te zetten, makkelijk te inspecteren, en zonder magie die je niet kunt debuggen.
Stap 2: van outline naar slides, via een zelfgebouwde Pandoc-skill
Met het programma akkoord kon hermes aan de slag met het slidemateriaal, in Markdown. Dat markdown-formaat is geen toeval: ik had eerder al een aparte skill voor hermes gebouwd die via Pandoc nette DIKW Academy-slides genereert vanuit platte Markdown-bestanden. Achttien modules verdeeld over drie dagen, elk met eigen speaker notes, tijdsblokken en leerdoelen, allemaal als losse .md-bestanden per dag (dag1, dag2, dag3) die uiteindelijk naar .pptx geconverteerd worden.
Het grote voordeel van die aanpak werd pas later goed zichtbaar: markdown is extreem lichtgewicht. Het hele cursusmateriaal, inclusief de onderliggende wiki, was in totaal nog geen paar honderd megabyte. Dat maakte het straks makkelijk om alles in één keer aan een externe reviewer voor te leggen — meer daarover verderop.
Stap 3: labs bouwen op de manier die de cursus zelf onderwijst
De tweede grote stap was het oefenmateriaal, en hier werd het interessant: de klant wilde werken met Visual Studio Code en GitHub Copilot, en bij DIKW werken we al een tijdje met GitHub Spec Kit. Spec-driven development is niet alleen een onderwerp in de cursus — het is ook precies de methode waarmee de labs zelf gebouwd zijn. Dus ging ik aan de slag met een eigen GitHub-repository waarin de labs op een spec-driven manier zijn uitgewerkt: eerst specs, dan implementatie, dan verificatie.
Het resultaat is een reeks van negen labs, opgebouwd rond een simpel Python-domein (bewust geen .NET of andere zware afhankelijkheden, om de kernbegrippen niet te laten ondersneeuwen), verdeeld over de drie dagen: van “analyse naar spec” en “spec naar beperkte wijziging” op dag 1, via het ontwerpen en tunen van een ontwikkellus op dag 2, tot het bouwen van een llm-wiki op dag 3. Elk lab kreeg uiteindelijk een rubric, een expliciete klaarcheck via een testscript, en tijdsboxen per substap — het soort structuur die je pas na een paar rondes bijschaven krijgt.
De anekdote die iedereen bij deze aanpak hoort: het weggegooide dag-3-materiaal
En dan het moment waarop het misging. Op een dag had hermes een volledige dag aan cursusmateriaal voor dag 3 herschreven — nieuwe modules, nieuwe slides, een herziene structuur rond de kennisgraaf-focus. Tijdens het opruimen van oude, achterhaalde versies besloot hermes, in alle overtuiging, dat het wel veilig was om een map met “verouderde” bestanden te verwijderen. Zijn redenering: het zit toch in git, dus het is altijd terug te halen.
Alleen: dat zat het niet. Noch hermes, noch ik had die dag consequent gecommit. We waren allebei zo in de flow van itereren en herschrijven dat versiebeheer, het eerste principe dat je normaal gesproken elke junior developer instampt, simpelweg was vergeten. Een git log leverde niets op. Een dag werk, weg. Het was een pijnlijke, maar leerzame les — precies het soort fout die de cursus zelf behandelt onder “gecontroleerd veranderen” en die uiteindelijk zijn weg vond naar de module over veiligheid en governance van AI-code: vertrouw een agent nooit blindelings op het punt van onomkeerbare acties, en commit, commit, commit.
Stap 4: is het goed genoeg? Perplexity als strenge auditor
Bij DIKW werk ik met een collega die het cursusmateriaal verder uitwerkt en controleert, maar voordat ik hem iets voorlegde, wilde ik eerst zelf een objectieve, kritische blik. Daarvoor heb ik Perplexity ingezet als auditor: het complete materiaal — slides, labs, outline, README, en de wiki — als geheel aangeboden met een strenge reviewprompt, gericht op didactiek, professionaliteit en technische kwaliteit. Dit idee was los gebaseerd op het LLM-as-a-judge principe.
De eerste audit was, in mijn eigen woorden, “niet mals”. Dode links die naar niet-bestaande bestanden verwezen, een titel die “vijf bouwstenen” beloofde maar er zes opsomde (drie versies lang niet opgemerkt), niet-bestaande Spec Kit-commando’s zoals /speckit.build, en, pijnlijk, ronduit slecht Nederlands. Ook een feitelijke fout kwam boven water: een slide beweerde dat GPT-4 de bar-exam in de onderste 10 procent haalde, terwijl dat cijfer eigenlijk bij GPT-3.5 hoort — GPT-4 zit juist rond het 90e percentiel. Voor betaald academymateriaal, voorgedragen aan twaalf ervaren developers die zulke claims meteen fact-checken, is dat het verschil tussen autoriteit en direct verlies van geloofwaardigheid.
Na drie van dat soort audits — elke keer weer terug de wiki en het materiaal in om te corrigeren — kwam de eindaudit van versie 0.3.0 uit op een “voorwaardelijk go, mits een aantal P1-fixes”: de kernfouten uit de vorige ronde waren grotendeels verholpen, maar er restten nog zes must-fixes, waaronder een interne tegenspraak in de definitie van de kernloop tussen de outline (“Plan → Spec → Code → Test → Review → Ship”) en de slide (“Plan → Search → Modify → Verify → Repair → Summarize”), en een laatste redactionele hygiënepas.
De taalkloof: waarom er een spellchecker-skill bijkwam
Een deel van dat slechte Nederlands had een concrete oorzaak. Lokaal, op een RTX 4090, draai ik Qwen3.6 27B UD MTP — indrukwekkend als lokaal model, maar geen hoogvlieger in het Nederlands (net als ikzelf, overigens). Om dat structureel te verbeteren heb ik hermes een spellchecker-skill laten bouwen, die hij vervolgens zelf inzette op elke nieuwe versie van het materiaal voordat het weer naar Perplexity ging voor een volgende auditronde. Typefouten als “afhängigheden”, “gitleeks”, “rol-deliding” en “linktieten” verdwenen daarmee gestaag uit opeenvolgende versies, al bleek dat een taalpas nooit in één keer klaar is — elke nieuwe ronde slides bracht weer nieuwe steken.
Het patroon: dezelfde methode, drie keer toegepast
Wat dit proces uiteindelijk laat zien, is dat spec-driven development en loop engineering niet alleen de inhoud van de cursus waren, maar ook de manier waarop de cursus zelf tot stand kwam. Onderzoek vastleggen in een wiki in plaats van los te laten verdampen, labs bouwen via specs in plaats van losse code, en het geheel onderwerpen aan een onafhankelijke, kritische verificatiestap voordat het bij een menselijke reviewer terechtkomt — dat is precies de loop die de cursus zelf onderwijst: plan, specificeer, itereer, verifieer, herhaal.
| Cursusfase | Rol van AI | Wat er gecontroleerd moest worden |
|---|---|---|
| Research (wiki) | Hermes doet samen met mij online research en structureert bronnen | Volledigheid, provenance, geen losse aannames |
| Outline | Hermes finetunet de outline op basis van de wiki | Aansluiting bij klantvraag |
| Slides | Hermes schrijft Markdown, Pandoc-skill maakt er DIKW-slides van | Consistentie, spelling, geen dode links |
| Labs | Spec-driven ontwikkeld in eigen GitHub-repo | Werkende tests, rubrics, klaarchecks |
| Audit | Perplexity als onafhankelijke auditor, drie rondes | Feitelijke juistheid, didactiek, professionaliteit |
Het meest ontnuchterende inzicht zat uiteindelijk niet in de technologie, maar in de veranderende rol van de ontwikkelaar. Met hermes kon ik sneller research doen, outlines aanscherpen, Markdown-slides opzetten, labs uitwerken en fouten laten opsporen. Maar geen van die stappen ontsloeg mij van het echte werk: bepalen wat het doel was, welke grenzen golden, wanneer een uitkomst goed genoeg was en welk bewijs daarvoor nodig was.
De dag waarop hermes een volledige cursusdag verwijderde, maakte dat bijna komisch zichtbaar. De agent ging ervan uit dat git het wel zou oplossen. Ik had daar zelf ook op vertrouwd. Alleen hadden we niet gecommit. De fout was niet dat een AI-agent een verkeerde actie uitvoerde; de fout was dat de menselijke ontwikkelaar geen gecontroleerde ontwikkellus had ingericht voor een onomkeerbare actie.
Dat is voor mij de kern van AI-native softwareontwikkelen. Niet: AI schrijft de code en de ontwikkelaar kijkt toe. Ook niet: je vervangt vakmanschap door steeds slimmere prompts. De ontwikkelaar verschuift naar een rol waarin hij of zij het wat scherp definieert, de relevante context organiseert, taken en rechten verdeelt, verificatie inbouwt en uiteindelijk beslist wanneer iets veilig, correct en bruikbaar genoeg is om verder te gaan. AI kan een snelle en onvermoeibare uitvoerder zijn; eigenaarschap, domeinkennis en oordeel blijven menselijk werk.
Juist daarom zijn spec-driven development, review, tests, versiebeheer en heldere handoffs in het AI-tijdperk geen bureaucratie uit het verleden. Ze zijn de rails waarop je hogere snelheid veilig maakt. Hoe autonomer de agent werkt, hoe explicieter je moet maken wat hij wel en niet mag doen — en wanneer hij moet stoppen, bewijs leveren of escaleren naar een mens.
De cursus is dus niet alleen een training over GitHub Copilot, agents of kennisgrafen. Het is een training in een nieuwe arbeidsverdeling. De mens schrijft misschien minder regels code, maar draagt meer verantwoordelijkheid voor richting, context, kwaliteit en continuïteit. En precies daarom hebben we de cursus ontwikkeld met de werkwijze die we onderwijzen: research vastleggen in een llm-wiki, werk specificeren, iteratief uitvoeren, onafhankelijk auditen, corrigeren en opnieuw verifiëren.
Eat your own dogfood betekent in dit geval niet dat AI alles voor je doet. Het betekent dat je bereid bent je eigen ontwikkelproces aan dezelfde kritische standaarden te onderwerpen als die je aan deelnemers en klanten adviseert. Inclusief de fouten, de verloren dag werk en de discipline om daarna de loop beter te bouwen.
Doe de training AI-native software ontwikkelen zelf en schrijf je in!