Op Techorama 2025 werden inzichten gedeeld over actuele thema’s binnen de IT en softwareontwikkeling. Deze blog is
geschreven voor IT professionals. In dit blog bespreken we enkele hoogtepunten.

In deze blog geef ik een samenvatting van de verschillende sessies:

• The Past, Present, and Future of AI for Application Developers — Steve Sanderson
• Agents of Change: Building AI Agents that Work (and Think) for Us – Jeff Prosise
• Understanding Model Context Protocol (MCP) — Roelant Dieben
• VAR, AI Referees, and the Future of Code Reviews – Amber Vanderburg
• The Next Decade of Software Development – Richard Campbell
• Relate. Reflect. Respond. – Alice Meredith
• What’s new in C# 13, 14, and beyond – Bart de Smet
• Practical tips for keeping your C# code base clean – Dennis Doomen
• Debugging Like a Coach: Fixing Team Bugs Before They Crash the Game — Amber Vanderburg
• React: The Most Common State Mistakes in 2025 — Cory House
• Fortifying your Workflows: Battle-Tested Security Strategies for Hardening GitHub Actions – Josh Johanning
• Trusted. Respected. Heard. – Alice Meredith
• Lessons from the Fast Lane – Robert Doornbos

The Past, Present, and Future of AI for Application Developers — Steve Sanderson

Steve Sanderson begon zijn sessie met een simpele constatering: “AI makes work better.” En dat is nauwelijks overdreven. Twee jaar geleden gebruikte nog vrijwel niemand AI tijdens het ontwikkelen, nu ligt dat gebruik al rond de vijftig procent. De vraag is niet langer of we AI gaan gebruiken, maar hoe we ermee beginnen.
Om die vraag te beantwoorden, nam Steve het publiek mee op een reis door de tijd — terug naar het begin van het begrip “kunstmatige intelligentie”.

Van Turing tot Eliza

In 1950 stelde Alan Turing zijn beroemde vraag: “Can machines think?” Hij bedacht de zogenaamde imitation game, later bekend geworden als de Turingtest — een manier om te bepalen of een machine menselijk genoeg kan converseren.
In de jaren zestig ontstonden de eerste chatbots. Steve toonde live een klassieker: Eliza , een programma dat met simpele stringvervanging reageerde op wat je zei. Als je iets intypte, herhaalde Eliza het gewoon in de vorm van een vraag. Het werkte niet echt, maar het was een fascinerende illusie. Steve lachte: “People process it as intelligence — but it’s just string replacement.”

De fundamenten van voorspellende tekst

Daarna ging hij nog verder terug. In 1913 beschreef Andrey Markov de kans dat een volgende letter of woord afhangt van de vorige — de basis voor wat we nu Markov chains noemen.
En in 1948 legde Claude Shannon met zijn informatietheorie de basis voor moderne taalmodellen. Hij liet zien hoe je op basis van letterfrequenties een tekst kunt laten “gokken” wat erna komt.

“Pro tip,” grapte Steve. “Everything is legitimate for AI.”
En inderdaad: zelfs iets eenvoudigs als een letterrooster kan de kiem zijn van een taalmodel.

De doorbraak: Transformers

Pas in 2017 kwam de echte revolutie: de Transformer-architectuur. Die maakte het mogelijk om context op veel grotere schaal te begrijpen. Sindsdien is de groei van AI-modellen explosief.
Steve toonde een overzicht van bekende modellen — van GPT-1 met 117 miljoen parameters tot GPT-4 , waarvan naar schatting 1,7 biljoen parameters onder de motorkap zitten. Daar tegenover staan open modellen als LLaMA en DeepSeek R1 , die ook snel aan terrein winnen.

Hoe een taalmodel leert

Om te laten zien hoe AI leert, trainde Steve live een kleine versie van GPT-2.
Na één iteratie was de output pure chaos.
Na honderd iteraties begon het model taalpatronen te herkennen.
Na vijfhonderd iteraties produceerde het zinnen die grammaticaal klopten.

“It’s just predicting the next token,” zei Steve.
“Chat completion is simply token prediction shaped into something we want to hear.”

Function calling en echte intelligentie

Maar moderne AI gaat verder dan tekstvoorspelling. Met function calling kan een model nu echte methodes aanroepen of data uit de echte wereld ophalen.
Zo ontstaat een brug tussen tekstbegrip en praktische actie.
Hij liet zien hoe dat werkt in toepassingen als:

• Chat-interfaces
• RAG (Retrieval-Augmented Generation)
• Virtuele assistenten

C# in actie

Vervolgens stapte hij over naar de praktijk: AI integreren in .NET.
Met Microsoft.Extensions.AI en IChatClient demonstreerde hij hoe je een AI-model eenvoudig laat samenvatten, vertalen of classificeren.
Een voorbeeld met een vastgoedapplicatie liet zien hoe een AI automatisch eigenschappen uit een beschrijving kon extraheren en in JSON kon teruggeven.

Vision en reasoning

Steve liet ook multimodale toepassingen zien — modellen die niet alleen tekst, maar ook beelden begrijpen.
Met GPT-4o-mini en lokale modellen via Hugging Face (een site waar veel AI modellen op staan) demonstreerde hij beeldclassificatie, zelfs draaiend in WebAssembly.
Daarna ging het over reasoning models: AI die niet alleen voorspelt, maar nadenkt — patronen herkent, context begrijpt en keuzes maakt.
Hij liet praktische voorbeelden zien:

• Formulieren automatisch invullen op basis van clipboarddata
• Slimme autocomplete
• Semantische zoekfuncties
• Spraakinterfaces, zoals in een auto-advertentie met voice-input

Tot slot

Aan het einde van zijn sessie benadrukte Steve dat de toekomst van AI niet alleen draait om grotere modellen, maar om betere modellen — systemen die begrijpen wat ze doen.
AI wordt niet meer alleen een tool die code aanvult of tekst genereert, maar een integraal onderdeel van hoe we software bouwen. De lijn tussen mens en machine vervaagt en voor ontwikkelaars ligt daar niet een bedreiging, maar een kans: om slimmer, sneller en creatiever te bouwen dan ooit tevoren.

Agents of Change: Building AI Agents that Work (and Think) for Us – Jeff Prosise

Jeff Prosise stapte het podium op met een energieke glimlach en de belofte van “lots of demos.” Hij hield woord. Het volgende uur stond in het teken van een nieuwe golf binnen AI: autonome agents — systemen die niet alleen reageren, maar ook samenwerken, plannen en handelen.

“Think of them as microservices for AI,” zei Jeff.
“Each agent does one thing extraordinarily well. Together, they can solve problems far more complex than any single model could.”

Wat zijn AI-agents eigenlijk?

Een AI-agent is in de basis een wrapper rondom een LLM (Large Language Model). Maar in plaats van simpelweg tekst te genereren, krijgt de agent autonomie en tools om specifieke taken uit te voeren: data ophalen, bestanden doorzoeken, berekeningen uitvoeren of zelfs API’s aanroepen.
Jeff legde het uit als een soort bouwteam: jij levert de bouwstenen, AI zorgt voor de workflow en het framework biedt de infrastructuur voor communicatie tussen de agents.

Agentic frameworks: de bouwstenen van deze nieuwe golf

Hij liet vier populaire frameworks zien die deze manier van werken mogelijk maken:

• Agents SDK / AutoGen – Een open-source framework van Microsoft voor het coördineren van meerdere agents. Ondersteunt RAG (Retrieval-Augmented Generation), verschillende conversatiepatronen en werkt met Python en .NET.
• CrewAI – Een Python-framework waarin groepen (“crews”) van agents samenwerken. Rijke ondersteuning voor geheugen en toolgebruik.
• Agno – Een open-source, LLM-agnostisch framework dat toolgebruik, persistentie en RAG ondersteunt, met een ingebouwde playground om workflows te testen.
• OpenAI’s Agents SDK – Een meer Python-first benadering met ondersteuning voor geheugen, audio, tool use en web search.

De praktijk: agents die denken, plannen en samenwerken

Om te laten zien wat dat betekent, bouwde Jeff live een prototype.
Op het scherm verscheen een fictieve vacature voor een CEO. Een agent analyseerde cv’s, beoordeelde kandidaten en gaf scores tussen 1 en 10 — allemaal in natuurlijke taal.

“One agent reads the resumes, another compares them to the job description, a third composes the response,” legde hij uit.
“They pass information dynamically — one by one — like a team.”

