Van test naar code: Zo stuur je AI bij het programmeren

In deze aflevering hoor je Bouke Nijhuis, CTO bij CINQ ICT, die een verrassende techniek onthult om AI precies te laten doen wat jij wilt bij het schrijven van code. Bouke deelt waardevolle inzichten over het samenwerken met verschillende AI-assistenten, hoe je hun output kunt vertrouwen en hoe zijn aanpak ook waardevol kan zijn in andere vakgebieden. [Muziek] Hoi, leuk dat je luistert naar een nieuwe aflevering van AIToday Live. En dit keer live, hè Niels? Vanavond podium vanuit De Fabrique in Utrecht. En we zitten op het hoofdpodium. Heel leuk. Samen met een ontzettend interessante gast. Want we hebben namelijk Bouke Nijhuis, CTO bij CINQ ICT. Of ICT, moet ik zeggen. En hij is een veel gevraagd spreker in de internationale developers community. Bouke heeft ontdekt hoe je AI inzet om precies te doen wat jij wilt. En in dit geval is dat het schrijven van code. Hij gebruikt daarvoor een techniek die Test Driven Development heet. Eerst omschrijft je namelijk precies wat je wilt bereiken. En daarna gaat de AI aan de slag. Dat klinkt als een interessante aanpak. Deze aanpak is eerst helder omschrijven van wat je wilt bereiken. En dan AI in het werk laten doen. Het is interessant voor iedereen die met AI werkt. Of je nu in de marketing teksten schrijft, financiële analyses maakt. Of HR-processen verbeterd. Bouke's ervaringen laten zien hoe je AI effectief kunt inzetten als assistent. Vandaag details aan inzichten over het samenwerken met verschillende AI-assistenten. Hoe je hun output kunt vertrouwen. En hoe zijn aanpak ook waardevol kan zijn in andere vakgebieden. We hebben 45 minuten. Waarvan 30 minuten even gewoon zo met jou een op een. En daarna hebben we een kwartier van vragen. Dus let's go. Laten we beginnen. Voor niet-technische luisteraars. Kun je als eerste eens uitleggen wat test-driven development is? En waarom het zo belangrijk is in de softwareontwikkeling? Hele goede vraag. Test-driven development is een techniek om software te ontwikkelen. Vroeger. Vroeger. In het verleden schreef men software. En ging men vaak daarna testen schrijven. Ik weet niet hoe lang geleden. Maar een tijdje geleden is de test-driven development bedacht. En daar is het idee andersom. Je schrijft eerst je testen. En dan schrijf je je software. En vervolgens gebruik je je testen om te kijken of je de juiste software hebt geschreven. Er zijn heel veel redenen om dit te doen. Maar er zijn twee redenen die ik echt goede redenen vind. En de eerste is dat je als je eerst je implementatie schrijft en daarna je testen. Dan zijn je testen beïnvloed door je eigen implementatie. Dus dat gaan altijd minder goede testen zijn. Dus andersom is beter. En de tweede is, ik geloof echt in het volgende. Hoe meer je nadenkt over iets, hoe beter het eindresultaat zal zijn. Als je eerst je testen schrijft, denk je goed na over je implementatie. En daarom zul je vervolgens ook een betere implementatie schrijven. En hoe bepaal je dan wat je gaat testen? Dat is een hele goede vraag. Maar als het goed is, voordat je iets gaat bouwen, weet je al ongeveer wat je wil bouwen. Je weet al wat de software moet gaan doen. Dus je kan opschrijven. Als ik deze input geef, verwacht ik dat de software deze output geeft. Want de voorjaar zou je daar al een beeld bij moeten hebben. Ik geloof ook heilig, als je eenmaal de testen hebt gedaan en dan je implementatie, dat je dan nieuwe testen erbij gaat schrijven. Want je krijgt nieuwe inzichten. Je bent eigenlijk heel erg bezig met de waarom vraag, toch? Waarom wil ik iets? Hoe kom ik daar? En wat heb ik er dan voor nodig? Je kan testen ook zien als een vorm van specificatie. Dus een specificatie in software. Dat deden we vroeger heel veel. Gingen mensen van tevoren heel het boekwerk schrijven van dit moet de software doen. Maar ja, in de praktijk, niemand ging die boeken lezen. En de software werd dus anders, ook door nieuwe inzichten. Tegenwoordig doen we dat vaak in de vorm van testen. Dus je kan de test zien als een vorm van specificeren. Wat zou mijn programma moeten doen? En dan heb je dat gespecificeerd. Maar hoe komt AI dan hier om de hoek? Ja, een hele goede vraag. Ik zal even een kleine introductie geven. Jullie hebben allemaal ondertussen met AI gespeeld. Anders zou je waarschijnlijk niet naar deze podcast luisteren. En dan weet je dus ook dat AI doet het eigenlijk... Ik persoonlijk vind het heel lekker werken. Alleen af en toe verzint AI dingen. En dat is een probleem. Dat is overal een probleem, maar vooral in de software development. Dus als je de AI gebruikt voor software development. En hij gaat dingen verzinnen, krijg je dus verkeerde implementaties. De reden dat ik hierover na ging denken is als volgt. Ga ik even een jaartje terug. Een jaartje terug stond ik op conferenties met een praatje genaamd The Battle of the AI Coding Assistance. In dit praatje vergeleek ik features van verschillende AI Coding Assistance. En dan kun je denken aan GitHub Copilot. Kun je denken aan JetBrains AI System, maar ook ChatGPT. En een van de features die ik daar liet zien was het feit dat deze assistance assistenten best wel goed waren in het genereren van testcases. Hoe werkt dat? Jij schrijft implementatie, je geeft aan AI en je vraagt om testcases. In bijna alle gevallen komt hij met de happy flow. In meeste gevallen komen er wel wat edge cases. En als je dan nog niet blij bent, kan je gewoon van meer vragen totdat je een volledige testfeed hebt. Na een van deze presentaties kwam dus iemand naar me toe en zei hé, waarom doe je niet andersom? Ik zei andersom? Wat bedoel je met andersom? Nou, jij schrijft de testen, je geeft ze aan AI en dan vraag je om implementatie. En dan zeg ik, wow, dat is een leuk idee zeg. Maar ik weet niet of het werd, nooit gedaan, maar ik ga het uitzoeken. En dat uitzoeken, dat heeft geleid tot mijn nieuwe praatje. En daar kijk ik dus, hoe kan je testdriven development combineren met AI? En wat is dan het inzicht, waarom zei je eigenlijk oeh? Wat is het inzicht wat je gekregen hebt, die zegt van ja, maar nou moet ik ook deze aanpak gaan volgen en blijven volgen. Ja, ik wil heel even afmaken hoe we dat dan doen. Ik wil daarna kijken. Ja, graag. Dus toen ging ik daar dus over nadenken en toen kwam ik erachter tot testdriven development, dus van tevoren testen schrijven en Gen AI een leuke combi is. Dus hoe is het proces? Dat ga ik nu uitleggen, dan heb je een idee hoe het werkt. Je schrijft dus testen, je geeft deze aan Gen AI, dan zeg je, hey, kom, geef mij de implementatie, die deze testen laat slagen. Dan komt er dus een implementatie uit Gen AI en als dit een goede, vervolgens draai je daar de testen tegen en als die testen slagen, dan heb je productiecode, tenminste als je je testen vertrouwt. Nou is dit de theorie natuurlijk. In de praktijk gaan er ook dingen mis, want in de praktijk is de theorie, dan gaat het een beetje anders. Maar dus soms vraag je de AI om een implementatie en dan krijg je een uitleg of je krijgt code die niet compileert. Nou dan moet je dus blijven vragen totdat je compileren en de code krijgt, zodat je er testen tegenaan kan draaien. En soms slagen niet alle testen. Als dat het geval is, dan pak je de testen die niet slagen, die geef je terug in AI en je zegt, hey, deze test slagen niet, kom nu met implementatie waarvoor deze testen ook slagen. Dus je krijgt een soort van feedback loop. En in principe, dat blijf je doen tot de max natuurlijk. En dan komt de code uit. En dus ik meen serieus, als je je testen vertrouwt, vertrouw je dus ook de code die uit deze aanpak komt. Dus kortweg gezegd laat je eigenlijk de AI steeds de problemen oplossen net zolang totdat de testen slagen. Ja. Dat lijkt me een hele mooie manier. Dus je laat AI de problemen creëren en daarna ze oplossen door de juiste definitie van de test. Nou, ik denk de kracht van deze methode, jij vroeg net waarom sloeg je hierop aan, is je kan de AI controleren. En dat is dus, ik zou zeggen tegenwoordig als ik een AI gebruik, 80 tot 90% van de antwoorden zijn gewoon goed. Maar die laatste 10 tot 20%, daar zit het probleem. En met deze methode die ik net uitleg, heb je dus een geautomatiseerde manier om de AI te controleren. En dat maakt deze, dit idee, dit concept zo krachtig. Ja, nee, ga je aan. Dat klinkt heel logisch. En gebruik je dit dan altijd als je met AI aan de slag gaat? Of in bepaalde doelstellingen nu voor softwareontwikkeling? Of eigenlijk altijd deze aanpak? Nee, hele goede vraag. Het is echt de conceptfase. Dus ik heb gekeken, ik heb een aantal testen gemaakt. Ik heb die AI gegeven. Ik heb ook een tool geschreven die dit doet. Want in de presentatie laat ik het eerst handmatig zien. Dus dan knip ik code vanuit mijn IDE, ga ik naar mijn browser. Maar dat is heel veel werk, heel handmatig werk. Dus ik heb een tooltje gemaakt. Die zeg je, daar staat de test en ga je ding doen. En die tool gaat dan met AI praten en die gaat die loopjes allemaal doen. Totdat de code uitkomt en die zet je op de goede plek en dan ben je klaar. Ik heb het, ja dus, om je vraag te beantwoorden gebruik ik elke dag nee. Maar ik programmeer ook niet meer zoveel. Maar ik heb bijvoorbeeld wel deze tool gebruikt om de tool te verbeteren. Oh, kan je daar wat verder over uitweiden? Ja, zeker. Dus één, er zit iets in de tool. Dat moet, dat heet de code container. Nou, die heeft een aantal features. Als de LLM met een antwoord komt, dan wordt die bewaart in deze container. Vervolgens, ik heb hem in Java gemaakt. Ik ben van origine Java programmer. Er zijn ook mensen, zeg maar, die niet in de software development zitten. Die luisteren, die denken in een container. Die denken misschien in een zeecontainer of een container buiten. De afvalcontainer. Waar hebben we het over? Ja, goede vraag. Het is een Java klasse. Dus een module in een programmeertaal. Oh ja. En deze moet twee dingen doen. Dus hij heeft een implementatie, een stuk tekst, een stuk code. En dan moet hij de naam van de klasse eruit halen. In Java heb je dat nodig om de juiste file naam te pakken. En in Java kan je packages gebruiken. Dus hij moet het package keyword opzoeken. En hij moet de tekst die erachter staat, moet hij eruit halen. Nou, dat zijn technische redenen. Daar ga ik nu niet op in. Want dat is de mensen die het niet programmeren. Maar wat je dus moet doen, is tekst uit tekst extraheren. En in heel veel gevallen, de beste manier om dat te doen, weer een moeilijk woord, is een reguliere expressie. Dus een manier in de informatica om tekst uit tekst te halen. Die vind ik heel moeilijk als mens. Ik vind het echt moeilijk om een reguliere expressie te schrijven. Dus je schrijft allemaal punten, sterretjes, haakjes. Je wordt er helemaal gek van. Het is voor computers fantastisch, maar voor mensen iets moeilijker. Dus ik had een hele slechte andere oplossing geschreven. Ik wist van tevoren, die is niet goed. Maar ja, ik moest erg beginnen. En vervolgens zat ik in die... Ja, ik had mijn slechte oplossing, die de hele tijd stuk ging. Ik moest iets beters hebben, maar ik had wel de testen. Dus ik heb testen gevoerd aan mijn tool. En vervolgens kwam die mijn implementatie met reguliere expressies, zoals het hoort. Kijk. En die kon ik even in de tool stoppen. Heel mooi. Ja. Dus dat is toch hoe het gaat. En hoe zou je dit kunnen vertalen naar de luisteraar die denkt van... Oh, dit is best allemaal een technisch verhaal. Hoe zou ik dit nou in mijn andere werk kunnen gebruiken? Is jouw vraag nu, hoe kun je dit in niet-programmeercontext gebruiken? Ja. Ja, dat vind ik een hele goede vraag en daar heb ik helaas geen goed antwoord op. Maar dat is wel iets waar ik nu veel meer bezig ben. Dus dit probleem is in principe, lost dit het genereren van code, niet vertrouwen van LLM en genereren van code op. Maar ja, je wilt het eigenlijk dus inderdaad breder inzetten. Wat is een unit test in het schrijven van een marketing tekst? Als jij mij die vraag kan beantwoorden, dan heb ik de oplossing voor jou. Ik denk niet dat daar geautomatiseerde dingen voor zijn, maar ik ben wel steeds meer... Nou, wat je daar natuurlijk wel hebt, is dat je ook nadenkt over de waarom, over... Wat verwacht ik? Wat vind ik kwaliteit? Wat moet eruit? Wat is je einddoel wat je wil bereiken? Kan je dat uitdrukken in getallen? Iets wat je kan meten? Nou, je zou er cijfers aan kunnen geven. Dat je zegt van, als je bijvoorbeeld je vraagt, iets moet heel actief geschreven worden. Kan je daar een cijfer aan hangen. En als dat cijfer onder een bepaald niveau is, kan je zeggen van, ja, maak het dan nog actiever. Volgens mij kom je dan in zo'n zelde loop zeg maar uit als waar jij in zit. Dat je net zo lang die cijfers hebt bereikt eigenlijk. Wat je voor deze methode hebt, is een manier om te meten of het antwoord goed genoeg is. En als je dat hebt, dan kan het. Ja, mooi. Zeker. Zo, zijn we een stukje verder gekomen. Ik had ook nog wel een vraag van, ja, toch nog wel de eye-opener. Weet je, waar zit, waar zat nou zeg maar in dit hele proces? Dat je dacht van, ja, maar nu moet ik het echt wel doorzetten. Want dit maakt mijn werk makkelijker. Dit is ook iets voor mijn collega's. Ik denk dat het iets meer is dan individueel hoe jij nu een aanpak hebt. Ja, ik denk dat het voor mij de eye-opener is. Vroeger toen ik AI gebruikte en er kwam antwoorden uit, moest ik altijd controleren, is dat antwoord correct? Heeft hij niet wat verzonnen? En het feit dat ik nu een geautomatiseerde manier heb om dit te doen, dat was voor mij de eye-opener. Dus het feit dat je, ja, je stopt ergens iets in, je gaat een kop koffie drinken, je komt terug en je hebt een antwoord. En je weet dat het antwoord goed is. Je hoeft het niet meer te controleren, want je hebt zelf al een manier gegeven om te controleren. En dat was voor mij de eye-opener. Mooi. Ja, je hebt meerdere assistenten. En de tijd, als ik je zo wil praten, want je praat al over vroeger. Ik weet niet wat vroeger in deze term is. Volgens mij gaan we heel snel al naar vroeger als we met deze technologie aan de slag gaan. Eerst even die vraag. Wat is vroeger? Ja, heel goed. Vroeger, dus voordat ik deze tool, voordat ik deze idee had en voordat ik deze tool ontwikkeld had, kan ik ook wel even iets over vertellen. Ik heb begin van het jaar ben ik hier eigenlijk een beetje mee begonnen. En toen was ik vooral bezig met ChatGPT. JetGPT heeft een API, net als alle andere LLMs. En die heb ik toen gebruikt. Wat ik steeds meer hoorde en steeds interessanter werd, was het feit dat tegenwoordig kan je ook lokale modellen draaien. Dus daar ben ik ook mee gaan spelen. Dus in de tool die ik ontwikkeld heb, kan je dus gebruiken of het lokale model gewoon op mijn MacBook, wat trouwens verrassend goed werd. Maar als je dan toch meer rekenkracht nodig hebt, dan kan je altijd nog zeggen, ga naar ChatGPT. En tegenwoordig doe ik ook Anthropic. Er zijn redelijk wat mensen in mijn community, zeg maar de mensen waar ik mee om ga, die zeggen dat Anthropic de beste code genereert. Oké. En wat is dan de beste? Wat zijn dan een beetje die verschillen, die smaakjes die je ertussen hebt? Waar loop je dan tegenaan? Ja, dat is heel goed. Ik kan niet zeggen, ChatGPT doet dit beter of Anthropic doet dat beter. Dit is wat mensen zeggen. Beide werken voor mij. Ik heb nog niet echt een use case kunnen vinden dat de ene het beter doet dan de ander. Natuurlijk hebben ze beide ook al wel modellen. En modellen zijn hun ene model specifiek goed daar, en de andere model specifiek daar goed in. Ik ben nog wel geïnteresseerd in het lokale model, open source neem ik aan. Wat gebruik je daarvoor? Ja, technisch, Ollama. Dat is een tool die je kan gewoon downloaden. Dat is een beetje de docker voor de LLMs, voor de large language models. Ja, ik dacht echt dat is veel ingewikkelder. Dus ik dacht echt, ik moet wat downloaden, 20 moeilijke stappen doen, hopen dat het werkt. Het bleek gewoon één tooltje te zijn met twee commandos en draait. Ja. En dan kan je allerlei open source modellen gewoon lokaal draaien. Maar heb je daar een favoriet in, voor het programmeren? Welke van de open source modellen gebruik je? Ik gebruik Llama 3.1, dat is van Meta, zeg maar het oude Facebook. Ik heb er meer dan tien geprobeerd, maar deze is gewoon goed. Ik weet dat het tegenwoordig ook een 3.2 versie is. Alleen die bestond uit een aantal kleine modellen die het minder goed deden. Een aantal grote modellen die waren multimodaal. Ja, dat heb ik niet nodig als ik aan het programmeren ben. Zeker nog, doe mij een LLM die alleen maar code genereert, in één taal. Ik zie daar wel toekomst in. Ik denk dat daar ook nog wel heel interessante ontwikkelingen kunnen plaatsvinden bij je toekomst. Dus meer specifieke modellen voor de use case die jij dan in ieder geval hebt, is code genereren. In plaats van ook nog plaatjes erbij maken, maar dat werkt niet zo lekker in je code. Ja, sterker nog, Llama 3.1 is nu ook gewoon tekst. Ik weet niet hoe ze doen, maar voor mij is half internet wordt die opgetraind. Het is allemaal overbodig informatie als je code wil genereren. En hoe heb je dat getest? Want je hebt het over testen. En hoe heb je dit dan getest? En wat kunnen mensen daarvan, andere vakgebieden daarvan leren? Goeie vraag. Dit is puur, ik heb gekeken. Dus als ik een presentatie geef, heb ik een aantal standaard voorbeelden en die probeer ik dan. En ik zag dus gewoon dat Lama 3.1 het beste deed. Ik heb geen wetenschappelijke goede manier om te bewijzen dat dit mijn beste model is. Maar goed, hij doet het gewoon lekker voor mij. Ja, dus blijven kwaliteit, blijven monitoren, kijken of de gewenste output er is. Nou, nu je dit zegt, je triggert wel iets bij mij. Dus ik vertelde jullie net over loops, over feedback loops. Als een model snel antwoorden geeft, dan heeft hij dus een weinig loops nodig. Dus ik zie in de output hoe snel hij met een antwoord komt. Ik zie het aantal loops dat is geweest. Als het aantal loops lager is, dan is het meestal een beter model. Ik zie ook als ik cloud modellen gebruik, dan zijn het vaak one-shot solutions. In ieder geval de aantal loops die hij maakt zijn kleiner. En daaraan kan je een beetje meten wat het beste model voor mij is. En die verschillende modellen zouden andere mensen kunnen zien als van, je gebruikt ChatGPT of je gebruikt Claude of je gebruikt Gemini van Google. Maar zo heb jij ook gekeken naar verschillende programmeerassistenten. Dus dat je verschillende smaken hebt voor het genereren van code. Ja, klopt. Dat heb ik vorig jaar vooral gedaan. En dan keek ik vooral naar AI-assistenten die in je browser draaiden. Dus dan hebben we het over GitHub Copilot. In het begin deed ik het ook al met ChatGPT. Maar we hebben ook JetBrains AI systemen. Dat is de technische voor je, denk ik. En dan heb je nog iets dat je hebt naar. Maar daar heb ik gekeken naar de verschillen. En eigenlijk, wat ik daar geleerd heb, is dat het eigenlijk niet zoveel uitmaakt welk model je gebruikt. Ze zijn allemaal best wel oké. Maar het is vooral de integratie met je programmeeromgeving, die het lekker maakt werken. Die ervoor zorgt dat je hem blijft en blijft gebruiken. Dat je verslaafd raakt. Moest je ook je aanpak aanpassen? Van hoe je hiervoor aan het programmeren was? En hoe je dat nu doet? Goeie vraag. Ik heb dit niet bewust gedaan. Maar nu je dit vraagt, wat ik merk wat ik nu doe, vroeger. Dus voor de interviertje van ChatGPT. Was ik aan het tikken, enter, en dan tikte ik gewoon door. Nu geef ik even de IDE een tel, pauze. Dan komt hij met een voorstel. En mijn ervaring is, zelfs met de simpelste modellen, doet hij de helft op goed. Dus heel vaak weet hij wel, dat heb ik nodig. Het scheelt me gewoon heel veel tikwerk. Dus ik wacht een tel en ik win tien tellen. Want ik maak natuurlijk nog tik fouten, ik ben een mens. En ja, dus het AI gewoon maar laten genereren, heeft meestal minder fouten, is sowieso tik fouten dan ik ze maak. En die seconde, geeft die ook tijd om extra na te denken? Ja, doe ik dat ook? Goeie vraag, goeie vraag. Ja, misschien wel, weet ik niet. Ik denk dat mijn brein nooit stil staat eigenlijk. Ik weet niet hoe jullie brein werken, maar die van mij gaat altijd maar door, maar door, maar door. Nou, wat ik bij mezelf merk is, ik begin meestal met het commentaar. Ja, heel goed. En net als jij, dus er zit een mate van vertraging in, en dat zou dezelfde mate van vertraging zijn als de ChatGPT, dat als je het nog eens doorleest, dus ik heb eigenlijk even de tijd om nog een keer door te lezen, ik denk, oh, maar hier kan ik eigenlijk misschien nog iets specifieker zijn. Ja, ik weet niet of ik dat ook heb. Wat ik wel interessant vind wat je zegt, als je commentaar tikt, dan heeft de AI meestal voldoende informatie om aan de slag te gaan. Ja. Het stuurt hem gewoon, hè. Ik neem aan dat je af en toe programmeert. Ja, zeker. Dus als je commentaar intikt, ja, dan weet hij de volgende regel, moet daar iets mee te maken hebben. Dus dat is een geweldig input. Ja. En commentaar is dan neem ik aan de commentaar van wat voor code wil ik gaan creëren, zodat we applicaties maken voor de luisteraars die niet zoveel in de softwareontwikkeling zitten. Dus daar definiëren we eigenlijk wat het programma moet gaan doen. En dat zetten we in de commentaar, een pseudo code, oftewel vertellen wat de code zou moeten gaan doen. En eigenlijk filter aan je erin. Ik was nog wel nieuwsgierig, maar dat heeft jouw werkproces aangepast. Maar ik neem aan dat je niet de enige bent die het gebruikt, dat je collega's hebt, organisaties die het gebruiken. Bedoel je nu de tool die ik ontwikkeld heb? Ja, de tool. Nee, dat is allemaal nog in beginfase. Oké. Wat ik heel graag, het is een beetje hobby. Dus wat ik heel graag wil is er iets blijvends van maken. Maar goed, uiteindelijk, eigenlijk heb ik twee doelen. Mijn persoonlijke doel is er een plugin van te maken, dus voor mijn ontwikkelomgeving. En wat ik dan voor me zie is, ik schrijf mijn implementatie, rechterknop, genereer de oplossing. Ik ga een kop koffie drinken en ik kom terug. En het is klaar, fantastisch. Maar goed, eigenlijk zou het niet een aparte plugin moeten zijn. Tegenwoordig hebben we allerlei AI-tools die rechtstreeks draaien in onze ontwikkelomgeving. Het moet daar onderdeel van worden. Dus het moet onderdeel worden van GitHub Copilot of van JetBrains AI-system. Eén kleine detail daarover. Er zijn tegenwoordig ook open source plugins voor je op de programmeeromgeving. Bijvoorbeeld Devox Genie, ik weet niet of jullie dat wat zegt. Nee, mij niet. Dus gewoon mensen maken dat en dan kan je gewoon aan het mee ontwikkelen. En ik ken toevallig de maker daarvan. En die wil het heel graag in hebben. Ik kan alleen de vrije tijd niet vinden om het erin te krijgen. Maar ja, het is een kwestie van tijd voor dit soort dingen standaard in je AI-assistens. Ik denk dat dit de toekomst is, want nu hebben we een geautomatiseerde manier om de AI te controleren. Je hebt nu een leerproces gehad dat dit jouw aanpak heeft aangepast. Wat wil je daar bij de mensen meegeven wat ze zelf kunnen aanpassen om hier alvast aan te gaan wennen? Om op deze manier te gaan werken? Het makkelijke antwoord is test-driven development gaan doen. Dus je eerst je testen schrijven, zodat je vervolgens ook een manier hebt om je AI te controleren. Maar er zit nog een stap voor. Want kijk, tot nu toe, ook weer vroeger voor ChatGPT, was het de superkracht om te kunnen programmeren. Was je misschien de held in een organisatie waar je ingehuurd werd? Dat gaat verdwijnen. Of dat wordt in ieder geval minder, laat ik het zo zeggen. Dat wordt minder. En dat vindt niet iedereen even leuk. Weer je de vraag. Is het schrijven van een test programmeren? Wat mij betreft is het een vaste onderdeel van programmeren. Zonder testen gaat er hopelijk niks in productie. Ik denk dus dat de werkzaamheden van een ontwikkelaar gaat veranderen. Dat zien we eigenlijk nu al. We moeten nu leren werken met AI Systems. Want AI is een tool. We hebben een extra tool in onze toolbox. Dus we moeten onze werkwijze aanpassen. Zodat we beter, sneller, efficiënter, mogelijk kunnen leveren. Hetzelfde geldt voor het concept wat ik hier probeer te vertellen. Het programmeren gaat niet weg. Het schrijven van een test is nog steeds programmeren, denk ik. En ik denk ook, weet je, die AI Systems en deze tool, die brengen je tot een bepaald niveau. En ik denk niet dat ze op korte termijn 100% gaan brengen. Dus we zullen altijd mensen nodig hebben voor het laatste stukje. Dus je moet nog steeds, er zijn twee varianten. Of je vertrouwt het helemaal. En je zit helemaal niet in de implementatie. Je vertrouwt die AI. Als we testen draaien, dan heb ik productie, rijpe code. Of je gaat een gulden midden weg. En dan heb je nog steeds mensen nodig die de code begrijpen. Nog even, ik weet niet waarom. Maar dat triggerde wat in mijn brein. Die zei van, deze vraag moet ik toch even stellen. Misschien een beetje in depth. Maar werkende code wil niet per se zijn efficiënte code. Hele goede vraag. Dus hoe zorg je dat dat ook meegenomen wordt in de oplossing die eigenlijk met behulp van AI dan wordt gecreëerd? Ja, dat is vraag recht vaker. Als we voor het gemak even efficiënte code plat slaan naar performante code. Dus code die snel executeert. Behalve unit test heb je ook iets dat heet een performance test. Dus die gaat meten hoe snel de code wordt, de oplossing wordt gegenereerd. Als je een paar van die testen meeneemt in de input naar de tool. Ja, dan gaat hij die meenemen in de testcyclus. En dan valt hij dus als hij niet snel genoeg is. En zo kan je ook, dit kan je breder trekken. Je kan, want code is meer dan, je kan code niet alleen vatten in unit test. Er zijn ook andere aspecten. Maar ik denk dat je eigenlijk al die andere aspecten ook kan platslaan in testen. Misschien een ander soort testen, maar je wilt wel geautomatiseerde testen. Zijn er nou andere skills, vaardigheden die je moet ontwikkelen om goed met AI om te kunnen gaan? Zeker in het vak van software engineer, van programmeur. Goeie vraag weer. Ik denk dat het nog steeds, zolang we nog niet in het tijdperk zitten, dat we de AI alles laten genereren. En we zelf de implementatie niet meer aanraken. Zul je zelf code moeten kunnen lezen. Dus zul je ook gewoon moeten begrijpen wat die doet. Dus ik denk dat de huidige opleidingen zoals we ze nu hebben, die opleiden tot programmeur prima zijn. Want je snapt vervolgens wat eruit de AI komt. Maar even als advocaat van de duivel. Dus ik kan gewoon een stukje code geven. En dan zeg ik tegen zo'n taalmodel, leg me dit even uit. Ja, dat kan. Dus hoeft niet meer te weten wat het doet. Ja, dat klopt. Dat is waar. Maar ik denk dat heel veel kennis en skills van programmeurs komen gewoon door te doen. Je kan mij uitleggen hoe ik moet fietsen. Maar als ik nog nooit gefietst heb, denk ik niet dat het me lukt aan de hand van je uitleg. Dat is typisch iets wat je moet doen. En dat verleer je dan ook niet meer. En ik denk dat hetzelfde geldt voor programmeren. Dus als je dat, voor mij zeggen ze, als je iets 10.000 uur doet, dan kan je het goed. Volgens mij moet je even die 10.000. Even. Je moet door de code through the motions. Zo gaan de beweringen. Je moet wel. Want anders, ja. Als ik iets lees, wat ik nog nooit zelf gedaan heb, dan onthoud ik het heel even. En dan is het weer weg. Ja. Ik vind het wel heel mooi wat je zegt met het fietsen. Als je dat zo uitlegt, dat je niet kan fietsen. Ik kijk heel veel films, maar dat maakt mij geen regisseur. Nee. Er schijnt trouwens zo'n boek te zijn over hoe je moet fietsen. Geschreven door een Engelsman of zo. Oké. Ik heb het niet meer geleerd, kan ik je zeggen. Nee, precies. Dat doe je met vallen en opstanden. Ja, inderdaad. Ik denk dat het voor heel veel skills in het leven geldt. En dus ook voor programmeren. Ja, laten we toch deze analogie nog heel even door volgen. Want waar moet je dan tegen aanstoten? Hoe hard moet je vallen om toch nieuwe vaardigheden? Want ik geloof niet, zeg maar, dat je met de... Als we gewoon door blijven doen, zoals je nu doet met je softwareontwikkeling, dat je dan toekomstbestendig bent. Dus er moet een verandering gaan plaatsvinden. Waar moet je je tegen aan gaan stoten? Ook als je misschien wat lichte weerstand hebt tegen het ontwikkelen met AI. Om uiteindelijk dat te overwinnen. Dat je zegt van, ja, maar ik moet deze stap gewoon maken. Dit triggert een aantal dingen bij mij. Ik zei net al, je moet leren werken met die nieuwe tools die we hebben. Want anders word je ingehaald door mensen die ze wel gebruiken. Dat is voor mij een gevleugelde uitspraak. Je wordt niet vervangen door AI, maar je wordt vervangen door iemand die AI gebruikt. Daar geloof ik heilig in. Het tweede wat het triggerde was... Maar dit is nog heel erg extern, heel erg extern gedreven. Dan doe je het eigenlijk voor een ander. Maar waarom zou je het voor jezelf moeten doen? Ik denk dat de meeste ontwikkelaars vinden alle nieuwe shiny tools interessant. Dus je gaat bijna vanzelf. Maar waarom zou je het moeten willen? Nou ja, de wereld verandert. Ik denk als jij niet mee verandert. Zeker in de softwareontwikkeling, alles gaat super snel. Ik denk dat je op een bepaald moment wordt je obsolite. Even terug naar de... Wat kan je niet leren door iets te lezen? In de softwareontwikkeling, ik denk als je het tien jaar gedaan hebt of zo, dan heb je echt wel een idee van dit gaat de goede kant op. Of je ziet code. En dan kan je al zeggen van, dit is volgens mij niet de manier hoe het moet. Ik gaf net het voorbeeld van text-extraheerder-text. Ik weet gewoon, de manier die ik had gekozen was makkelijk en vies. Het was even snel, ik had even iets nodig. Ik weet, dit kan beter, dit moet beter. En als je dat gevoel hebt, dat krijg je dus niet door alleen maar AI. Je zult ergens nog steeds je knieën moeten vallen. Ja, ervaring op doen. Ja, dat denk ik ook. Mooi. Ik weet niet of ik je vraag heb, ander. Het was ook een lange vraag. Ja, en ik wil nog een kleine aanvulling. Als het goed is zijn we als consultant, als iemand die software schrijft of ontwerpt, van nature lui. Ik denk dat mens van nature lui is en dat we dus efficiëntie nodig gaan hebben om het onszelf makkelijker te gaan maken. Ja, ik weet niet of we van nature lui zijn. Ik denk dat programmeurs vooral graag willen automatiseren. We hebben een hekel aan herhalende, repetieve werkzaamheden. Ik denk dat het het juiste soort lui is. Ik vind alleen lui een eng woord. Daarom zeg ik het ook. Om even wat te prikkelen inderdaad. Want inderdaad de goede manier van luiheid. Dus dat is denk ik de mooie verwoording inderdaad. Maar wat zijn valkuilen waar je zelf tegenaan bent gelopen? Met die ervaring die je nu opgedaan hebt. Wauw, die vraag heb ik nog nooit gehad. Wat zijn valkuilen waar ik tegenaan ben gelopen? Ik heb helaas geen goed antwoord op. Ik denk dat we moeten de grenzen van dit concept, dit idee, moeten we nog gaan bereiken. En die zijn er vast. Maar goed, elke week komen er nieuwe modellen uit. Elke week worden ze goedkoper. Elke week worden ze sneller. Ik denk dat die modellen zich sneller ontwikkelen dan ik. Dat weet ik eigenlijk wel zeker. Ik heb misschien daar wel zelf een persoonlijk antwoord op. Is dat zeker in het begin. Met het programmeren. Met ook het schrijven van testen. Eventueel zelfs functionele testen. Dat op het moment dat de AI met de dingen terugkwam. Dat ik dacht dat ding doet het niet goed. En de valkuil was dus dat ik niet reflecteerde op wat ik zelf gaf. Wat ik zelf schreef. Dat dat eigenlijk ambigu, tweeledig was. Dus hoe specifieker je uiteindelijk bent. Hoe duidelijker, hoe makkelijker het taalmodel jou kan begrijpen. Dus ben ik in mijn hoofd gaan schakelen van als ik niet een goed antwoord krijg. Wat moet ik dan aanpassen aan de vraag die ik stel. Ik herken dit. Dit heb ik inderdaad ook. Dus een super mooi voorbeeld. Dus als ik de tool gebruik. En er komen dus niet de code uit die ik verwacht. Dan heb ik dus niet de juiste testen. En meestal niet voldoende testen geschreven. Maar goed, ik herken het ook uit mijn tijd. Voordat deze tool er was. En dus dat ik AI-assisters gebruikte. Hoe specifieker je bent, hoe beter het antwoord. Dat is echt wel. Hoe meer input die heeft, hoe beter het antwoord eruit komt. Dat heb ik ook geleerd. Ja, en er wordt natuurlijk heel veel gezegd. Dus het lijkt een dooddoener. Maar het gaat mij er eigenlijk dan ook om. Dat je dan zelf eigenlijk gaat nadenken. Van wat moet ik anders doen. Ja, dus wat voor collega heb ik tegenover me. En dan collega in de zin van AI-collega. Waar is die goed in? Wat kan die wel? En hoe moet ik eigenlijk de juiste vraag stellen. Om het resultaat te beantwoorden. En wat hier aan raakt. Eén van de moeilijkste dingen denk ik in softwareontwikkeling. Is weten wat je wil. Elke consultant kent dit verhaal. Je hebt klanten die willen iets. Maar klanten weten meestal niet wat je wil. En dat is heel normaal. Ook als ik zelf iets wil. Ik begin aan iets. En gedurende het traject verandert wat ik wil. Het is heel normaal om niet gelijk te weten wat je wil. En dat maakt ook zeg maar dat we niet echt bang hoeven te zijn. Dat voorlopig AI onze taak overnemen. Want daarom moet je weten wat je wil namelijk. Als we dan toch even de toekomst in kijken. Wat zie je dan veranderen in die rol van de professional? Weten wat je wil. Maar nog andere veranderingen? Ja die vraag stelde jij ook al. Dit is een andere bewoording. Dus de vraag is wat gaat veranderen in de rol van een professioneel softwareontwikkeling? Ja. Ik kom, sorry. Ik kom jullie keer terug op hetzelfde antwoord. En dat is gebruik maken van de nieuwe tools die er zijn. Leer de AI gebruiken. Het is een nieuwe tool in je toolbox. En ga ermee spelen. Zorg dat je weet wat die kan. Maar weet ook wat die niet kan. Het is zeker nog niet perfect. En ik twijfel ook of we binnen 10 jaar een perfecte AI gaan krijgen. Ik hoorde laatst ook een mooie. En dat is ook zo eentje die rondgaat. Dit zijn op dit moment ook de slechtste modellen. Waar je tot nu toe mee gewerkt hebt. Dus in die zin het wordt ook gewoon nog beter. Ja. Dus de grote vraag voor mij is. Gaat dit plateauen? En waar gaat het dan plateauen? Want ik denk niet dat we binnen nu en 10 jaar. Dat noemen ze geloof ik AGI. Dus echt een computer hebben die net zo slim is als wij. Ik denk dat er nog wel een paar plateautjes tussen komen. De vraag is waar gaat het plateau. En ik lees ook wel signalen. De informatie is op. De internet is op. Ja. En dus AI's worden nu getraind op data gegenereerd door AI. Dus we gaan nu een soort van negatief spiraal naar beneden. Misschien zitten we nu op de hoogtepunt. Ik weet het niet. Dat zou ook nog kunnen. Ja. Wordt dan niet juist het goed kunnen schrijven van code van essentieel belang om de toekomstige plateaus aan te kunnen? Ja. Nou ja. Ik geloof wel in het labelen van wat is door mensen gemaakt en wat is door AI's gemaakt. Maar goed. Ja. Ik denk dat het te makkelijk om een zeilen is. Maar er zit iets in die hoek. Ik denk dat iedereen snapt als je AI voert met dingetjes van AI. Daar zijn ook echt experimenten mee gedaan. Dan zie je het gewoon rap tempo omlaag gaan. Dus ergens zullen we moeten kunnen aangeven. Dit is kwalitatief goede input. En dit is kwalitatief slechte input. Ik weet nog niet hoe we dat doen. Nee. Nou ja. Datakwaliteit is altijd een uitdaging. Het zit al een hele werkzaam leven in de data. En dat blijft altijd de crux. Wat is goede kwaliteit van de data om inderdaad mee aan de slag te gaan? Ja. We zitten hier live natuurlijk bij AI Community Day in Utrecht. Zoals Joop al zei. We hebben ook vragen vanuit het publiek. Dus ik wil de eerste vraag graag aan je voorleggen. De vraag komt van Willem Meins. Dankjewel. Chief AI Architect bij Aigency. En zijn vraag luidt. Je had het over tests als specificaties. Hoe kijk je tegen specification by example met feature files aan? En dan ook graag nog even toelichten voor de luisteraars die misschien wat minder bekend zijn met de materie. Ik moet zelfs toegeven dat ik minder bekend ben met de materie. Maar ik kan een aanname doen. Dus ik zal mijn aanname uitspreken en dan hebben we gelijk een uitlegging. Dan gaan we kijken of het klopt. Feature tests. Feature files. En het gaat om het stukje specification by example. Ja. Dus ik denk dat specification by example, dat lijkt heel erg op wat ik doe. Dus ik maak testen, die geef ik aan AI en ik vraag om implementatie. Dus daar geloof ik wel in. Alleen je moet wel voldoende voorbeelden hebben. Als je niet voldoende voorbeelden hebt, dan krijg je een te generieke oplossing die dus niet goed genoeg is. Maar aan de andere kant, als je te veel voor wil hebben, dan krijg je iets dat heet overfitting. Dan krijg je dus een antwoord dat te specifiek is gemaakt op jou. Dus je wil altijd een soort dat midden van bereiken. Ik twijfel of ik de vraag heb aan de antwoord. Een specification by example is een techniek waarbij je op een gestructureerde manier, die ken je misschien wel, de given when then, dus gegeven, het volgende, als dit gebeurt, dan verwacht ik deze uitkomst. En daar kun je als gevallen, kun je daar examples, voorbeelden, ik moet ze ook zelf naar een Nederlandse woord zoeken, voorbeelden aangeven, dat zijn die randgevallen waar je het over had, die geef je eigenlijk meteen mee. Ja, ik ken dit als BDD. Ja, precies. Ja, dat zit allemaal in diezelfde hoek. Ja, ja. En wat was de exacte vraag nu? Sorry. Pak je de kaart er even mee. Je had het over tests als specificaties. Hoe kijk je tegen specification by example aan het featurefase? Ja, dus deze testen zijn volgens mij ook runbaar. Ja. Nou ja, dan kan je het gebruiken. Dus dan heb je weer dezelfde feedback loop. Dus je geeft deze testen, dit soort testen geef je aan AI. Je vraagt om implementatie. Vervolgens run je deze testen. Het principe werkt ook. Klinkt mooi. Zeker. We hebben ook een vast onderdeel in de show, zeg maar. En dat gaat er over van, ja, als je nou een systeem, een AI systeem zou mogen bedenken. Die helemaal vrij is van techniek, van beperkingen, wat dat zou kunnen zijn. En om je eventjes wat denktijd te geven, hebben we daarvoor een jingle. Ik heb twee voorbeelden. Moet het software zijn? Nee hoor, nee. Het is helemaal vrij. Ja, dan zou ik heel graag een robot in mijn huis willen die alle irritante klusjes doet. Ja. Maar goed. Ik ook. Ik denk dat dat nog redelijk ver weg is. Nou ja, nee, goed. Nou ja, we gaan meemaken, hoop ik. Het tweede is, als je alleen maar over software hebt. Ik zou heel graag software hebben zoals we in science fiction films hebben. Zodat ik gewoon zeg, hé, doe dit. En dan komt hij met een antwoord en zegt, nee, ik bedoelde dat. En ik denk dat we daar steeds dichterbij komen. We zijn hem nog niet, maar het zou wel mooi zijn als we dat ergens in de komende tien jaar zouden bereiken. Nou, dat klinkt heel fijn. Allebei zeg ik ja graag op. Welk probleem zou dat oplossen? Nou ja, dus een heel simpel voorbeeld. Ik zoek een mailtje. Ik weet dat het ongeveer drie weken geleden is. Ik weet dat die persoon hem gemaild heeft. En ik weet dat dit woord erin zit. Dat ga ik zoeken. Ja, en dan ben ik, als ik geluk heb, vind ik het binnen tientallen. Maar als ik pech heb, ben ik minuut aan het zoeken. En dan heb ik dat mailtje. Maar dat had ik natuurlijk nodig voor een andere vraag. En zo schakel ik allemaal informatie aan elkaar in mijn hoofd. En voor je het weet ben je tien minuten tot uren bezig. Als je dat een AI kan laten doen, dan lijkt het me echt fantastisch. Ja, en die is waarschijnlijk nog vele malen snel weer even erin te zoeken. Maar inderdaad, nu zijn we aan het chainen van al die activiteiten om te komen tot het doel dat we willen bereiken. En eigenlijk willen we die chain, als ik je zo zeg, eigenlijk weghalen. En eigenlijk van A naar Z. Ja, heel simpel. Dus ik zat vanochtend, hier moet ik om drie uur een podcast opnemen. Hoe laat moet ik dan vertrekken? Hou rekening met de files. Nou, dan kan ik normaal gesproken kijken op Google Maps. Maar goed, ik moet eerst weten waar ik moest zijn. Dat was de fabriek. Dan tik ik de fabriek in. Zou die de goede fabriek hebben gepakt? Allemaal van dat soort dingen. Ja, ik vind dat echt heel erg fijn. Als je dat soort problemen voor mij kan oplossen. En dit zijn maar kleintjes. En als je dat helemaal kan, dan kan je langzaam grotere problemen oplossen. Tot aan wereldvrede. Wereldvrede. Oh. Nee, dat was een grapje. Maar goed, klein beginnen en langzaam uitbreiden. Mooie antwoord. Ja, zeker. Wat zouden nou drie mogelijke tips zijn voor luisteraars die nu luisteren en die zeggen van ik sta eigenlijk op het punt om te beginnen met het gebruik van AI, AI bij programmeren. Wat zouden jou drie tips zijn die je aan jezelf had willen geven voordat je hiermee begon? Even nadenken hoor. De eerste die gaf jij net eigenlijk al. Wees specifiek in wat je wil. Hoe specifieker jij bent richting de AI, hoe duidelijk die weet wat jij wil, hoe beter zijn antwoord zal zijn. Dat is echt wel een dingetje. Ik geloof het ook nooit zo in prompt engineering. Maar ik geloof nu hoe geavanceerder het model, hoe groter het model, hoe beter het werkt. Dus met een lokaal model hoef je daar niet je best voor te doen. Maar voor de grotere cloud modellen heeft dat echt wel zin. Dat is eigenlijk meer van hetzelfde. Wees specifiek. Maak je niet zoveel zorgen voor de kosten? Oeh. Bij bands toelichten? Ja, die kan ik zeker toelichten. Dus toen ik begon dacht ik, oh, APIs, prijzen, dat gaat een hoop geld kosten. Ik heb in het afgelopen jaar minder dan 11 euro verstookt. Dat was niet veel. Nee, terwijl ik van tevoren dacht, oh, moet ik dit wel doen? Gevaarlijk. Nou, er zitten allemaal limieten op. Dus je kan er gewoon een tientje op zetten. En daar heb ik eigenlijk bijna een heel jaar mee kunnen spelen. Daarnaast, geloof ik ook echt, maar goed, het is misschien iets hoger niveau dan voor mensen. Het duurste onderdeel van een software project zijn de uren gemaakt door programmeurs. Veruit. Dus elk uur dat je daar kan besparen, leeft gewoon geld op. Dus de kosten van een AI, wat is het duurste abonnement tegenwoordig? Volgens mij is dat twee uurtjes software schrijven. Ja. Dus ja, volgens mij is dat een no-brainer. Die twee uur heb je er zo uit. Dus ja, maak je niet te veel zorgen over de kosten. Mooi. Mooi punt. Maar ik moest eigenlijk drie. Derde. Ja. Zelfs wel heel specifiek, die drie. Ja, ja. Laten we bij twee jaar. Anders krijgen we die ongemakkelijke lange stilte zien in de podcast. Nou, volgens mij... Oh ja, we hebben ook nog stellingen. Ja. Want rondom AI, dat zul je misschien wel herkennen. Je werkt ook voor grote organisaties waar je komt. Dan hebben we natuurlijk ook altijd te maken met AI-beleid. Hoe ga je hiermee om? Zeker ook voor mag je deze tooling inzetten, ja of nee? En Niels en ik hebben een kaartspel ontworpen, waarin best wel een hele hoop van dit soort vraagstukken zitten. Met het idee, met een stelling die je met elkaar bediscussieert. Dus er is geen goed of fout. Maar we zijn wel benieuwd als we een stelling aan jou voorleggen. Kom maar op. Even voordat je de vraag stelt, we hadden een coole jingle. Dankjewel. Wel AI-gegenereerd. Ah, wauw. Ook zelfs dat kan AI. Zeker. En daar gaan wij niet zingen, Joop. De categorie is ethiek en maatschappij. En de stelling luidt. Het klonen van mijn stem is voor mij persoonlijk acceptabel. Wauw. Ik heb geen moeite met het klonen van stemmen als degene waarvan de stem is toestemming geeft. Maar goed, dat wordt het snel grijs. Dus ik kan me heel goed voorstellen dat je... En stel dat we, volgens mij kan je tegenwoordig ook podcast maken op basis met AI. Ja. Dan neem je onze drie stemmen en dan stop je er wat input in. En ja, had ik toch niet naar Utrecht hoeven komen. Maar ja, ik denk dat het prima is als, zoals ik al zei, als de persoon waarvan de stem is toestemming geeft. Maar dat dat ook alleen daarvoor wordt gebruikt. En daar wordt het snel eng, vind ik altijd. Dat is ook een beetje, als je AI gebruikt, waar gaat die data allemaal heen? Dat vind ik echt heel spannend. Dus ik zou... Mijn eerste antwoord is ja, het mag. Mijn tweede antwoord is alleen als ik het bedrijf vertrouw die er wat mee doet. Oké, mooi. Ik ben wel heel nieuwsgierig. Je bent ook spreker. Dus je gaat ook de wereld over om sessies te geven. Zou je het zelf toestaan dat ze jouw stem gebruiken voor een sessie op het onderwerp waar je zelf ook actief in bent? Of ga je dan toch liever zelf? Nee, ik ga het liever zelf. Dat is toch heerlijk om... Ja, ik vind het heerlijk. Conferenties vind ik hier een beetje... Dat is misschien een beetje gek, maar een beetje ontsnappen uit de normale dagelijkse werkzaamheden. Dus ik vind het heerlijk om naar conferenties te gaan. Zeker als het ergens in het buitenland is. En op het moment dat ik woon in een klein plaats, als ik in de bus stap, dan begint voor mij een soort van vakantiegevoel. Dan moet ik erbij vertellen, ik heb kinderen, een gezin, een druk thuis. Even de druk thuis. Even doen wat ik zelf zit in. Ja, en wat mij dan helpt als ik naar de conferentie ga, is de rust en de tijd om even over zaken na te denken waar je dagelijks niet aan toekomt, of niet altijd aan toekomt, en die tijd te pakken en te netwerken. Het is niet het onderwerp van de podcast, maar de conferenties hebben zin omdat je mensen... Het is fysieke conferenties. Ja. Virtuele vind ik heel moeilijk. En ik hoop dat wij het publiek ook een reden hebben gegeven om na te denken. Dus heel erg bedankt, Bouke, dat je dit wilde komen doen bij ons hier live op het podium. Ja, zelf ook weer een aantal dingen geleerd hebt. Dus testdriven, net zolang de AI laten fouten laten oplossen, net zolang dat je test slaagt, omdat je de test vertrouwt, zou die als het ware in productie kunnen. Toch? Eens. En ook dank jullie wel voor het feit dat ik hier mocht zijn. Dank je wel. Oh ja, die nemen we even op de wee op. Dank jullie wel. Dank jullie wel dat jullie in het publiek wilden zitten. Ons ook wilden steunen hierin. Dank voor de vragen. Je kan ons vinden via Spotify, Apple Podcast, eigenlijk al je favoriete podcast app. Dus als je je daarop abonneert, komt deze aflevering vanzelf tevoorschijn. Dankjewel, tot de volgende keer. [Muziek]