Op 3 juni 2025 bezocht ik de Full Stack Conference in Utrecht: een dag vol inspiratie, kennisdeling en technische diepgang. Deze blogpost is geschreven voor een technisch publiek, maar iedereen is welkom om het te lezen. De conferentie bracht developers van allerlei disciplines samen – van frontend tot backend, van DevOps tot AI. In dit verslag neem ik je mee langs de sessies: een praktische blik op AI zonder de hype en een boeiende introductie in de wereld van observability met OpenTelemetry.

Of je nu zelf ontwikkelaar bent, of gewoon benieuwd naar wat er speelt in de wereld van moderne softwareontwikkeling – ik hoop dat dit verslag je nieuwe inzichten of ideeën geeft.

Jessy The – AI zonder de hype: hoe je AI wél goed inzet

Na de lunch kwam frontend developer “Jessy The” het podium op, met zichtbaar enthousiasme. Niet iemand die zomaar met de AI-hype meevaart, maar juist iemand die probeert te begrijpen wat AI echt voor developers betekent. “AI is geen magie,” begon ze. “Het is gewoon een tool – en met grote kracht komt grote verantwoordelijkheid.” (Ja, Spider-Man werd nog even aangehaald.)

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’s FLAN-T5.

Maar voordat ze begon met bouwen, stelde ze zichzelf en ons voor een hele belangrijke vraag:

“Moet mijn app eigenlijk wel AI gebruiken?”

Niet elk project heeft baat bij AI. Soms is een simpele regels-engine effectiever, goedkoper én betrouwbaarder. Ze gaf voorbeelden van waar AI waarde toevoegt:

• Bij complexe beslissingen waar geen vaste regels voor zijn
• Wanneer je UX kunt verbeteren door slimme suggesties
• Als er daadwerkelijk een probleem is dat AI kan oplossen

Daarna legde ze drie routes uit om AI toe te voegen aan je app:

1. Een kant-en-klare API gebruiken (zoals ChatGPT)
2. Een bestaand model finetunen
3. Een compleet eigen model trainen vanaf nul

Die laatste optie is alleen voor de echte avonturiers: duur, tijdrovend en risicovol. “Ze vergeleek het met een stagiair op een middelbare school, dat kost veel tijd om die op te leiden.”

Het AI-trainingsproces

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. “Je bouwt een soort curriculum. Je bepaalt wat belangrijk is, wat de juiste antwoorden zijn en je voert het de juiste voorbeelden.”

Ze besprak het trainingsproces in 8 stappen:

• Begrijp het model
• Definieer je taak
• Verzamel of bouw een dataset
• Bepaal het leerdoel
• Kies je model (grotere modellen zijn krachtiger, maar langzamer)
• Fine-tune met tools zoals Hugging Face en Google Colab
• Meet je training- en validatieverlies
• Test en evalueer

Ze waarschuwde voor gevaren zoals hallucinatie (AI verzint dingen), input/output mismatch en het fenomeen van catastrophic forgetting: als je een model té hard traint op nieuwe data, vergeet het ineens alles wat het eerder wist.

“Het 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.”

Tot slot sloot ze af met een warme oproep:

“Gebruik AI bewust. Niet omdat het hip is, maar omdat het echt iets toevoegt voor de gebruiker.”

Alexander Chatzizacharias & Riccardo Lippolis – Operational Excellence met OpenTelemetry

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.

Hun reis naar Operational Excellence begon uit frustratie. Ze wilden af van het reactieve brandjesblussen en toe naar inzicht, rust en controle.

Wat ze misten was observability – het vermogen om te zien wat er gebeurt. Niet alleen als iets fout gaat, maar ook waarom en waar in je systeem. Ze legden uit dat observability meer is dan monitoring. Het is een combinatie van:

• Logs – de details
• Metrics – de getallen
• Traces – de reis van een request

De OpenTelemetry-aanpak

Ze introduceerden OpenTelemetry (OTel) als dé 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:

• Grafana
• ELK Stack
• Jaeger

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:

• Hoe vaak iemand scoorde
• Waar de fouten zaten
• Wat er in de logs stond op dat moment

Traces lieten letterlijk zien welke microservice werd geraakt bij elk request – alsof je een soort detective bent in je eigen landschap.

“Outage? It’s a microservice murder mystery!”

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.

Waarom zou je dit doen?

“Omdat je landschap complexer wordt. De techstack wordt diverser. En je gebruikers verwachten stabiliteit.”

Met observability kun je:

• Proactief fouten opsporen
• Performance optimaliseren
• Debuggen zonder giswerk
• Jezelf en je team tijd besparen

Ze sloten af met een oproep:

“Operational Excellence is niet saai. Het is juist wat je nodig hebt om te groeien – en je gebruikers serieus te nemen.”