De workflow verscheen als een soort chatinterface waarin agents met elkaar communiceerden. Jeff vroeg de AI zelfs om een rejection letter in the style of Dr. Seuss — en het werkte.

Hoe werkt dat technisch?

Achter de schermen gebeurt er veel.
LLM’s zijn stateless, dus een agent-framework moet zelf geheugen bijhouden. Jeff liet zien hoe dat werkt met een eenvoudige in-memory database of met SQLite of MongoDB.
Hij demonstreerde Agno, waarin agents eenvoudig worden gedefinieerd met een paar regels Python-code.
Een agent heeft:

• een instructieprompt,
• een session ID,
• en een streaming-output om tussentijdse resultaten te tonen.

Agno bevat ingebouwde tools voor o.a. samenvatten, rekenen, het ophalen van data (zoals via yfinance) en zelfs het genereren van afbeeldingen. Alles via function calling — waarbij de LLM een JSON-beschrijving van de gewenste functie opstelt, die vervolgens echt wordt uitgevoerd.

MCP – de nieuwe standaard voor agentcommunicatie

Daarna ging het over MCP (Model Context Protocol), een nieuwe standaard die LLM’s in staat stelt om functies en API’s te importeren alsof het lokale tools zijn.
Bedrijven zijn druk bezig hun diensten via MCP beschikbaar te maken — van PayPal tot Salesforce.
De voordelen:

• gestandaardiseerde communicatie tussen agents;
• eenvoudige authenticatie (OAuth, tokens environment variables);
• ondersteuning voor streaming via HTTP.

Agno heeft zijn eigen MCP-server en ondersteunt multi-agent orchestration met vector databases en deelbare context.

Multi-agent samenwerking in actie

Tot slot liet Jeff een indrukwekkende demo zien van meerdere agents die samenwerkten aan een data-analyse.
Een Database Agent haalde gegevens op, een Quant Agent verwerkte ze en een Visualization Agent genereerde de grafiek — alles binnen een teamstructuur, aangestuurd door een Team Lead Agent.
In Python definieerde hij een Team-klasse met een members-property. Door share_member_interactions=True te zetten, konden de agents onderling informatie delen. Het resultaat verscheen als een live gegenereerde plot op het scherm.

De toekomst van agentic AI

Jeff sloot af met een vooruitblik:
AI-agents zullen binnenkort samenwerken zoals menselijke teams dat doen — met rollen, taken en context. De ontwikkelaar definieert het speelveld, maar de agents bepalen de uitvoering.

“We’re entering the era of AI orchestration,” zei hij.
“Where you don’t just build models — you build teams.”

Understanding Model Context Protocol (MCP) — Roelant Dieben

De sessie begon rustig, met een simpele titel op het scherm: “Understanding MCP.” Maar al snel werd duidelijk dat dit niet zomaar een technische uitleg zou worden — dit was een kijkje in wat velen de nieuwe ruggengraat van AI-integratie noemen.

De opkomst van MCP

Roelant trapte af met een glimlach: “MCP is nog geen jaar oud, maar het zorgt nu al voor flink wat buzz.”
Zijn agenda was overzichtelijk:

1. Introductie
2. Wat is MCP en waarom de ophef
3. De fundamenten
4. Zelf een MCP-server bouwen
5. Belangrijkste inzichten

Hij grapte over de USB-analogie — “I hate this analogy, it had nine connectors” — maar gebruikte het toch om te illustreren wat MCP wil zijn: één universele standaard voor hoe taalmodellen met externe systemen praten.

Waarom MCP nodig is

LLM’s, legde Roelant uit, kennen jouw wereld niet. Ze hebben geen toegang tot je documenten, API’s of databases. Ze genereren tekst, maar zonder context weten ze niet wat relevant of actueel is.

“Context is everything to the model,” zei hij.
“Good context makes agents smarter — and safer.”

MCP (Model Context Protocol) is ontworpen om dat probleem op te lossen. Het combineert memory, state en access — zodat een model kan werken met externe informatie op een veilige, gestandaardiseerde manier.

Wat is MCP?

MCP werd geïntroduceerd in november 2024 en is een open-source standaard die sterk doet denken aan bestaande protocollen als REST, LSP (Language Server Protocol) en JSON-RPC. Het is flexibel, webgebaseerd en bedoeld om de interactie tussen LLM’s, applicaties en tools te standaardiseren.

Demo: MCP in actie

Tijdens de demo opende hij Visual Studio Code en liet hij zien hoe GitHub Copilot, via MCP, kon communiceren met externe services.
Hij vroeg: “Are there new papers on Hugging Face?” Copilot stuurde de vraag via een MCP server , die op zijn beurt de informatie ophaalde. Geen custom plugin meer nodig, geen API-sleutels overal verstopt — gewoon één gestandaardiseerde interface.

“Every LLM used to need its own interface,” zei Roelant. “MCP replaces all of that.”

Hij toonde een GitHub MCP registry , waar al honderden servers beschikbaar zijn — van Playwright tot Hugging Face.

Hoe MCP werkt

MCP draait om drie kerncomponenten:

• Tools – functies of API-calls die een model kan gebruiken.
• Resources – leesbare datasets, bestanden of endpoints.
• Prompts – vooraf gedefinieerde templates voor AI-interacties.

Een MCP client roept tools aan of vult prompts in, terwijl een MCP server die tools en bronnen beschikbaar stelt.
De communicatie verloopt via JSON-RPC , met endpoints zoals /tools/list en /tools/invoke.
Roelant liet met de MCP Explorer zien hoe je de beschikbare tools kunt inspecteren, tokens kunt toevoegen en direct met servers kunt praten.

Lokale vs. externe MCP communicatie

Hij onderscheidde twee typen verbindingen:

• STDIO – lokaal, bidirectioneel en met lage latency (bijvoorbeeld binnen je eigen machine of editor).
• Streamable HTTP – voor externe, netwerkgebaseerde communicatie met authenticatie en streaming-ondersteuning.

STDIO is snel en betrouwbaar voor lokale agents; HTTP is ideaal voor cloudgebaseerde of remote toepassingen.

Pokémon: een verrassende analogie

De eerste slide was al in Pokemon stijl.

“It will make sense later,” had hij aan het begin gezegd — en dat deed het.

Hij legde de analogie uit:

• Pokédex → MCP Registry
• Pokémon → MCP Servers
• Pokémon Skills → Tools
• Pokémon Cards → Resources
• Pokéball → Client
• Trainer → Host
• Battle → Task

Een speelse, maar effectieve manier om te laten zien hoe MCP een ecosysteem vormt waarin clients, servers en tools samenwerken.

Beveiliging en authenticatie

Omdat MCP toegang kan krijgen tot gevoelige data, is veiligheid cruciaal.
Het protocol gebruikt OAuth 2.1 en OpenID Connect , met nadruk op “least privilege” en tokenvalidatie.
Roelant legde uit dat OAuth 2.1 inmiddels veiliger en consistenter is dan zijn voorganger en dat Microsoft werkt aan Entra Agent ID als mogelijke uitbreiding voor agentic identity management.

“MCP is only as secure as you make it,” zei hij. “Keep it updated, and follow best practices.”

Zelf een MCP-server bouwen

Tot slot liet hij zien hoe eenvoudig het is om een eigen MCP-server te bouwen.
In Visual Studio voegde hij via NuGet het ModelContextProtocol-pakket toe.
Met slechts zes regels code registreerde hij een HTTP-client naar de PokéAPI — en maakte zo een simpele, werkende MCP-server met een eigen tool.

“Just HTTP,” benadrukte hij. “No magic.”

Key takeaways

• MCP maakt AI écht contextbewust.
• Het standaardiseert de manier waarop LLM’s tools, data en geheugen gebruiken.
• Het is open, uitbreidbaar en al breed geadopteerd.
• Beveiliging is geïntegreerd, maar blijft je eigen verantwoordelijkheid.
• Context engineering — het bewust ontwerpen van de informatie die je AI krijgt — wordt een nieuw specialisme.

VAR, AI Referees, and the Future of Code Reviews – Amber Vanderburg

Amber opent met een voetbalclip — een bal die nét over de doellijn gaat. De zaal reageert meteen: herkenning, frustratie, discussie. Ze glimlacht: “Outrage in football. What do we do in situations like this?”

Amber is voormalig sportcoach en nu actief in tech leadership. Ze neemt het publiek mee door de geschiedenis van technologie in de sport — en wat we daarvan kunnen leren als softwareontwikkelaars.

