Jessy nam ons mee in haar eigen avontuur. Ze bouwde een app: een AI talk coachdie op basis van een LinkedIn-profiel advies geeft over passende sprekers of tech talks. Ze gebruikte Next.js voor de frontend en Flask (Python) voor de backend. De AI-functionaliteit? Die kwam van OpenAI en modellen van Hugging Face zoals Google\u2019s FLAN-T5.<\/p>\n
Maar voordat ze begon met bouwen, stelde ze zichzelf en ons voor een hele belangrijke vraag:<\/p>\n
\u201cMoet mijn app eigenlijk wel AI gebruiken?\u201d<\/p><\/blockquote>\n
Niet elk project heeft baat bij AI. Soms is een simpele regels-engine effectiever, goedkoper \u00e9n betrouwbaarder. Ze gaf voorbeelden van waar AI waarde toevoegt:<\/p>\n
\n
- Bij complexe beslissingen waar geen vaste regels voor zijn<\/li>\n
- Wanneer je UX kunt verbeteren door slimme suggesties<\/li>\n
- Als er daadwerkelijk een probleem is dat AI kan oplossen<\/li>\n<\/ul>\n
Daarna legde ze drie routes uit om AI toe te voegen aan je app:<\/p>\n
\n
- Een kant-en-klare API gebruiken (zoals ChatGPT)<\/li>\n
- Een bestaand model finetunen<\/li>\n
- Een compleet eigen model trainen vanaf nul<\/li>\n<\/ol>\n
Die laatste optie is alleen voor de echte avonturiers: duur, tijdrovend en risicovol. \u201cZe vergeleek het met een stagiair op een middelbare school, dat kost veel tijd om die op te leiden.\u201d<\/p>\n
Het AI-trainingsproces<\/h3>\n
Jessy ging vervolgens de diepte in over fine-tuning. Ze zag het als een leerproces waarbij jij de leraar bent en de AI de leerling. \u201cJe bouwt een soort curriculum. Je bepaalt wat belangrijk is, wat de juiste antwoorden zijn en je voert het de juiste voorbeelden.\u201d<\/p>\n
Ze besprak het trainingsproces in 8 stappen:<\/p>\n
\n
- Begrijp het model<\/li>\n
- Definieer je taak<\/li>\n
- Verzamel of bouw een dataset<\/li>\n
- Bepaal het leerdoel<\/li>\n
- Kies je model (grotere modellen zijn krachtiger, maar langzamer)<\/li>\n
- Fine-tune met tools zoals Hugging Face en Google Colab<\/li>\n
- Meet je training- en validatieverlies<\/li>\n
- Test en evalueer<\/li>\n<\/ul>\n
Ze waarschuwde voor gevaren zoals hallucinatie (AI verzint dingen), input\/output mismatch en het fenomeen van catastrophic forgetting: als je een model t\u00e9 hard traint op nieuwe data, vergeet het ineens alles wat het eerder wist.<\/p>\n
\u201cHet is net als leren met flashcards. Eerst begrijp je het niet, dan oefen je en op een gegeven moment snap je het. Maar je moet ook blijven checken of je nog weet wat je eerder hebt geleerd.\u201d<\/p><\/blockquote>\n
Tot slot sloot ze af met een warme oproep:<\/p>\n
\u201cGebruik AI bewust. Niet omdat het hip is, maar omdat het echt iets toevoegt voor de gebruiker.\u201d<\/p><\/blockquote>\n
Alexander Chatzizacharias & Riccardo Lippolis \u2013 Operational Excellence met OpenTelemetry<\/h2>\n
De volgende sessie begon met een bijna theatraal verhaal. Alexander en Riccardo, twee backend developers, vertelden hoe hun team ooit in de situatie zat dat niemand wist wat er in productie gebeurde. Als er iets kapot ging? Slack. Paniek. Debuggen met screenshots.<\/p>\n
Hun reis naar Operational Excellence begon uit frustratie. Ze wilden af van het reactieve brandjesblussen en toe naar inzicht, rust en controle.<\/p>\n
Wat ze misten was observability \u2013 het vermogen om te zien<\/em> wat er gebeurt. Niet alleen als iets fout gaat, maar ook waarom<\/em> en waar<\/em> in je systeem. Ze legden uit dat observability meer is dan monitoring. Het is een combinatie van:<\/p>\n
\n
- Logs \u2013 de details<\/li>\n
- Metrics \u2013 de getallen<\/li>\n
- Traces \u2013 de reis van een request<\/li>\n<\/ul>\n
De OpenTelemetry-aanpak<\/h3>\n
Ze introduceerden OpenTelemetry (OTel) als d\u00e9 manier om al deze data te verzamelen op een open, gestandaardiseerde manier. Geen vendor lock-in, geschikt voor elke techstack (Java, Go, Python, etc.) en met krachtige integraties zoals:<\/p>\n
\n
- Grafana<\/li>\n
- ELK Stack<\/li>\n
- Jaeger<\/li>\n<\/ul>\n
Ze demonstreerden dit met een kleine game die ze gebouwd hadden: een Flappy Bird clone. Elke klik van de speler werd getraceerd. Je kon in Grafana exact zien:<\/p>\n
\n
- Hoe vaak iemand scoorde<\/li>\n
- Waar de fouten zaten<\/li>\n
- Wat er in de logs stond op dat moment<\/li>\n<\/ul>\n
Traces lieten letterlijk zien welke microservice werd geraakt bij elk request \u2013 alsof je een soort detective bent in je eigen landschap.<\/p>\n
\u201cOutage? It\u2019s a microservice murder mystery!\u201d<\/p><\/blockquote>\n
Ze bespraken ook de rol van de OpenTelemetry Collector: een centrale plek die data verzamelt en doorstuurt naar visualisatietools. Belangrijk: je kunt zelf configureren welke data waarheen gaat, ideaal voor privacy en interne netwerken.<\/p>\n
Waarom zou je dit doen?<\/h3>\n
\u201cOmdat je landschap complexer wordt. De techstack wordt diverser. En je gebruikers verwachten stabiliteit.\u201d<\/p><\/blockquote>\n
Met observability kun je:<\/p>\n
\n
- Proactief fouten opsporen<\/li>\n
- Performance optimaliseren<\/li>\n
- Debuggen zonder giswerk<\/li>\n
- Jezelf en je team tijd besparen<\/li>\n<\/ul>\n
Ze sloten af met een oproep:<\/p>\n
\u201cOperational Excellence is niet saai. Het is juist wat je nodig hebt om te groeien \u2013 en je gebruikers serieus te nemen.\u201d<\/p><\/blockquote>\n
Bart Wullems – A Gentle Introduction into Property-Based Testing (Test Automation)<\/h2>\n
Bart Wullems, MVP bij Microsoft en lead architect bij de Vlaamse Landmaatschappij, gaf een toegankelijke introductie in property-based testing. Hij begon met een persoonlijk verhaal over een dure bug tijdens een project waarbij handmatig 400.000 brieven verstuurd werden via een complexe Windows-service. Na een fout gingen 10.000 brieven de deur uit met verkeerde informatie, wat leidde tot een schadepost van \u20ac43.000. Deze bug was te wijten aan het ontbreken van goede tests, wat hem ertoe bracht zijn testaanpak grondig te herzien.<\/p>\n
Van example-based naar property-based testing<\/h3>\n
Bart legde het verschil uit tussen traditionele example-based testing<\/em> (waarbij een paar voorbeeldwaarden getest worden) en property-based testing<\/em> (waarbij eigenschappen van de functionaliteit worden getest met willekeurige data).<\/p>\n
\n
- Example-based: test input zoals
add(1, 2) = 3<\/code>.<\/li>\n- Property-based: test algemene eigenschappen, zoals commutativiteit<\/em>:
add(a, b) == add(b, a)<\/code>.<\/li>\n<\/ul>\nWat is een \u201cproperty\u201d?<\/h3>\n
Een property is een regel of verwachting waaraan alle geldige input\/output-combinaties moeten voldoen, zoals \u201cde som van twee positieve getallen is altijd groter dan elk van de getallen afzonderlijk\u201d.<\/p>\n
Tools en voorbeelden<\/h3>\n
Bart demonstreerde tools zoals FsCheck, jqwik en Fast-check (JavaScript). Via generators<\/em> worden automatisch invoerwaarden gegenereerd. Bij een fout wordt via shrinking<\/em> het kleinste foutieve voorbeeld gezocht, wat debugging makkelijker maakt.<\/p>\n
Praktische toepassingen<\/h3>\n
\n
- Wiskundige eigenschappen: associativiteit, commutativiteit en idempotentie<\/li>\n
- Business rules: domeinspecifieke eisen, zoals de uitkomst van een algoritme of sortering<\/li>\n
- Edge cases: nulls, lege lijsten en negatieve getallen<\/li>\n<\/ul>\n
Conclusie<\/h3>\n
Property-based testing dwingt je om dieper na te denken over je vereisten. Het is geen vervanging van example-based tests, maar een waardevolle aanvulling die helpt om edge cases en algemene fouten eerder te ontdekken.<\/p>\n
Jeroen Resoort – Running LLMs on Commodity Hardware: Private, Practical, and Powerful<\/h2>\n
Jeroen Resoort gaf een praktische en toegankelijke sessie over het draaien van Large Language Models (LLMs) op betaalbare en lokale hardware. De focus lag op privacy, controle en betaalbaarheid, met tools als Ollama en Open Web UI.<\/p>\n
Waarom lokaal draaien?<\/h3>\n
\n
- Geen dataverlies: alles draait op je eigen machine<\/li>\n
- Geen logging of tracking<\/li>\n
- Geen maandelijkse kosten<\/li>\n
- Meer controle en aanpasbaarheid<\/li>\n
- Mogelijkheid om ongefilterde modellen te gebruiken<\/li>\n<\/ul>\n
Gebruikstoepassingen<\/h3>\n
\n
- Tekstanalyse en parsing<\/li>\n
- Code review en assistentie (bijv. in IntelliJ via DevoxxGenie)<\/li>\n
- Afbeeldingengeneratie met tools zoals Stable Diffusion<\/li>\n
- Spraakherkenning via Whisper<\/li>\n<\/ul>\n
Modellen en performance<\/h3>\n
Er zijn veel modellen beschikbaar, o.a.:<\/p>\n
\n
- LLaMA 3.2<\/li>\n
- Gemma<\/li>\n
- Mistral en Mixtral (Mixture of Experts)<\/li>\n
- CodeLlama voor codeertaken<\/li>\n<\/ul>\n
Afwegingen zijn onder meer de grootte van het model (parameters), het geheugengebruik, tokens per seconde en de context window size.<\/p>\n
Technieken voor optimalisatie<\/h3>\n
\n
- Quantization: van 16-bit naar 8-bit om geheugen te besparen<\/li>\n
- Mixture of Experts: modellen zoals Mixtral gebruiken gespecialiseerde submodellen voor snellere inferentie<\/li>\n
- Preloading en keep-alive: om laadtijden te verminderen<\/li>\n<\/ul>\n
Hardwareoverwegingen<\/h3>\n
\n
- Minimaal: laptop met voldoende RAM (32\u201364GB)<\/li>\n
- Optimale setup: Mac Studio, krachtige GPU of server<\/li>\n
- Clusters: meerdere goedkope servers via RPC, maar niet per se sneller<\/li>\n<\/ul>\n
Tot slot<\/h3>\n
Het draaien van LLM\u2019s lokaal is mogelijk \u00e9n praktisch. Het vereist wel enige hardwarekennis en een balans tussen performance, geheugen en use-case. Tools als Ollama en Open Web UI maken het toegankelijker dan ooit.<\/p>\n
Lightning Talks<\/h2>\n
Talk 1: Rasmus Renvall \u2013 Hidden Costs of “Ready-Made” Platforms<\/em><\/h2>\n
Rasmus Renvall deelde een herkenbaar patroon: de verleiding om kant-en-klare platformen zoals Dataiku te kopen \u2013 tools die \u201calles beloven\u201d, maar in de praktijk toch onverwachte kosten en obstakels met zich meebrengen.<\/p>\n
Rasmus kwam met voorbeeld uit het werk: het team demonstreerde een nieuwe AI-platformoplossing. De demo zag er indrukwekkend uit: realtime inzichten, automatisering en veelbelovende resultaten. Het leek zelfs de boilerplate-code te kunnen vervangen. Iedereen was enthousiast, de beslissing werd genomen: kopen die handel!<\/p>\n
Het patroon<\/h3>\n
In plaats van een gedeelde basis, gingen teams in de cloud allemaal aan de slag met hun eigen datasets en hun eigen interpretaties. Verschillende versies van data circuleren, wat leidt tot mismatchende uitkomsten. Bucket A heeft iets anders dan Bucket B. Samenwerking voelt ineens als een last: het platform \u201chelpt\u201d wel, maar lost het kernprobleem \u2013 communicatie en afstemming \u2013 niet op.<\/p>\n
Reality check<\/h3>\n
\n
- De lokale mappen zijn nu vervangen door cloud buckets, maar de fragmentatie blijft<\/li>\n
- De maandelijkse factuur? Equivalent aan \u00e9\u00e9n of twee fulltime engineers<\/li>\n
- Kennisdeling stokt. Silo\u2019s ontstaan. De samenwerking die beloofd werd, is vooral afhankelijk van de mensen \u2013 en die zijn vaak te druk<\/li>\n<\/ul>\n
Wat dan wel?<\/h3>\n
Rasmus’ oplossing is simpel, maar krachtig: breng mensen weer bij elkaar. Ga in gesprek, cre\u00eber gezamenlijke definities van data en processen en werk stapsgewijs aan \u00e9chte samenwerking. Technologie is een hulpmiddel, geen magische oplossing.<\/p>\n
Eerst de communicatie oplossen, dan pas de tooling. Fix the people, not just the platform.<\/p>\n
Talk 2: Ramona Domen \u2013 We Need You: Accessibility on the Web<\/em><\/h2>\n
Ramona Domen hield een pleidooi voor digitale toegankelijkheid (a11y) en ze maakte meteen duidelijk: we hebben iedereen nodig.<\/p>\n
Ze begon met een persoonlijk voorbeeld: de vroedvouwenschool in Heerlen waar haar kind was geboren, voor 100 jaar geleden was er bijvoorbeeld lift. Fysieke toegankelijkheid was er niet. Helaas geldt dat ook nog vaak voor het web.<\/p>\n
Waarom is digitale toegankelijkheid belangrijk?<\/h3>\n
\n
- Kleurblindheid: 12% van de mannen<\/li>\n
- Neurodivergentie: ca. 50% van developers (ADHD, autisme etc.)<\/li>\n
- Leeftijd: iedereen wordt ouder, met visuele of motorische uitdagingen<\/li>\n
- Tijdelijke beperkingen: gebroken arm, huilende baby, vertraagde vlucht etc.<\/li>\n<\/ul>\n
Toegankelijkheid helpt iedereen. Denk aan ondertitels, duidelijke focus-indicatoren, schaalbare lettertypes en alternatieve teksten voor afbeeldingen.<\/p>\n
Wat kun jij doen?<\/h3>\n
\n
- Praat erover in je team<\/li>\n
- Maak het bespreekbaar bij planning en design<\/li>\n
- Gebruik de WCAG-checklist<\/li>\n
- Hou het simpel<\/li>\n<\/ul>\n
Toegankelijkheid is niet ingewikkeld, maar vraagt w\u00e9l bewustzijn. En dat begint bij jou.<\/p>\n
Talk 3: Edo Poll \u2013 What is a System Anyway? A Little Play<\/em><\/h2>\n
Edo Poll sloot af met een luchtige, maar scherpe mini-performance over systeemdenken. Zijn vraag: \u201cWat \u00eds een systeem eigenlijk?\u201d<\/p>\n
Aan de hand van een sketch over een NS-fiets-parkeerapp en de bijbehorende backends, liet hij zien hoe makkelijk het is om race conditions, edge cases en onbedoelde interacties over het hoofd te zien als je alleen naar je eigen deel kijkt.<\/p>\n
De kernboodschap: een systeem is meer dan code \u2013 het is ook gedrag, communicatie en interactie tussen onderdelen.<\/p>\n
Hij gebruikte humor om duidelijk te maken dat systemen niet altijd rationeel of logisch gedragen \u2013 net als mensen. Een oplossing die \u201cperfect\u201d lijkt, kan totaal verkeerd uitpakken in een andere context, of als gebruikers onverwacht gedrag vertonen.<\/p>\n
Zijn conclusie: systeemdenken vereist dat je uitzoomt. Kijk naar het grotere geheel. Vraag niet alleen: \u201cWerkt mijn stukje?\u201d, maar ook: \u201cWat gebeurt er als alle stukjes samenwerken?\u201d<\/p>\n
Sander Hoogendoorn \u2013 Seven Habits of a Highly Successful Team<\/h2>\n
Sander Hoogendoorn sloot de dag af met een energieke en inspirerende keynote over teamwerk in softwareontwikkeling. De centrale boodschap: software development is een teamsport. En succesvolle teams? Die hebben gewoontes \u2013 zeven om precies te zijn.<\/p>\n
De realiteit van vandaag<\/h3>\n
Veel teams kampen met technische schuld, complexe platformlandschappen en verstikkende afhankelijkheden. Wat is het echte probleem? Niet alleen de monolith, maar vooral: de organisatie en cultuur eromheen.<\/p>\n
\n
- Refactoring wordt uitgesteld (\u201cde afwas stapelt zich op\u201d)<\/li>\n
- Veranderingen zijn onvermijdelijk \u2013 maar worden vaak niet omarmd<\/li>\n
- De echte bottleneck zit niet bij de developers, maar in de structuur en besluitvorming<\/li>\n<\/ul>\n
De zeven gewoontes van succesvolle teams<\/h3>\n
Sander deelde de zeven gewoontes die teams helpen om succesvol te zijn.<\/p>\n
1. Prioriteer pragmatisch<\/h3>\n
Je kunt je tijd maar \u00e9\u00e9n keer uitgeven. Dus besteed die gericht:<\/p>\n
\n
- 70% innovatie<\/li>\n
- 20% renovatie<\/li>\n
- 10% bugs en onderhoud (“keep the lights on”)<\/li>\n<\/ul>\n
Werk toe naar het gezamenlijke doel (\u201cde stip op de horizon\u201d). Gebruik een tech board om idee\u00ebn te toetsen: helpt dit ons \u00e9cht vooruit? Is het klein genoeg? Is het urgent? Of moet het naar de \u201csomeday\/maybe\u201d backlog?<\/p>\n
2. Continue vernieuwing in kleine stappen<\/h3>\n
De winkel moet open blijven terwijl je verbouwt. Denk klein. Experimenteer. Falen hoort erbij. Sander verwees o.a. naar de Cynefin framework: softwareontwikkeling is vaak complex of zelfs chaotisch \u2013 dus niet strak te plannen.<\/p>\n
\u201cCoddiwomple\u201d \u2013 een woord voor doelgericht ronddwalen. Kleine stappen, feedback, aanpassingen.<\/p>\n
3. Eigenaarschap op teamniveau<\/h3>\n
De kleinste eenheid van eigenaarschap is niet de developer, maar het team. En teams moeten autonomie hebben om keuzes te maken. D\u00e1\u00e1r ontstaat de magie.<\/p>\n
Zelforganisatie is lastig, maar noodzakelijk. Je leert door te doen \u2013 en door te mogen falen.<\/p>\n
4. Minder regels, meer vertrouwen<\/h3>\n
Inspiratie van Dee Hock (oprichter van Visa): hoe minder regels, hoe meer zelfregulatie. Sander gaf het voorbeeld van verkeersregels: minder verkeersborden \u2192 mensen gaan rustiger rijden, omdat ze elkaar aankijken. Vertrouwen en visuele communicatie in plaats van bureaucratie.<\/p>\n
\u201cPerfectie is niet wanneer er niets meer toe te voegen is, maar wanneer je niets meer kunt weglaten.\u201d \u2013 Antoine de Saint-Exup\u00e9ry<\/p>\n
5. Microteams bouwen<\/h3>\n
Kleine en tijdelijke teams voor specifieke problemen:<\/p>\n
\n
- Pick a problem<\/li>\n
- Form a team<\/li>\n
- Discuss a solution<\/li>\n
- Work<\/li>\n
- Report as done<\/li>\n
- Disband<\/li>\n
- Repeat<\/li>\n<\/ol>\n
Snellere doorlooptijd. Minder afhankelijkheden. Flexibel en wendbaar.<\/p>\n
6. Continu leveren<\/h3>\n
Van waterval naar trunk-based development. Geen pull requests en geen wachttijden. Lever meerdere keren per dag. Automatisering is cruciaal. \u201cCode met vertrouwen.\u201d<\/p>\n
Sander haalde o.a. Jez Humble aan (Continuous Delivery): releases moeten zo klein zijn dat je \u201cde bus kunt missen\u201d en het geen ramp is.<\/p>\n
7. Purpose, mastery & autonomy<\/h3>\n
Wat motiveert mensen \u00e9cht? Niet regels of controle, maar:<\/p>\n
\n
- Purpose \u2013 zinvol werk doen<\/li>\n
- Mastery \u2013 ergens beter in worden<\/li>\n
- Autonomy \u2013 ruimte om te beslissen<\/li>\n<\/ul>\n
Afsluiting<\/h3>\n
Sander sloot af met een dosis humor en levensfilosofie:<\/p>\n
\n\u201cWaarom zijn we eigenlijk nooit naar Itali\u00eb gegaan?\u201d vroeg zijn moeder aan hem<\/p>\n
\u201cOude sleutels openen geen nieuwe deuren.\u201d<\/p>\n<\/blockquote>\n
Durf te veranderen. Blijf leren. En bovenal: heb plezier.<\/p>\n
\u201cIf all else fails:
rm -rf node_modules && npm install<\/code>.\u201d<\/p>\nConclusie<\/h2>\n
De Full Stack Conference 2025 bood een mix van inspiratie, technische diepgang en praktijkgerichte sessies. Wat alle sprekers gemeen hadden, was hun nadruk op bewust kiezen: gebruik AI niet omdat het hip is, maar omdat het iets wezenlijks toevoegt. Observeer je systemen niet oppervlakkig, maar met inzicht en context. Test niet alleen met voorbeelden, maar vanuit eigenschappen en intentie. Draai LLMs niet per se in de cloud, maar misschien wel gewoon lokaal \u2013 als dat beter past bij je use case of waarden.<\/p>\n
Of je nu frontend-, backend- of DevOps-engineer bent: deze dag herinnerde ons eraan dat moderne softwareontwikkeling niet alleen gaat over tools en stacks, maar over het maken van doordachte keuzes. Technologie inzetten waar het \u00e9cht werkt en waar je als team en gebruiker beter van wordt.<\/p>\n
![\"Full](\"https:\/\/media.qdraw.nl\/log\/full-stack-conference-2025\/1000\/20250603_113230_d_e_kl1k.jpg\")