Bart Wullems – A Gentle Introduction into Property-Based Testing (Test Automation)

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 €43.000. Deze bug was te wijten aan het ontbreken van goede tests, wat hem ertoe bracht zijn testaanpak grondig te herzien.

Van example-based naar property-based testing

Bart legde het verschil uit tussen traditionele example-based testing (waarbij een paar voorbeeldwaarden getest worden) en property-based testing (waarbij eigenschappen van de functionaliteit worden getest met willekeurige data).

• Example-based: test input zoals add(1, 2) = 3.
• Property-based: test algemene eigenschappen, zoals commutativiteit: add(a, b) == add(b, a).

Wat is een “property”?

Een property is een regel of verwachting waaraan alle geldige input/output-combinaties moeten voldoen, zoals “de som van twee positieve getallen is altijd groter dan elk van de getallen afzonderlijk”.

Tools en voorbeelden

Bart demonstreerde tools zoals FsCheck, jqwik en Fast-check (JavaScript). Via generators worden automatisch invoerwaarden gegenereerd. Bij een fout wordt via shrinking het kleinste foutieve voorbeeld gezocht, wat debugging makkelijker maakt.

Praktische toepassingen

• Wiskundige eigenschappen: associativiteit, commutativiteit en idempotentie
• Business rules: domeinspecifieke eisen, zoals de uitkomst van een algoritme of sortering
• Edge cases: nulls, lege lijsten en negatieve getallen

Conclusie

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.

Jeroen Resoort – Running LLMs on Commodity Hardware: Private, Practical, and Powerful

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.

Waarom lokaal draaien?

• Geen dataverlies: alles draait op je eigen machine
• Geen logging of tracking
• Geen maandelijkse kosten
• Meer controle en aanpasbaarheid
• Mogelijkheid om ongefilterde modellen te gebruiken

Gebruikstoepassingen

• Tekstanalyse en parsing
• Code review en assistentie (bijv. in IntelliJ via DevoxxGenie)
• Afbeeldingengeneratie met tools zoals Stable Diffusion
• Spraakherkenning via Whisper

Modellen en performance

Er zijn veel modellen beschikbaar, o.a.:

• LLaMA 3.2
• Gemma
• Mistral en Mixtral (Mixture of Experts)
• CodeLlama voor codeertaken

Afwegingen zijn onder meer de grootte van het model (parameters), het geheugengebruik, tokens per seconde en de context window size.

Technieken voor optimalisatie

• Quantization: van 16-bit naar 8-bit om geheugen te besparen
• Mixture of Experts: modellen zoals Mixtral gebruiken gespecialiseerde submodellen voor snellere inferentie
• Preloading en keep-alive: om laadtijden te verminderen

Hardwareoverwegingen

• Minimaal: laptop met voldoende RAM (32–64GB)
• Optimale setup: Mac Studio, krachtige GPU of server
• Clusters: meerdere goedkope servers via RPC, maar niet per se sneller

Tot slot

Het draaien van LLM’s lokaal is mogelijk én 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.

Lightning Talks

Talk 1: Rasmus Renvall – Hidden Costs of “Ready-Made” Platforms

Rasmus Renvall deelde een herkenbaar patroon: de verleiding om kant-en-klare platformen zoals Dataiku te kopen – tools die “alles beloven”, maar in de praktijk toch onverwachte kosten en obstakels met zich meebrengen.

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!

Het patroon

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 “helpt” wel, maar lost het kernprobleem – communicatie en afstemming – niet op.

Reality check

• De lokale mappen zijn nu vervangen door cloud buckets, maar de fragmentatie blijft
• De maandelijkse factuur? Equivalent aan één of twee fulltime engineers
• Kennisdeling stokt. Silo’s ontstaan. De samenwerking die beloofd werd, is vooral afhankelijk van de mensen – en die zijn vaak te druk

Wat dan wel?

Rasmus’ oplossing is simpel, maar krachtig: breng mensen weer bij elkaar. Ga in gesprek, creëer gezamenlijke definities van data en processen en werk stapsgewijs aan échte samenwerking. Technologie is een hulpmiddel, geen magische oplossing.

Eerst de communicatie oplossen, dan pas de tooling. Fix the people, not just the platform.

Talk 2: Ramona Domen – We Need You: Accessibility on the Web

Ramona Domen hield een pleidooi voor digitale toegankelijkheid (a11y) en ze maakte meteen duidelijk: we hebben iedereen nodig.

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.

Waarom is digitale toegankelijkheid belangrijk?

• Kleurblindheid: 12% van de mannen
• Neurodivergentie: ca. 50% van developers (ADHD, autisme etc.)
• Leeftijd: iedereen wordt ouder, met visuele of motorische uitdagingen
• Tijdelijke beperkingen: gebroken arm, huilende baby, vertraagde vlucht etc.