In 1731 verscheen de eerste stopwatch. Daarna kwam de elektronische klok, de ‘photo finish’ en automatische scorebepaling bij bowlen. In 1995 deed video-refereeing zijn intrede en in 2001 kwam AI de sport binnen via cricket — het beroemde Hawk-Eye systeem dat met zes tot tien camera’s de balbeweging volgt.

De technologie verbeterde de kijkervaring , maar bracht ook vragen over eerlijkheid en vertrouwen. Tennis volgde in 2006 met real call video assistance. In 2010 zagen we het bekende WK-moment tussen Engeland en Duitsland: een doelpunt dat niet werd toegekend. Twee jaar later voerde de FIFA doeltechnologie in en in 2018 werden videoreferees officieel gebruikt tijdens het WK. Volgens FIFA lag de nauwkeurigheid toen op 99,3%.

In 2022 kwam daar semi-automatische buitenspeltechnologie bij: twaalf camera’s, twintig datapunten per speler. Amber stelt de vraag: “Do we even need human referees anymore?”

Maar: zonder context is er geen vertrouwen. Het publiek accepteert een menselijke fout nog eerder dan een kil technisch besluit van een systeem.
Daarna maakt Amber de overstap naar software: de toekomst van code reviews.

Ze laat een reeks beelden zien van gebeurtenissen waar technologie “technisch correct” handelde, maar menselijk gezien faalde — van persoonlijke tragedies tot Dieselgate bij Volkswagen. Een “defeat device” liet auto’s anders presteren tijdens tests, waardoor ze voldeden aan regels, maar de werkelijkheid maskeerden.
De les: context en intentie doen ertoe.

Amber benadrukt dat goede code reviews — net als goede arbitrage — niet alleen gaan over correctheid , maar over kritisch denken , empathie en communicatie.
Ze zegt: “The questions you ask reveal your values.”

Ze illustreert dit met voorbeelden uit het onderwijs en uit het dagelijks leven.

Wie bij een auto-ongeluk eerst vraagt “hoe erg is de schade?” in plaats van “ben je oké?”, laat zien welke waarde prioriteit krijgt.
Hetzelfde geldt bij code reviews: de vragen die we stellen sturen het gedrag van een team.

Amber vertelt over haar ervaring in India, waar ze een voetbalacademie leidde. De spelers waren taakgericht: ze wachtten op instructies en feedback, zonder het grotere spel te zien. Ze leerden een vaardigheid, maar misten context en creativiteit.
Na jaren training begreep ze dat haar taak niet was om hen nóg beter te laten uitvoeren, maar om hen te leren denken in systemen — de bigger picture te zien.
Tot slot maakt ze de sprong naar AI in coaching en code reviews.

AI kan ons helpen, maar zonder context mist het systeem menselijkheid. Ze toont beelden van vertrouwen en samenwerking en stelt de vraag:
“How are you building trust — with your team, your tools, your AI?”
Vertrouwen, zegt ze, bestaat uit competence, character en communication.
Je kunt iemand vertrouwen met een geheim, maar niet met je auto — omdat vertrouwen domeinspecifiek is.

Goede code reviews, net als goede scheidsrechters, vragen om datzelfde evenwicht tussen correctheid en context.
Het is niet genoeg dat iets werkt — het moet kloppen binnen de waarden van het team en de gebruikers.

Amber eindigt met een persoonlijke anekdote: een jonge speler die “pass!” riep, maar niet wist waarom. Pas toen ze samen de bedoeling achter de actie begrepen, ontstond er echt spelinzicht.
“Reviewing code,” zegt ze, “isn’t about shouting instructions — it’s about helping others see the field.”

The Next Decade of Software Development – Richard Campbell

Richard Campbell, bekend van DotNetRocks en RunAs Radio (samen goed voor bijna tweeduizend afleveringen), nam het publiek mee op een reis door de tijd — van de begindagen van de cloud tot aan de toekomst van softwareontwikkeling in het komend decennium.

Het einde van Moore’s Law

Richard dook vervolgens de geschiedenis van hardware in: van Fairchild Semiconductor in 1960 tot Intel’s vroege RAM-chips. Moore’s Law — de observatie dat het aantal transistors op een chip ongeveer elke twee jaar verdubbelt — heeft decennialang onze vooruitgang gedragen. Maar, zei hij: “We’re at the end of that curve.”
De afstanden tussen transistors worden nu gemeten in nanometers en zelfs picometers. Chips worden 3D en fabrikanten als Intel en TSMC werken aan 2nm-processors. Ondertussen komen ARM-processors op in de cloud, terwijl Apple’s M5-chips met 16 cores en neurale netwerken krachtige lokale AI-taken draaien.
Zijn punt: hardwareontwikkeling verandert niet alleen in tempo, maar ook in karakter.
De toekomst ligt in specialisatie — quantum, neuromorfisch, edge — in plaats van simpelweg sneller en kleiner.

De evolutie van software

Richard liet een lijst van talen en tools zien die developers de afgelopen decennia hebben gebruikt: Python, Java, C#, JavaScript, Swift, Go, Kotlin, Rust, TypeScript.
“None of them are perfect,” zei hij. “They’re just the current answers.”
Hij besprak de verschuiving van client naar cloud, van Windows naar Linux en van traditionele apps naar browsers en PWAs.
“.NET is 20 years old,” herinnerde hij het publiek, “and .NET 10 is around the corner.”
Er volgde een snelle tour door de wereld van low-code tools — Power BI, Power Apps, Power Automate, Power Virtual Agents — en de manier waarop ze traditionele ontwikkelcycli versnellen. Toch, benadrukte hij, blijft de kern hetzelfde: “Good software is still about solving real problems.”

AI: het slechtste goed bedachte woord

Richard noemde “AI” het slechtste marketingwoord ooit.
Hij lachte: “If it doesn’t work, we call it AI. Once it works, we rename it.”
Hij verwees naar HAL 9000 uit 2001: A Space Odyssey, naar de angst voor machines die ons vervangen — en naar de ironie dat moderne AI vooral ons werk makkelijker maakt.
Hij beschreef de opkomst van OpenAI, Google Brain, de ruzies over financiering en de samenwerking tussen Microsoft en OpenAI die leidde tot ChatGPT en GitHub Copilot.
Toch waarschuwde hij: “Copilot is your copilot — but if the plane crashes, it’s still your fault.”
AI kan code genereren, workflows versnellen en documentatie doorspitten, maar het neemt geen verantwoordelijkheid over.

Technologiehypes en wat blijft

Op het scherm verscheen de Gartner Hype Cycle. Richard vergeleek de huidige AI-golf met de dotcom-bubbel van de jaren negentig.
Toen ook kwam er een stortvloed aan investeringen en hoewel veel bedrijven verdwenen, bleef de infrastructuur: de netwerken, servers, browsers en standaarden waarop het internet vandaag nog steeds draait.
“Bubbles come and go,” zei hij, “but the foundations remain.”
Hij noemde zeven grote bedrijven die nu de wereld van AI en cloud domineren en sprak over de groeiende energiebehoefte van datacenters, de verschuiving van banen en het ontstaan van nieuwe rollen rondom AI-veiligheid, ethiek en auditing.

Verder dan generatieve AI

Richard ging daarna dieper in op generatieve AI buiten tekst en code. Hij noemde AlphaFold 3 — dat eiwitstructuren voorspelt — als voorbeeld van AI die wetenschappelijke vooruitgang versnelt.
Hij sprak over batterijen waarvan we nog niet precies begrijpen waarom ze werken, over landbouw waar sensoren en drones bemesting optimaliseren en over de manier waarop machine learning ons helpt zulke complexe systemen te modelleren.
Hij benadrukte dat innovatie niet altijd zichtbaar is. “Phones haven’t changed much,” zei hij, “but what happens behind the glass is revolutionary.”
Hij noemde Apple Vision Pro en Meta’s nieuwe brillen als stappen in de richting van “see-through computing” — maar gaf toe dat we de echte killer use-case voor kenniswerkers nog moeten vinden.

Quantum en de grenzen van kennis

