Door Rob Pijnenburg, samen met Tom Heijmans
Op 27 en 28 oktober waren mijn collega Tom en ik bij Techorama in de Pathé in Utrecht. Twee dagen vol technische sessies over AI, softwarearchitectuur en tooling. Ik ging erheen om nieuwe kennis op te doen, inspiratie te verzamelen en te ontdekken hoe andere engineers omgaan met de ontwikkelingen rondom AI. Wat vooral bleef hangen? Een goed AI-model is belangrijk, maar de manier waarop je het inzet, bepaalt uiteindelijk wat je ermee bereikt.
Een conferentie die al vóór de eerste sessie begon
De voorbereiding liet ik natuurlijk grotendeels aan AI over. Ik gaf Claude het programma van Techorama en vroeg om een persoonlijk schema, gericht op AI, architectuur en tooling. Inclusief alternatieve sessies en een iCal-bestand voor mijn agenda.
Dat ging niet helemaal vanzelf. Eerst gaf Claude aan dat hij de sessies niet online kon ophalen, terwijl hij zelf de links al in het Excel-bestand had gezet. Na een kleine aanwijzing werkte het prima. Een mooi voorbeeld van hoe AI je werk makkelijker maakt, maar ook waarom je zelf moet blijven nadenken. Eenmaal in Utrecht konden we ons volledig richten op de inhoud. En er kwam behoorlijk wat voorbij.
Zelf agents bouwen is minder ingewikkeld dan je denkt
Een van de interessantste sessies was die van Max Gfeller, die liet zien hoe je zelf een coding agent bouwt. Zijn verhaal bevestigde iets wat we in de praktijk ook steeds vaker zien: het bouwen van een agent hoeft helemaal niet zo ingewikkeld te zijn.
Met een aantal relatief eenvoudige stappen kun je al een werkende coding agent maken. De uitdaging zit vervolgens vooral in hoe je die agent laat samenwerken met de omgeving en hoe je omgaat met de problemen waar hij tegenaan loopt.
Max liet bijvoorbeeld zien hoe hun agent via een zogenaamde venting-optie zelf kan aangeven waar hij vastloopt. Een interessante manier om meer inzicht te krijgen in het gedrag van een agent.
Ook de sessie van Geert van der Cruijsen over OpenCode maakte indruk. Terwijl grote partijen als Microsoft, Anthropic en OpenAI hun eigen tooling blijven ontwikkelen, laat OpenCode zien wat er mogelijk is met een open-source alternatief dat met verschillende modellen kan werken.
Geert demonstreerde onder andere hoe je taken op afstand kunt uitvoeren en hoe OpenSpec daarbij kan helpen. Na deze sessie wilde ik eigenlijk meteen OpenCode weer aanslingeren en koppelen aan onze lokale modellen.
MCP: niet denken vanuit data, maar vanuit mogelijkheden
Met onze eigen MCP-workshop bij Bright Cubes in het vooruitzicht was de sessie van Rockford (Rocky) Lhotka extra interessant. Rocky benadrukte een belangrijk verschil tussen traditionele software en AI: een Large Language Model (LLM) is niet-deterministisch. Je kunt dus niet verwachten dat een model bij dezelfde input altijd exact hetzelfde gedrag vertoont. Volgens Rocky kun je een LLM daarom beter benaderen als een mens dan als een traditioneel programma. Dat heeft gevolgen voor de manier waarop je systemen ontwerpt.
Een belangrijk inzicht was het verschil tussen een traditionele API en een MCP-server. Waar een API vaak data-shaped is, moet een MCP-server juist capability-shaped zijn. Je stelt niet simpelweg data beschikbaar, maar biedt mogelijkheden waarmee een agent een taak kan uitvoeren.
Tijdens een tweede sessie ging Rocky dieper in op de ontwikkelingen binnen het Model Context Protocol. Vooral de ondersteuning voor een stateless protocol, multi-round-trip requests en verbeterde autorisatie zijn interessante stappen.
Het zijn ontwikkelingen die MCP steeds bruikbaarder maken voor toepassingen binnen organisaties. Tegelijkertijd blijft het belangrijk om rekening te houden met het onvoorspelbare gedrag van agents.
Deze inzichten nemen we zeker mee naar onze eigen workshop op 19 november.
Software ontwerpen voor agents vraagt om andere keuzes
Een andere sessie die me aan het denken zette, was die van Steve Smith, beter bekend als Ardalis. Hij ging in op hoe we software moeten ontwerpen wanneer AI-agents een steeds grotere rol krijgen in development.
Zijn verwachting is dat abonnementen voor agents het komende jaar mogelijk 10 tot 100 keer duurder worden, of dat aanbieders volledig overstappen op gebruiksgebaseerde tarieven.
Of die voorspelling precies uitkomt, moeten we natuurlijk afwachten. Maar het onderliggende punt is interessant: efficiënt omgaan met tokens wordt steeds belangrijker. Dat betekent dat bestaande principes rondom softwarekwaliteit een nieuwe dimensie krijgen. Denk aan kleinere bestanden, minder technical debt en een overzichtelijke codebase.
Dat zijn sowieso goede uitgangspunten voor softwareontwikkeling, maar ze helpen ook om agents efficiënter te laten werken. Een agent die minder onnodige context hoeft te verwerken, kan sneller en mogelijk goedkoper tot een resultaat komen.
De rode draad: context en de harness bepalen het resultaat
Als ik één technisch inzicht uit Techorama moet kiezen, dan is het wel het belang van context.
Tijdens verschillende sessies kwam de term dumb zone voorbij. Daarmee wordt het punt bedoeld waarop een model slechter begint te presteren doordat de context te vol raakt. Dat is interessant, omdat de adviezen hierover behoorlijk zijn veranderd.
Een jaar geleden was het idee nog dat bestanden als AGENTS.md en SKILL.md zo uitgebreid mogelijk moesten zijn. Hoe meer instructies en achtergrondinformatie, hoe beter. Inmiddels verschuift dat inzicht. Juist compacte, gerichte instructies blijken belangrijk, omdat al die informatie onderdeel wordt van de context die een model moet verwerken.
Daarnaast werd meerdere keren het belang van een goede harness benadrukt: de logica rondom het model die bepaalt welke informatie wordt meegestuurd, op welk moment dat gebeurt en hoe de context beheersbaar blijft.
Het model zelf is dus maar een deel van de oplossing. De architectuur eromheen bepaalt in belangrijke mate hoe effectief een agent zijn werk kan doen. Dat vind ik misschien wel de belangrijkste ontwikkeling. We zijn steeds minder alleen bezig met de vraag welk model het beste is, en steeds meer met hoe we een goede omgeving bouwen waarin dat model optimaal kan functioneren.
Van nieuwe inzichten naar onze eigen omgeving
Naast alle AI-sessies was er gelukkig ook genoeg aandacht voor andere technische onderwerpen. Zo liet Laila Bougria zien hoe je veelvoorkomende problemen in event-driven architecturen kunt voorkomen. Vooral haar verhaal over coupling, self-contained events en het belang van schemabeheer leverde herkenbare inzichten op.
Ook de sessie over Aspire van Maddy Montaquila en Tommaso Stocchi was interessant. We gebruiken Aspire intern al regelmatig, maar hun voorbeelden lieten zien dat er nog meer mogelijkheden zijn, onder andere bij het integreren van agents.
Tom en ik hebben daarnaast ieder onze eigen technische onderwerpen opgepakt. Tom dook onder andere in async en OpenTelemetry, terwijl ik me verder verdiepte in Kiota, een Microsoft-tool voor het werken met REST-API's.
En natuurlijk waren er sessies over Dapr, architectuurprincipes en zelfs het bouwen van een eigen LLM. Vooral die laatste, een behoorlijk technische presentatie van Bart de Smet, liet zien hoeveel er achter het trainen van een model schuilgaat.
Genoeg ideeën dus om zelf mee te experimenteren.
Wat betekent dit voor ons werk bij Bright Cubes?
Wat me tijdens Techorama opviel, is hoeveel engineers inmiddels met AI experimenteren. In gesprekken tussen de sessies door kwamen allerlei toepassingen, lokale modellen en ideeën voor agents voorbij. Tegelijkertijd merkte ik dat we bij Bright Cubes al behoorlijk ver zijn met een aantal van deze ontwikkelingen.
We experimenteren binnen ons AI-lab met lokale modellen, beschikken over meerdere DGX'en om modellen op te draaien en werken aan het ontsluiten van verschillende interne informatiebronnen. Dat sluit goed aan bij een ander inzicht uit de keynote van Dado Van Peteghem. Hij gaf aan dat slechts een klein deel van alle bedrijfsdata wordt gebruikt om AI-modellen te trainen. De waarde van AI zit dus niet alleen in het model, maar juist ook in de informatie die je beschikbaar maakt en de manier waarop je die informatie gebruikt.
Voor organisaties betekent dat dat je niet automatisch het nieuwste of grootste model nodig hebt. Het gaat erom dat je de juiste data, context en tooling samenbrengt om een concreet probleem op te lossen, maar ook inziet wanneer AI niet de oplossing is. En precies daar liggen interessante technische uitdagingen.
Blijven experimenteren, maar de mens niet vergeten
De openingskeynote van Dado Van Peteghem bevatte nog een boodschap die goed bij de rest van de conferentie paste. Volgens Dado heb je ongeveer 100 uur nodig om een nieuwe vaardigheid echt onder de knie te krijgen. Omgerekend is dat zo'n 18 minuten per dag gedurende een jaar. Zijn advies was simpel: besteed die tijd niet alleen aan lezen over AI, maar vooral aan zelf experimenteren.
Dat herken ik. Je leert pas echt wat een model of agent kan wanneer je ermee gaat bouwen, tegen beperkingen aanloopt en ontdekt hoe je die kunt oplossen. Tegelijkertijd waarschuwde Dado voor de balans tussen scale en soul. AI maakt het mogelijk om enorm op te schalen, maar we moeten daarbij de menselijke kant niet verliezen.
Na twee dagen Techorama gingen Tom en ik met een flinke hoeveelheid nieuwe ideeën naar huis. Sommige tools willen we direct proberen, andere inzichten nemen we mee in onze bestaande projecten en onze eigen AI-workshops.
Mijn belangrijkste conclusie? Iedereen is bezig met AI, maar het verschil zit steeds meer in hoe je het inricht. Houd de context klein, investeer in een goede harness en ontwerp je software zo dat agents er efficiënt mee kunnen werken.
En vooral: blijf zelf bouwen en experimenteren. Want uiteindelijk leer je daar het meeste van.