Toegankelijkheid helpt iedereen. Denk aan ondertitels, duidelijke focus-indicatoren, schaalbare lettertypes en alternatieve teksten voor afbeeldingen.

Wat kun jij doen?

• Praat erover in je team
• Maak het bespreekbaar bij planning en design
• Gebruik de WCAG-checklist
• Hou het simpel

Toegankelijkheid is niet ingewikkeld, maar vraagt wél bewustzijn. En dat begint bij jou.

Talk 3: Edo Poll – What is a System Anyway? A Little Play

Edo Poll sloot af met een luchtige, maar scherpe mini-performance over systeemdenken. Zijn vraag: “Wat ís een systeem eigenlijk?”

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.

De kernboodschap: een systeem is meer dan code – het is ook gedrag, communicatie en interactie tussen onderdelen.

Hij gebruikte humor om duidelijk te maken dat systemen niet altijd rationeel of logisch gedragen – net als mensen. Een oplossing die “perfect” lijkt, kan totaal verkeerd uitpakken in een andere context, of als gebruikers onverwacht gedrag vertonen.

Zijn conclusie: systeemdenken vereist dat je uitzoomt. Kijk naar het grotere geheel. Vraag niet alleen: “Werkt mijn stukje?”, maar ook: “Wat gebeurt er als alle stukjes samenwerken?”

Sander Hoogendoorn – Seven Habits of a Highly Successful Team

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 – zeven om precies te zijn.

De realiteit van vandaag

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.

• Refactoring wordt uitgesteld (“de afwas stapelt zich op”)
• Veranderingen zijn onvermijdelijk – maar worden vaak niet omarmd
• De echte bottleneck zit niet bij de developers, maar in de structuur en besluitvorming

De zeven gewoontes van succesvolle teams

Sander deelde de zeven gewoontes die teams helpen om succesvol te zijn.

1. Prioriteer pragmatisch

Je kunt je tijd maar één keer uitgeven. Dus besteed die gericht:

• 70% innovatie
• 20% renovatie
• 10% bugs en onderhoud (“keep the lights on”)

Werk toe naar het gezamenlijke doel (“de stip op de horizon”). Gebruik een tech board om ideeën te toetsen: helpt dit ons écht vooruit? Is het klein genoeg? Is het urgent? Of moet het naar de “someday/maybe” backlog?

2. Continue vernieuwing in kleine stappen

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 – dus niet strak te plannen.

“Coddiwomple” – een woord voor doelgericht ronddwalen. Kleine stappen, feedback, aanpassingen.

3. Eigenaarschap op teamniveau

De kleinste eenheid van eigenaarschap is niet de developer, maar het team. En teams moeten autonomie hebben om keuzes te maken. Dáár ontstaat de magie.

Zelforganisatie is lastig, maar noodzakelijk. Je leert door te doen – en door te mogen falen.

4. Minder regels, meer vertrouwen

Inspiratie van Dee Hock (oprichter van Visa): hoe minder regels, hoe meer zelfregulatie. Sander gaf het voorbeeld van verkeersregels: minder verkeersborden → mensen gaan rustiger rijden, omdat ze elkaar aankijken. Vertrouwen en visuele communicatie in plaats van bureaucratie.

“Perfectie is niet wanneer er niets meer toe te voegen is, maar wanneer je niets meer kunt weglaten.” – Antoine de Saint-Exupéry

5. Microteams bouwen

Kleine en tijdelijke teams voor specifieke problemen:

1. Pick a problem
2. Form a team
3. Discuss a solution
4. Work
5. Report as done
6. Disband
7. Repeat

Snellere doorlooptijd. Minder afhankelijkheden. Flexibel en wendbaar.

6. Continu leveren

Van waterval naar trunk-based development. Geen pull requests en geen wachttijden. Lever meerdere keren per dag. Automatisering is cruciaal. “Code met vertrouwen.”

Sander haalde o.a. Jez Humble aan (Continuous Delivery): releases moeten zo klein zijn dat je “de bus kunt missen” en het geen ramp is.

7. Purpose, mastery & autonomy

Wat motiveert mensen écht? Niet regels of controle, maar:

• Purpose – zinvol werk doen
• Mastery – ergens beter in worden
• Autonomy – ruimte om te beslissen

Afsluiting

Sander sloot af met een dosis humor en levensfilosofie:

“Waarom zijn we eigenlijk nooit naar Italië gegaan?” vroeg zijn moeder aan hem

“Oude sleutels openen geen nieuwe deuren.”

Durf te veranderen. Blijf leren. En bovenal: heb plezier.

“If all else fails: rm -rf node_modules && npm install.”

Conclusie

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 – als dat beter past bij je use case of waarden.

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 écht werkt en waar je als team en gebruiker beter van wordt.