Tot slot nam Richard het publiek mee naar de wereld van quantum computing.
Hij sprak over IBM’s Quantum Eagle, Microsoft’s Majorana-processor en de bizarre omstandigheden waarin deze machines functioneren — gekoeld met helium, zwevend in vacuüm, trillingsvrij tot op atomaire schaal.
Hij vergeleek de huidige fase van quantum computing met de begindagen van de transistor.
“Back then,” zei hij, “we didn’t even know what digital meant yet. Now we’re staring at the next revolution — and just like then, the unreliable will eventually make the reliable.”
Hij eindigde met een optimistische blik:

“We’re in the big time now. We get to make the future.”

Relate. Reflect. Respond. – Alice Meredith

Alice Meredith, met dertig jaar ervaring in leiderschap en verandermanagement, bracht in haar sessie een frisse, menselijke kijk op werk, communicatie en verandering. Haar carrière begon ooit bij Blockbuster Video , daarna werkte ze in HR-leiderschap bij Best Buy en ging daarna trainingen geven bij Pluralsight, waar ze inmiddels meer dan dertig leiderschapscursussen ontwikkelde. Haar missie: mensen helpen de menselijke kant van werk te beheersen — om niet alleen functioneel aanwezig te zijn, maar ook echt verbinding te maken, te reflecteren en bewust te reageren.

“Soft skills aren’t soft,” zei ze. “They’re the hard stuff that makes the hard skills matter.”

De menselijke kant van werk

Om effectiever te zijn in ons werk, moeten we eerst begrijpen hoe we zelf ‘geprogrammeerd’ zijn — ons menselijk besturingssysteem , zoals zij het noemde: een verzameling van levenservaringen, overtuigingen en automatische patronen die we soms zelf hebben gekozen, maar vaak gewoon hebben overgenomen.
We draaien allemaal met een eigen set ‘apps’: persoonlijkheidstypologieën zoals DISC, MBTI, Big Five enneagram en Gallup Strengths. Geen enkele is perfect, maar samen geven ze inzicht in onze kern.
Volgens Alice bestaat die kern uit vier fundamentele drijfveren:

• Macht (Power) – Ze hebben de wens om dingen te laten gebeuren.
• Loyaliteit (Loyalty) – Gedreven door loyaliteit, relaties en waarden.
• Plezier (Fun) Gedreven door plezier. Hebben veel energie.
• Vrede (Peace) – Creëren rust, stabiliteit en veiligheid.

Ze vergeleek onze sterke kanten met een huis met een balkon en een kelder:

“Op het balkon schitteren je kwaliteiten; in de kelder schieten ze door en worden ze je valkuil.”

Het doel is om jezelf in realtime te herkennen en terug naar het balkon te bewegen — naar balans.

Relate: de kracht van echt zien

In het deel Relate vertelde ze een verhaal over een 14-jarige jongen die ze ooit ontmoette aan het strand van Venice Beach. Hij deed stunts op zijn skateboard, terwijl dat daar eigenlijk niet mocht. Toen ze hem aankeek en simpelweg zei: “I see you”, veranderde zijn houding compleet.

“Being seen makes people feel they matter.”

In organisaties werkt het net zo. Mensen willen zich gezien en gehoord voelen. Kleine gebaren kunnen daar groot verschil in maken.
Ze gaf een voorbeeld van haar tijd bij Best Buy, waar ze een interne HR-e-mail herschreef die aanvankelijk formeel en afstandelijk was. In twintig seconden maakte ze de boodschap warmer, persoonlijker, menselijker — “You matter” in plaats van “You must.”

Reflect: het bouwen van verbindingen

Alice moedigde leiders aan om “connection bombs” te planten — spontane, menselijke interacties op de werkvloer die relaties versterken. Ze vertelde hoe ze ooit, tijdens een lunchwandeling, een toevallige ontmoeting had over een Journey-concert. Dat leidde tot een halfuur gesprek, nieuwe inzichten en een langdurige samenwerking.

“Every small conversation expands your network and builds trust.”

Verbinding ontstaat niet in vergaderingen of KPI’s, maar in de tussenruimte — de momenten waarin mensen zichzelf mogen zijn.

Respond: omgaan met conflicten en verandering

Het derde onderdeel draaide om responsiviteit — hoe we reageren in situaties van spanning of feedback.
Alice haalde het Thomas-Kilmann-conflictmodel aan, met vijf stijlen:

• Competing (win-verlies)
• Avoiding (verlies-verlies)
• Accommodating (verlies-winst)
• Compromising (klein win-klein verlies)
• Collaborating (win-win)

Ze benadrukte dat conflictstijlen niet statisch zijn: we kunnen leren om flexibel te schakelen, afhankelijk van de context.

Rommelig einde

Zo eindigde de sessie zonder duidelijke conclusie met veel persoonlijke anektotes.

What’s new in C# 13, 14, and beyond – Bart de Smet

Bart de Smet, Principal Software Engineer bij Microsoft en bekend gezichten binnen de .NET-community, nam het publiek mee in een snelle maar diepgaande tour door de nieuwste features van C# 13 , de aankomende verbeteringen in C# 14 en zelfs een voorproefje van wat daarna nog in de pijplijn zit.
Zoals altijd deed hij dat met zijn kenmerkende combinatie van precisie, snelheid en diepgang.

Params reimagined

C# 13 breidt de bekende params-functionaliteit eindelijk uit. Waar params sinds de begintijd alleen arrays accepteerde, kunnen ze nu ook werken met andere collection types — denk aan IEnumerable<T>, IList<T>, ImmutableArray<T>, of zelfs custom types die IEnumerable implementeren.

Locking: eenvoudiger en veiliger

Een van de meest zichtbare verbeteringen is de nieuwe lock syntax. In plaats van expliciet te werken met Monitor.Enter en Monitor.Exit, introduceert C# 13 een veiligere, moderne variant

Escape sequences: een kleine maar fijne update

Console-API’s ondersteunen nu de Unicode escape \e (in plaats van het oude \x1B), wat code leesbaarder maakt bij het werken met ANSI-color output of terminal-besturing.

Kleine verbeteringen, groot gemak — “less hexadecimal guessing,” aldus Bart.

Ref en unsafe in iterators

Een meer geavanceerde toevoeging: iterators (yield return) kunnen nu werken met ref en unsafe contexten , zonder onnodige heap-allocaties.
Hierdoor worden iterators efficiënter bij performancekritische code, bijvoorbeeld bij Span<T>-operaties.
ref struct types blijven wel beperkt tot de stack — ze kunnen dus niet naar de heap of interfaces worden gecast — maar dankzij nieuwe compilerondersteuning kun je ze nu combineren met IDisposable via het allow ref structs-attribuut.

Partial members en de field keyword

C# 13 breidt partial classes verder uit met partial members — niet alleen methodes, maar ook indexers, properties en constructors kunnen nu als partial worden gedefinieerd. De nieuwe field keyword maakt het bovendien eenvoudiger om in properties expliciet naar het backing field te verwijzen: Een elegante oplossing voor wie vaak boilerplate in properties moest schrijven.

Overload resolution attributes

Een subtiele maar belangrijke verandering: C# 13 introduceert een nieuw [OverloadResolutionPriority] attribuut, waarmee library-ontwikkelaars de prioriteit van overloads kunnen sturen — zonder binary-breaking changes. Vooral nuttig bij API’s die ReadOnlySpan<T> ondersteunen.

C# 14 – de volgende stap

Extension members

De grootste verandering die eraan komt, zijn extension members — niet alleen methodes, maar ook properties, indexers en zelfs operators kunnen worden uitgebreid.
Dat betekent dat je bijvoorbeeld dit kunt doen:

extension StringExtensions on string
{
    int WordCount => this.Split(' ').Length;
}

De feature wordt nog verder uitgewerkt, maar de potentie is groot — zeker voor domeinspecifieke API’s.

User-defined compound assignment

C# 14 introduceert ook custom compound assignments zoals += of ++ in structs. Zo kun je zelf bepalen hoe samengestelde bewerkingen zich gedragen — een krachtig hulpmiddel voor bijvoorbeeld numerieke types of matrixklassen.

Null-conditional assignment

De welbekende ?. operator krijgt een zusje: de null-conditional assignment.
Waar je vroeger alleen kon lezen met ?., kun je nu ook veilig toewijzen:

person?.Address ??= new Address();

Beyond: de horizon van C

Tot slot gaf Bart een vooruitblik op toekomstige concepten — zoals unbound generic names, lambda-parameters met modifiers en verdere uitbreiding van partial members.
De focus blijft volgens hem op type safety, performance en expressiviteit — drie pijlers waar C# al twintig jaar om bekendstaat.

“We’re not done evolving,” sloot Bart af. “C# keeps growing with the developers who use it.”

Practical tips for keeping your C# code base clean – Dennis Doomen

Dennis Doomen — bekend van zijn Fluent Assertions-library en zijn expertise in clean architecture — deelde in deze sessie zijn meest beproefde adviezen voor het onderhouden van een gezonde, schaalbare en begrijpelijke C#-codebase.
Zijn boodschap was duidelijk: “Clean code isn’t about writing less code — it’s about writing code that everyone wants to work with.”

Keep it simple: fight unnecessary complexity

Hij begon met een observatie over hoe veel teams onnodig complexe architecturen creëren. Niet elke toepassing heeft microservices nodig, benadrukte hij:

“If you don’t need independent scaling, merge those microservices back into a modular monolith.”

Het is volgens hem beter om eerst te kijken waar je daadwerkelijk moet schalen — en pas daarna de architectuur daarop aan te passen. Microservices zijn een middel, geen doel.
De Gartner Hype Cycle kwam voorbij: technologieën worden vaak te vroeg geadopteerd. Dennis moedigde aan om pragmatisch te blijven — eenvoud boven hype.

Organiseer de codebase logisch

Een terugkerend thema: structuur.
De mapstructuur van je project moet de architectuur weerspiegelen, niet de technologie. Geen “Controllers”-, “Services”- en “Repositories”-mappen, maar verticale slices zoals Orders, Payments, Users.

“The folder structure should explain your architecture at a glance.”

Daarnaast: hou concrete implementaties intern (internal) en exposeer alleen interfaces waar nodig. Door conventie en tooling kun je afdwingen dat interne onderdelen niet per ongeluk publiek worden.

Gebruik tooling om consistent te blijven

Automatisering is essentieel om kwaliteit te bewaken. Dennis liet zien hoe EditorConfig , Prettier en .NET analyzers kunnen helpen bij consistente formatting en statische code-analyse.
Ook JetBrains Inspect, SonarQube en Roslyn analyzers noemde hij als hulpmiddelen om vroegtijdig problemen te detecteren.

“Let tools do the boring work so you can focus on design.”

Zelfs AI kan hierbij helpen — hij noemde Copilot en Sonnet als voorbeelden van assistenten die mee kunnen denken bij refactoring, zolang je hun output nog steeds als je eigen code beschouwt.

Document the why, not the how

Veel documentatie schiet tekort omdat ze uitlegt wat de code doet, niet waarom ze zo is opgebouwd.
Dennis pleitte voor korte, doelgerichte commentaren die context toevoegen:

“Explain the purpose, not the procedure.”

Gebruik beschrijvende titels en laat de code zelf het werk doen. Tools zoals GhostDoc kunnen helpen bij basisdocumentatie, maar het echte werk zit in de intentie.

Slimme commit- en branchstrategieën

Versiebeheer is volgens hem een onderschat onderdeel van clean code.
Kies één bekende branchstrategie — zoals GitHub Flow of GitFlow — en houd je eraan.
Belangrijker nog:

• Splits refactoring commits van functionele wijzigingen.
• Houd PR’s klein en gericht.
• Gebruik fix-up commits en interactive rebases om je geschiedenis schoon te houden.

“A clean commit history is a clean story of your code.”

Hij toonde voorbeelden in GitKraken hoe kleine, goed getitelde commits het reviewproces aanzienlijk verbeteren.

Reduce dependencies and coupling

Een schoon systeem is een los systeem.
Gebruik Central Package Management om versies te beheren en afhankelijkheden te minimaliseren.
Wanneer code herbruikbaar moet zijn, publiceer het als een NuGet-pakket in plaats van losse binaries.
Verder:

• Vermijd mocks of mocks door interfaces bewust te ontwerpen.
• Gebruik adapters om afhankelijkheden te isoleren.
• Overweeg een omgekeerde afhankelijkheidsrichting wanneer een module te veel weet van een ander.

“Every dependency is a liability — treat it like one.”

Dupliceer liever dan te vroeg te abstraheren

Een opvallend advies dat vaak tot discussie leidt:

“Duplicate before you abstract.”

Dennis legde uit dat je pas moet abstraheren wanneer je dezelfde code minstens drie keer nodig hebt.
Te vroege generieke oplossingen leiden tot onnodige complexiteit en onbegrijpelijke code.

“If it’s too complicated to reuse, maybe it’s not worth reusing.”

Hij verwees naar het principe van de “Rule of Three” en de YAGNI-filosofie (You Ain’t Gonna Need It).

Refactoring and scouting rule

Refactoring hoort een natuurlijke gewoonte te zijn, geen project op zich.
Kleine verbeteringen mogen continu gebeuren, mits goed afgescheiden in commits.
Dennis sloot af met het “Scouting Rule”-principe:

“Always leave the code cleaner than you found it.”

Samenvattend

De sessie was een praktische gids vol nuchtere adviezen:

• Gebruik minder patronen en meer gezond verstand.
• Automatiseer consistentie.
• Schoon commitgedrag is net zo belangrijk als schone code.
• En abstraheer pas als het écht nodig is.

Of zoals Dennis het zelf zei:

“Clean code isn’t a style — it’s a culture. Build it, live it, and your future self will thank you.”

Building the Ultimate Safety Net with Integration Tests — Jimmy Bogard

Het was best druk toen Jimmy Bogard begon aan zijn talk. Z'n presentatie was: demo-heavy, geen theoretisch verhaal. Hij startte met een herkenbaar beeld — een project zonder tests, tot de eerste bug opdook. En dan de pijnlijke realiteit: hoe later je een bug ontdekt, hoe duurder het wordt. Toch blijven veel teams hangen bij unit tests of, erger nog, helemaal geen automatische tests.
Bogard haalde de testing pyramid erbij om dat punt te illustreren. Unit tests zijn snel en goedkoop, maar vaak te ver verwijderd van het echte proces. UI-tests zijn daarentegen traag en breekbaar. Integration tests — die het geheel samenbrengen — zijn trager dan unit tests, maar leveren wél de meeste waarde op, juist omdat ze de echte componenten gebruiken.
Hij liet een eenvoudig voorbeeld zien met een applicatie die queries uitvoert, business-logica afhandelt en data opslaat. In de praktijk zijn de meeste systemen complexer: veel interacties met de database, mocks die verouderen en test suites die vooral vertrouwen vernietigen in plaats van opbouwen. Zijn boodschap was duidelijk: “Mocks can lie. Integration tests don’t.”
Unit tests kunnen je een vals gevoel van veiligheid geven. Ze zijn vaak te sterk gekoppeld aan implementatiedetails, breken bij refactoring en vangen zelden echte regressies. Bogard pleitte ervoor om minder te “mocken” en meer te testen met echte afhankelijkheden — zonder externe tools, tenzij het echt niet anders kan.
Daarna kwam de live demo. Hij gebruikte een Microsoft.AspNetCore.Mvc.Testing library en WebApplicationFactory met xUnit. Een simpele HTTP-client maakte in-process calls naar de applicatie, controleerde responses en voerde assertions uit. De test draaide in slechts 282 ms — volledig end-to-end, zonder mocks.
De volgende stap: integratie met een echte database. Met FastEndpoints en Testcontainers liet hij zien hoe je PostgreSQL in Docker kunt starten voor elke test, onafhankelijk en schoon. Database-seeding, migraties en configuratie gebeurden automatisch. Door in-memory configuraties te gebruiken in plaats van appsettings.json, bleven de tests licht en flexibel.
Hij liet zien hoe belangrijk het is om logs direct in de testoutput te tonen, zodat fouten beter traceerbaar zijn. Daarna ging hij verder met meer geavanceerde scenario’s: authenticatie en externe API-calls. In plaats van auth uit te schakelen, introduceerde hij een TestJWT provider voor gecontroleerde tokens. Voor externe API’s gebruikte hij fakes — eenvoudige singleton-klassen die de complexiteit laag houden maar de logica realistisch nabootsen.
Zelfs Razor Pages kwamen voorbij: een test die de HTML-output controleert om te verifiëren dat de juiste data wordt weergegeven. De kern van zijn verhaal bleef overeind: test het systeem zoals het echt draait.
Aan het einde sloot hij af met een duidelijke boodschap:

“Stop aiming for the testing diamond — embrace integration tests. They’re slower, yes, but they give you confidence that your system actually works.”

Debugging Like a Coach: Fixing Team Bugs Before They Crash the Game — Amber Vanderburg

Amber Vanderburg opende haar sessie niet met code, maar met mensen. Haar stelling: de moeilijkste bugs in een organisatie zitten niet in de software — ze zitten in de teams. En zoals elke goede coach weet, los je die niet op met een snelle fix, maar met dialoog, reflectie en vertrouwen.
Ze gebruikte het beeld van debugging teams like code: analyseren, begrijpen, verbeteren. Haar structuur was eenvoudig maar krachtig: Fix. Improve. New. Niet alles hoeft direct opgelost, maar elk gesprek kan leiden tot verbetering.
De kern van haar verhaal kwam voort uit The Five Dysfunctions of a Team van Patrick Lencioni — met vertrouwen als absolute basis. Zonder vertrouwen beweegt niets. Ze gaf een grappig voorbeeld: “If I say I trust Amber to be late, that’s not trust — that’s experience.” Vertrouwen gaat over voorspelbaarheid, openheid en het nakomen van beloften.
In internationale of silo-gedreven teams is dat vaak een uitdaging. Eén persoon met vertrouwenissues kan al frictie veroorzaken. Amber liet zien hoe je dat kunt “mappen”: wie vertrouwt wie en waar stokt de samenwerking? Ze verwees naar het boek The Speed of Trust — hoe meer vertrouwen, hoe sneller teams leren en presteren.
Daarna introduceerde ze het What–Why–Alternative–Follow-up-model voor gesprekken. Richt je niet op wat iemand fout deed, maar waarom dat gedrag ontstaat, wat het effect is en welke alternatieven beter werken. Cruciaal: plan altijd een follow-up. Zonder consistentie vervliegt verandering.
Wanneer iets niet werkt, zei ze, flip the script. Stel andere vragen. Vraag niet: “Waarom ben je niet meer als Henry?”, maar: “Help me begrijpen waarom je deze keuze maakt.” Goede vragen nodigen uit tot reflectie — slechte vragen sluiten de deur.
Amber benadrukte ook de fear of conflict — een klassieke valkuil. Teams die conflicten vermijden, verliezen innovatie. Ze benoemde verschillende reacties: ontkennen, klagen, of de schuld bij een ander leggen. Maar echte groei vraagt candor — openheid met empathie. “Speak with courage, but also with care.”
Ze liet zien hoe je gesprekken kunt “debuggen”: kijk naar je sociale scripts. Als iemand zegt: “I’m fine,” vraag door. Misschien betekent dat eigenlijk: “I don’t feel supported.” Combineer de persoonlijke behoefte met de praktische noodzaak.
Een belangrijk punt ging over de kracht van pauze. “Don’t erase the empathy statement. Wait for it.” Een korte stilte van twee seconden na “I understand you” maakt ruimte voor echtheid. Ze noemde dit de power in pause.
In het tweede deel ging ze dieper in op leiderschap. “What would a good developer do? What would a good leader do?” — dat zijn de vragen die teams zichzelf dagelijks moeten stellen. Vermijd generieke vragen; luister om te begrijpen, niet om te antwoorden.
Ze sprak ook over process trust: het verschil tussen frustratie en overweldiging. Teams die vier processen gebruiken voor één verandering verliezen vertrouwen. Combineer feiten met gevoelens, want beide sturen gedrag.
Tenslotte: flipping the script op teamniveau. Mensen met sterke meningen die niet durven spreken, teams die politiek zijn geworden — je kunt ze helpen door ruimte te maken, bijvoorbeeld via anonieme feedback of timeboxed discussies.
Amber sloot af met een persoonlijk inzicht: grote teams werken alleen als mensen zichzelf overstijgen. “The greatest teams are made of people who build something bigger than themselves.”

React: The Most Common State Mistakes in 2025 — Cory House

Cory House begon zijn sessie met een quote van schrijver William Gibson: “The future is already here — it’s just not evenly distributed.” Dat gold volgens hem ook voor React. Terwijl sommige teams al met React 19, Server Components en lokale databases werken, worstelen anderen nog met dezelfde stateproblemen als in 2015.
Zijn talk was een reis door tien jaar React-state management — van de eerste componentDidMount() tot de nieuwste server features — met één duidelijke boodschap: de meeste fouten komen niet door de tools, maar door verkeerde keuzes in waar je state beheert.

Van componentDidMount tot React Query

Cory liet zien hoe data fetching in React zich heeft ontwikkeld.

• 2014: Alles gebeurde in componentDidMount().
• 2019: Met hooks verplaatsten we logica naar useEffect(), maar daarmee kwamen ook veel nieuwe problemen: over-fetching, dubbele requests en te veel boilerplate.
• 2020: Custom hooks brachten herbruikbaarheid — useFetch, useUser enz. — maar nog steeds was er veel code nodig.
• 2021: Enter React Query (nu TanStack Query). Een derde van de projecten gebruikt het inmiddels. Het introduceerde query keys, caching en mutations — allemaal gericht op minder boilerplate en betere performance.

Hij legde het principe stale-while-revalidate uit: data wordt eerst uit cache getoond en daarna ververst — een balans tussen snelheid en actualiteit.

React verandert de regels

Vanaf React 18 en 19 werd de manier waarop we state en data beheren opnieuw uitgevonden:

• 2022: useErrorBoundary — fouten worden automatisch afgehandeld.
• 2023: useSuspense voor data fetching — minder handmatige loading– en errorstates nodig.
• 2024: React Server Components — server-side rendering zonder extra fetch-calls aan de clientkant. Data wordt gestreamd als HTML en libraries als Moment.js blijven op de server.

Cory’s advies: “Try it when you can — it’s not the future, it’s already usable.”

2025 en verder: Local-first apps

De nieuwste trend volgens hem is local-first computing. Met tools als TanStack DB draait je database deels in de browser, in een aparte thread. Daardoor blijft je app bruikbaar bij trage of wegvallende verbindingen.
“Every app is a conflict resolution problem,” zei Cory — en lokale databases lossen dat op door synchronisatie en caching slim te combineren.

De 30 manieren om state te beheren

Cory toonde een dia met de titel: “There are 30 ways to handle state in React.”
Dat klinkt als een grap, maar het punt was serieus: er zijn véél lagen van state en de meeste fouten ontstaan doordat ze door elkaar worden gehaald.
Hij onderscheidde onder andere:

• URL state: zoals filters of sortering — deelbaar via link.
• Web storage: localStorage, sessionStorage, of IndexedDB.
• Local state: enkel binnen een component.
• Lifted state: gedeeld tussen componenten via een common parent.
• Derived state: berekende waarden, zoals fullName uit firstName + lastName.
• Refs: handig voor undo-functionaliteit of imperatieve logica.
• Context: voor globale settings zoals taal of dark mode.
• Remote state: data van een server, vaak met React Query of SWR.

Zijn advies: “Pick the lowest level that works. Don’t lift state unless you have to.”

Veelgemaakte fouten

Een paar veelvoorkomende problemen die hij noemde:

• Prop drilling: data die te diep doorgegeven wordt.
• Derived state in useState: dubbele bronnen van waarheid.
• Niet valideren van API-data: gebruik tools als Zod voor runtime-validatie.
• Overmatig global state management: niet alles hoort in Redux, Context of Zustand.

React 19 en de toekomst

Tot slot gaf Cory een vooruitblik op React 19 en wat hij “the good enough mindset” noemde:
gebruik de nieuwste tools waar ze waarde toevoegen, maar vermijd shiny-object-syndroom.
React 19 introduceert o.a. Action State voor formulieren — een manier om pending states, optimistic UI’s en fouten af te handelen zonder extra libraries.
Zijn voorbeeld: bij het verzenden van een formulier kun je direct een optimistic update tonen — alsof de actie geslaagd is — en pas terugrollen als er een fout optreedt. “Great UX assumes success, but gracefully handles failure.”

Conclusie

Cory sloot af met de boodschap dat state management in React minder gaat om syntax en meer om mentaal model.
Begrijp wáár je state hoort, hoe je het deelt en hoe je het valideert — dan maakt het niet uit of je Redux, React Query of een simpele hook gebruikt.
Of zoals hij het samenvatte:

“Managing state is like managing people — if you keep it local when you can, everything runs smoother.”

Fortifying your Workflows: Battle-Tested Security Strategies for Hardening GitHub Actions – Josh Johanning

Josh opende met een simpele maar ontnuchterende constatering: CI/CD workflows zijn nu een van de favoriete aanvalsvectors van kwaadwillenden — en GitHub Actions staat middenin het strijdtoneel. Zijn sessie was praktisch, direct en zat vol voorbeelden uit echte incidenten en best practices die je morgen kunt invoeren.

Waarom GitHub Actions hardenen / versterken?

Met meer dan 29.000 open-source Actions in de marketplace en workflows die arbitrary code uitvoeren, ontstaan er veel risico’s: onbedoelde privilege-escalatie, gelekte secrets, of build-servers die als springplank gebruikt worden voor grotere aanvallen. Josh verwees naar bekende supply-chain incidents, waaronder:

• tj-actions/changed-files (2025) – gehackte Action via malicious commit en re-tagging, die secrets stal via pull_request_target.
• Nx “s1ngularity” Attack (2025) – npm-token lek leidde tot besmette packages die crypto-wallets stalen.
• Shai-Hulud Worm (2025) – zelfreplicerend npm-worm die GitHub en npm tokens misbruikte.
• SolarWinds (2020) – buildserver-compromis met gesigneerde malware.

De zwakste schakel is niet je code, maar je supply chain. Vertrouwen en automatisering verhogen risico’s — en met AI-promptinjection komen daar nieuwe dreigingen bij.

Begin met minimale rechten: permissions & tokens

Vanaf februari 2023 heeft GitHub de default repository-permissies verlaagd naar read-only voor nieuwe orgs en enterprises, maar oudere repos behouden nog steeds read/write!
Josh benadrukte dat je permissies per job moet specificeren, niet op workflow-niveau, zodat alleen noodzakelijke stappen schrijfrechten krijgen.

Secrets en authenticatie

Er zijn drie strategieën:

1. GitHub secrets store – makkelijk, maar minder schaalbaar.
2. Extern (Azure Key Vault / HashiCorp Vault) – veiliger en beter auditbaar via OIDC (OpenID Connect).
3. Hybride aanpak – centrale Vault als bron, met geautomatiseerde sync naar repo-secrets.

Belangrijke tips:

• Gebruik geen gestructureerde data (zoals JSON) als secret.
• Mask dynamisch aangemaakte secrets in logs.
• Automatiseer rotatie en gebruik least-privilege credentials.

OIDC in plaats van long-lived tokens

Met OIDC kan je cloudtoegang regelen zonder tokens op te slaan of te roteren — authenticatie wordt door het externe platform afgehandeld.
Josh demonstreerde dit met Azure AD federated credentials en liet zien hoe je zelfs kunt afdwingen dat alleen goedgekeurde reusable workflows toegang krijgen tot productieomgevingen.
Ook npm schakelt over: klassieke long-lived tokens zijn uitgefaseerd, standaard expiratietijd is teruggebracht naar 7 dagen.
Gebruik OIDC + 2FA voor npm-publicaties om supply-chain risico’s te verkleinen.

Bouwketen integriteit: tags, SHAs en signing

GitHub Actions worden meestal gepubliceerd via Git-tags — en tags zijn mutable. Daardoor kon de tj-actions/changed-files hack duizenden repositories treffen.
Josh benadrukte:

• Pin altijd op commit SHA.
• Gebruik dependabot.yml om automatisch updates te blijven ontvangen.

Sinds augustus 2025 kun je zelfs SHA-pinning afdwingen als enterprise policy.

Immutable releases

In private preview (aug 2025) introduceerde GitHub Immutable Releases, waarmee assets, tags en attestaties cryptografisch worden vastgezet.

• Immutable assets kunnen niet meer aangepast of verwijderd worden.
• Tags zijn beschermd tegen force pushes.
• Releases worden automatisch ondertekend (attestation signing).

Josh toonde live dat force pushing of tag deletion wordt geblokkeerd zodra immutable releases aanstaan.

Script injection & OSS-beveiliging

Net als bij SQL-injectie geldt: gebruikersinput is onbetrouwbaar. Issue-titels, branch-namen of comments kunnen misbruikt worden in inline scripts.
Mitigaties:

• Gebruik Actions met input-parameters in plaats van inline run: scripts.
• Zet userinput eerst in environment-variabelen (env:).
• Beperk token-permissies strikt.

Algemene aanbevelingen

• Gebruik CODEOWNERS of rulesets voor workflowwijzigingen.
• Zet OpenSSF Scorecard Action in om supply-chain hygiene te meten.
• Vermijd pull_request_target — vooral in publieke repos.
• Stel een allow-list in van goedgekeurde Actions (liefst “as code” met automatische validatie).
• Gebruik aparte workflows voor PR-validatie versus productie-CD.

Scan vroeg, scan vaak: CodeQL, Dependabot, Secret scanning

Josh liet zien hoe CodeQL + Copilot Autofix kwetsbaarheden automatisch detecteren én suggesties geven, zoals:

• Ontbrekende permissions-blokken.
• Ongepinde tags.
• Kwetsbare versies van Actions.
• Script injection via gebruikersinput.

CodeQL is gratis voor openbare repos en je kunt security findings organiseren via security campaigns — waarbij Copilot Autofix automatisch patches voorstelt.
Dependabot Security Alerts is ook gratis en detecteert kwetsbare Actions via de GitHub Advisory Database.

Attestations: bewijs van herkomst

Attestations zijn het moderne alternatief voor traditionele code signing.
Ze registreren cryptografisch waar en door wie een artefact is gebouwd en worden automatisch vastgelegd in GitHub Actions via OIDC-signing.
Zo kan downstream-softwareverificatie plaatsvinden zonder extra tooling.

Beheer zelf-gehoste runners verstandig

Josh benadrukte opnieuw het SolarWinds-voorbeeld: treat build servers as production.
Gebruik GitHub-hosted runners als veilige default — die zijn:

• Ephemeral (nieuw image per job)
• Network-isolated
• Volledig vernietigd na afloop van de job

Voor self-hosted runners:

• Gebruik Actions Runner Controller (ARC) of Terraform-templates om ephemeral gedrag na te bootsen.
• Scheid build- en release-runners.
• Geef nooit productie-netwerktoegang.
• Disable repo-level runners om exfiltratie te voorkomen.
• Cache enkel tools, geen gevoelige data.

Praktische checklist

• Zet default repository permissions op minimaal (read-only).
• Pin alle 3rd-party Actions op commit SHA.
• Gebruik OIDC in plaats van long-lived secrets.
• Forceer commit signing en gebruik immutable releases.
• Automatiseer scans (CodeQL, Dependabot, secret scanning).
• Houd een Actions allow-list bij.
• Scheid workflows voor PR’s en releases.
• Beperk en isoleer self-hosted runners.
• Automatiseer tokenrotatie.

Tot slot

Josh sloot af met een realistische maar optimistische boodschap:

“De dreiging is reëel, maar de meeste mitigaties zijn laagdrempelig. Met een paar aanpassingen aan permissies, secrets en scans kun je je CI/CD-pijplijn aanzienlijk weerbaarder maken.”

Trusted. Respected. Heard. – Alice Meredith

Alice begon haar sessie met een glimlach en een waarschuwing: “Invloed begint niet bij je functietitel, maar bij je gedrag.” Ze maakt Pluralsight traningen en reist de wereld rond met haar Human Firewall Tour — waarin ze mensen leert om sterk, eerlijk en empathisch te communiceren binnen organisaties.

De essentie: invloed is gedrag, niet positie

Alice stelde een simpele vraag:

“Wie heeft hier invloed?”
Iedereen keek naar de leidinggevenden — maar volgens haar hebben ook juniors, stagiairs en specialisten invloed. Niet omdat ze macht hebben, maar omdat ze vertrouwen, respect en geloofwaardigheid opbouwen door hun gedrag.

Ze gebruikte het model A-B-C+:

• Authority – formele macht,
• Behaviour – hoe je handelt,
• Consequences – de resultaten die je gedrag oplevert,

Invloed is dus geen status, maar een reeks keuzes die je dagelijks maakt.

Word een persoon van eer (honor)

Echte invloed begint bij integriteit.

“Eén oneervolle actie kan jaren van vertrouwen vernietigen.”

Alice deelde haar persoonlijke “Honor Code” — vijf gedragingen die het fundament vormen voor geloofwaardigheid:

1. Speak the truth , zelfs als het ongemakkelijk is.
2. Act with follow-through – laat je daden overeenkomen met je woorden.
3. Avoid gossip , want roddel ondermijnt vertrouwen.
4. Give credit , want het verheffen van anderen vergroot je eigen invloed.
5. Stand firm , blijf trouw aan je waarden, ook onder druk.

Ze vertelde over teams die uit elkaar vielen door kleine, herhaalde overtredingen van deze ongeschreven regels — en over hoe herstel begint bij eerlijkheid.

Bouw diep vertrouwen – ga van “shallow” naar “deep water”

De meeste werkrelaties blijven aan de oppervlakte: vriendelijk, maar oppervlakkig.

“Shallow water feels safe. Deep water feels risky. But that’s where real connection lives.”

Echte invloed vraagt om kwetsbaarheid. Alice moedigde het publiek aan om de eerste stap te zetten:
– deel je fouten,
– vraag actief naar ervaringen van anderen,
– en wees nieuwsgierig in plaats van oordeelend.
Ze gebruikte de metafoor van het private pool vs open ocean:

• In je private pool voel je je comfortabel met bekenden.
• In de open oceaan ontmoet je nieuwe mensen, ideeën, perspectieven — daar groeit invloed.

Tijdens rondetafels en meetings, zei ze, moeten we bewust “deep water” betreden:
anderen uitnodigen die anders denken, niet alleen wie we al vertrouwen.

Emotionele intelligentie is belangrijker dan cv’s

Alice verwees naar onderzoek bij CEO’s: bij sollicitaties draait het zelden om technische skills, maar om emotionele intelligentie.
Wie zichzelf én anderen begrijpt, beïnvloedt effectiever.
Ze onderscheidde:

• Private awareness – weten wat er in jou omgaat.
• Public awareness – bewust zijn van wat anderen zien en voelen.

Wanneer die twee in balans zijn, word je betrouwbaar én menselijk.
Een voorbeeld: iemand die na een stressvol gesprek zegt “Geef me even tijd om te ontladen” toont bewustzijn — en voorkomt dat emoties onbedoeld richting anderen overslaan.

Inclusie als moreel kompas

“Be the one.”
De ene persoon die groet in de lift.
Die zegt: “Hé Tom, ik heb je al een tijdje niet gehoord.”
Die een stil persoon uitnodigt om iets te delen.

In een drukke corporate wereld waarin mensen vaak “te druk” zijn voor echte verbinding, is bewust inclusief gedrag revolutionair.
Alice noemde inclusie “the reset button for humanity”.
Ze moedigde aan om actief uit je bubbel te stappen: praat met mensen die anders denken, andere rollen of achtergronden hebben.

Feedback en herframing

Het laatste stuk ging het over feedbackcultuur. Negatieve feedback roept vaak defensie op — maar door reframing kun je dezelfde boodschap constructiever brengen.
In plaats van: “Je luistert nooit”, zeg:

“Ik merk dat ik moeite heb om mijn punt te maken. Kunnen we even stilstaan bij hoe we dit gesprek voeren?”

Ze noemde dit “Flipping the script” — de vaardigheid om feedback te geven met empathie, waardoor de ander open blijft.

Kernboodschap

Echte invloed begint niet bij positie , maar bij eer, vertrouwen, authenticiteit en inclusie.

“You don’t need a title to lead.
You just need the courage to be trusted, respected, and heard.”

Lessons from the Fast Lane – Robert Doornbos

De closing keynote van de conferentie werd gegeven door niemand minder dan Robert Doornbos , oud-Formule 1-coureur en tegenwoordig analist en ondernemer. Zijn verhaal was niet zomaar een verzameling anekdotes uit de racewereld — het was een kijkje achter de schermen van een hypercompetitieve sport waarin samenwerking, data en innovatie het verschil maken tussen winnen en uitvallen.

F1 is de ultieme teamsport

Hoewel veel mensen Formule 1 zien als een individuele sport, benadrukte Doornbos dat een F1-team draait op teamwork.
Een modern Red Bull-team bestaat uit ruim 600 mensen , waarvan 120 meereizen naar de 24 races per jaar — verspreid over de hele wereld, goed voor meer dan 1500 reiskilometers per seizoen.

“Een coureur staat op het podium, maar zonder het team is hij nergens.”

Van de monteurs tot de data-analisten, iedereen werkt synchroon samen om één doel te bereiken: de snelste zijn. Elke fractie van een seconde telt.

Innovatie en data: het hart van de snelheid

Formule 1 is net zo goed technologie als sport. Elke auto is uitgerust met meer dan 300 sensoren die continu data verzamelen: temperatuur, bandenslijtage, brandstofverbruik, aerodynamica enzovoort.
Die data stroomt naar gigantische IT-hubs op het circuit én naar het hoofdkwartier van het team. De communicatie moet realtime zijn, want elke vertraging in dataverkeer kan miljoenen kosten.

“Het is een partnerschap van data. Zonder meten geen winnen.”

Simulaties en windtunnels

Hij vertelde hoe belangrijk simulaties tegenwoordig zijn in F1. Coureurs rijden duizenden virtuele kilometers per week in een simulator van 12 miljoen euro — maar, voegde hij met een glimlach toe, “je kunt het gevoel van G-krachten nooit simuleren.”
Ook windtunnels spelen nog steeds een sleutelrol.
Al sinds de jaren dertig wordt aerodynamica getest in windtunnels — eerst voor vliegtuigen, later voor racewagens.

“Waar vliegtuigen lift creëren, creëren wij downforce — genoeg om een auto ondersteboven tegen het plafond te laten rijden.”

De kunst van de pitstop

Doornbos noemde de pitstop het perfecte voorbeeld van menselijke efficiëntie onder extreme druk.
Een compleet bandenwissel — door een team van twintig mensen — gebeurt in gemiddeld 1,8 seconden.

“Dat is pure choreografie. Elk teamlid weet exact wat zijn taak is, geen twijfel, geen ego, alleen perfectie.”

Hij gebruikte het als metafoor voor organisaties:

“In een goed team weet iedereen zijn rol en vertrouwt men elkaar blind. Dat is hoe je onder druk presteert.”

De toekomst: elektrificatie en veiligheid

Formule 1 is constant in beweging. Waar vroeger de V10- en V8-motoren domineerden, zijn moderne wagens hybride power units: een samenspel van verbrandingsmotor en elektrische systemen.
Ook veiligheid is enorm verbeterd — dankzij jarenlange innovaties die later hun weg vinden naar gewone wegauto’s.

“Alles wat we in F1 leren over veiligheid, vindt uiteindelijk z’n weg naar de straat.”

Lessen uit de racebaan

Doornbos sloot af met een krachtige boodschap die net zo goed geldt voor technologie, business en persoonlijke groei:

“Als alles onder controle lijkt, ga je niet snel genoeg.”

Hij bedoelde daarmee dat echte vooruitgang ontstaat aan de rand van comfort — waar risico, lef en teamwork samenkomen.
Fouten horen erbij, maar zonder ambitie, experiment en durf komt niemand op pole position.

Takeaways uit de Fast Lane

1. Data is pas waardevol als je er actie op onderneemt.
2. Snelheid komt van vertrouwen, niet van chaos.
3. Simuleren is goed, maar echte ervaring blijft onmisbaar.
4. Perfectie is teamwork – niet ego.
5. Durf gas te geven, ook als je het nog niet volledig onder controle hebt.

Conclusie — Techorama 2025

Techorama 2025 bewees opnieuw waarom het een van de meest toonaangevende techconferenties van de Benelux is.
Drie dagen lang stond innovatie centraal: van diepgaande sessies over AI-integratie en cloud-native architecturen tot inspirerende keynotes over leiderschap, creativiteit en de toekomst van softwareontwikkeling.

Wat vooral opviel, was de balans tussen technologie en menselijkheid. Sprekers benadrukten niet alleen de kracht van nieuwe tools en frameworks, maar ook het belang van samenwerking, ethiek en een gezonde techcultuur. De rode draad? Technologie ontwikkelt zich razendsnel, maar de kern blijft: mensen die met passie bouwen, leren en delen.

Of je nu kwam voor de nieuwste inzichten in .NET, DevOps, data, of design systems — Techorama 2025 bood iets voor iedereen. En terwijl we naar huis gingen met volle notitieboeken en nog vollere hoofden, bleef één gedachte hangen: de toekomst van technologie is niet iets dat ons overkomt, maar iets wat we samen vormgeven.

Tot volgend jaar — waar we elkaar opnieuw uitdagen, inspireren en verbinden.