Twee derde van de Nederlandse IT-organisaties kan achteraf niet reconstrueren wat een AI-coding agent precies heeft gedaan, blijkt uit onderzoek onder 330 IT-beslissers. Het probleem is niet dat mensen de risico's niet zien, maar dat ze die risico's afdekken met beleid in plaats van technische maatregelen, terwijl een taalmodel je beleidsdocument niet leest.
De oplossing is een coding harnas: een ontwikkelomgeving waarin architectuurprincipes, security-regels en testen technisch zijn afgedwongen in plaats van opgeschreven. Daarmee verschuift de vraag van "heeft de agent zich aan de regels gehouden" naar "staan de goede regels in ons harnas".
Morgen kun je beginnen met één vraag aan bestuur, architecten en teamleden afzonderlijk: waarop baseer jij je oordeel dat het goed gaat met coding agents in onze ontwikkelstraat? Het verschil tussen die antwoorden is je agenda voor de komende maanden.
Hoi, welkom weer bij de korte aflevering van AIToday Live. Ik ben Joop Snijder, Head of AI bij Info Support. Ik heb vandaag denk ik echt wel een gave aflevering. Want ik begin vandaag met een vraag waarop ik geen definitief antwoord heb. En dat is precies waarom hij denk ik juist de moeite waard is. Stel, je zit in een organisatie waar AI-agents meebouwen aan software. Dat je met coding agents zoals Claude Copilot, GitHub Copilot, dat je software bouwt. De directeur zegt we hebben dit onder controle, we kunnen opschalen. Maar de architect, de beïnvloeders op de werkvloer zeggen we hebben dit niet onder controle. Ik wil dat er bij elke actie iemand meekijkt. Wie van de twee heeft dan gelijk. Ik kan die vraag stellen omdat we hem hebben gemeten. Ik heb namelijk aan het onderzoek van Info Support meegewerkt, het Agentic Engineering-onderzoek uitgevoerd in opdracht van Info Support onder 330 Nederlandse IT-beslissers. Voordat ik de uitkomst geef iets over waarom dit onderzoek bestaat. De cijfers in dit vakgebied die rondgaan, komen bijna allemaal uit twee hoeken. Namelijk Amerikaanse leveranciersrapporten over hun eigen tooling en academisch werk waarin individuele ontwikkelaars in een laboratorium of in open source-projecten worden gevolgd. Beide zijn natuurlijk hartstikke nuttig. Maar beide meten iets anders dan wat een Nederlandse organisatie nodig heeft om een besluit te nemen. Wat wij hebben gemeten, is juist dat besluitsvormingsniveau. Dus niet hoe snel typt een developer, wel hoe is toezicht geregeld, waar ligt eigenaarschap. Wat is er formeel verankerd? En hoe denken bestuur en werkvloer over hoe klaar de organisatie is. En dat in een markt waarin de AVG en de AI Act juist dagelijks praktijk is, waarin veel maatwerksoftware wordt gebouwd bij overheid, zorg, finance, logistiek, noem maar op. En waarin het gesprek over digitale soevereiniteit scherper wordt gevoerd dan in de meeste landen. Die combinatie die bestond nog niet. Daarom is denk ik dit onderzoek zo'n moeite waard. Kijk, wat ik niet ga doen is je helemaal vol gooien met allerlei percentages. Als je die exact wil nalezen. De link naar het rapport staat in de shownotes. En je kan hem gewoon gratis lezen. Je hoeft ook helemaal niets achter te laten. Je kan het gewoon meteen lezen op die link. Dan de metingen waar mijn openingsvraag over gaat. Van de hoofdbeslissers vindt ongeveer een kwart namelijk dat elke AI-actie menselijke controle vereist. Maar van de adviseurs met invloed op IT-beleid vindt ongeveer de helft dat. Het is het dubbele. En dat is geen meningsverschil over smaak. Dat is een verschil over hoeveel ruimte uiteindelijk zo'n coding agent krijgt, welke controles nodig zijn en hoe snel je kunt opschalen. Dus twee mensen in dezelfde organisatie kijken naar dezelfde situatie en zien iets anders. En loopt dat er ver uit één. Dan geeft een organisatie coding agents meer ruimte dan haar processen, security en misschien zelfs kwaliteitscontroles aankunnen. Nu de vraag dan zelf: wie heeft het dan gelijk. Kijk je naar de rest van het onderzoek, dan blijkt dat wel de verkeerde vraag. Want geen van beide meet namelijk iets, ze schatten allebei. Neem het toezicht. Actief toezicht op coding agents, als logging, audits, duidelijke rolverdeling, vindt bij ongeveer een derde van de organisaties plaats. Dus dat betekent dat twee derde achteraf niet kan reconstrueren wat een agent van een coding agent precies heeft gedaan op basis waarvan. In die twee derde is het oordeel van de directeur een indruk. Het oordeel van een architect of een developer, dus ook. Alleen komen ze via een andere route tot die indruk. De een misschien via een rapportage, de ander via een enorme review stapel aan code op zijn bureau. Dat verklaart waarom het verschil zo groot is. Zonder gedeelde meting wint niet het beste argument, maar de positie waar je zit. Het tweede patroon uit het onderzoek maakt nog iets duidelijker. Namelijk vrijwel iedere IT-beslisser die ziet risico's. De groep die zegt geen enkele belemmering te zien, is verwaarloosbaar klein. De zorgen liggen best wel dicht bij elkaar. Gevoelige bedrijfsdata die bij externe AI-providers belandt bijvoorbeeld, of twijfel over de kwaliteit van AI-gegenereerde code. Of de vraag of toepassingen voldoen aan die AVG of AI Act en sectorspecifieke eisen. Maar ook gebrek aan observability. Dus kunnen zien, observeren wat een AI-agent doet of gedaan heeft. En agent security. Dus het risico dat een autonome agent onbedoeld of schadelijke acties uitvoert op interne systemen. En let op hoe precies deze lijst eigenlijk is. Want wie zo scherp kan benoemen wat er mis kan gaan, weet dus waar de gevaren zitten. Het ontbreekt de Nederlandse organisaties dus niet aan inzicht in de risico's van de coding agents. Kijk vervolgens naar wat ze er tegen doen en dan wordt het gat zichtbaar. Want wat het vaakst wordt ingericht, zijn namelijk afspraken. Beleid en data-uitwisseling met AI-tools, goedkeuringsprocessen rondom nieuwe tools. Maar wat achterblijft, zijn juist de maatregelen die iets echt afdwingen. Dus logging, monitoring, een afgeschermde sandbox, waarin een coding agent kan werken zonder productiesystemen te bereiken. Precies de maatregelen die de genoemde risico's zouden ondervangen. En organisaties beheerst dus AI vooral op papier. En het taalmodel, lees je beleidsdocument niet. Misschien als je hem meegeven, maar dat wil niet zeggen dat hij zich daar dan ook daadwerkelijk aan houdt. Hetzelfde zie je in de trechter van adoptie naar volwassenheid. Dus ruim acht op de tien organisaties zetten AI in tijdens het ontwikkelproces. Kijk je naar wie het werkelijk heeft geïntegreerd in de engineeringpraktijk. Dan blijft echt een hele kleine minderheid over. En bij minder dan één op de tien is AI-governance formeel verankerd met verantwoordelijkheden en een roadmap. Dus ja, adoptie is makkelijk. Beheersing is toch echt wel een heel stuk moeilijker. Je zou dit kunnen wegzetten als een soort van Nederlandse eigenaardigheid. Maar dat is het niet. Daarvoor moet ik wel even kort buiten ons onderzoek stappen. Er bestaat namelijk academisch werk dat het mechanisme achter deze kloof laat zien. alleen dan op individueel niveau. Een studie van Stanford bijvoorbeeld, die liet deelnemers beveiligingsgevoelige programmeeropdrachten maken met en zonder AI-coding agents. De groep met die agents, schreef minder veilige code, maar dacht tegelijkertijd veilige code te hebben geschreven. Beetje apart natuurlijk, toch. En een ander experiment van METR, die liet ervaren ontwikkelaars aan echte taken werken in hun eigen codebases. Gemeten waren ze achteraf met AI langzamer. Maar achteraf dachten ze dus dat ze sneller waren geweest. En die studies gaan dan uiteindelijk over één developer aan één taak. Wat wij meten is de laag daarboven met ons onderzoek. Dus hoe een organisatie zichzelf beoordeelt en welke controles ze inricht. Dat de overschatting op beide niveaus terugkomt maakt hem wel aannemelijker. Maar goed, je zou nu kunnen concluderen dat de architect wint en dat alles langs de mens zou moeten. Maar ik denk dat dat niet werkt. Het onderzoek van ons laat ook zien dat AI vandaag vooral het coderen, programmeren, code review en het testen versnelt. Het knelpunt verplaatst zich daarmee naar juist requirements, architectuur. en aan de andere kant deployment en beheer. Dus menselijke review is precies de plek waar dan uiteindelijk de file ontstaat. Dus meer handmatige controle betekent dan meer stapels en minder aandacht per stuk binnen zo'n stapel. Dus de vraag is niet hoeveel controle je uitoefent, maar of je controle meetbaar uiteindelijk is. Menselijke goedkeuring die niemand kan reconstrueren, is uiteindelijk ook helemaal geen controle. Een geautomatiseerde test die faalt, je achteraf ook kan zien. Die is dat wel. En wat helpt dan? Wat helpt, is een zogenaamde AI coding harness. De naam is niet toevallig gekozen. Een harnas, fysiek harnas beschermt en beperkt bewegingsvrijheid tegelijkertijd. En zo werkt het hier ook. Het is de ontwikkelomgeving, waarin dan architectuurprincipes, specificaties, testen, security regels en feedback loops zijn vastgelegd. Maar ook technisch worden afgedwongen. Wat zit daar dan in. Bijvoorbeeld een agent die krijgt toegang tot alleen de codebase die voor zijn taak nodig is, zodat de fout aan de ene kant van je landschap niet aan de andere kant schade aanricht. Er staan testen klaar die de coding agent zelf kan draaien, waardoor hij zijn eigen werk afkeurt voordat er een mens überhaupt tijd in steekt. Iets technisch uit, dus linters en type checkers fout in stijl en structuur. en die geven de agent een signaal terug in laten zeggen. Dezelfde seconde nog. En in plaats van dat een reviewer dit drie dagen later opmerkt, krijgt de coding agent dat terug en kan die ook direct de problemen oppakken. Zo zijn er nog heel veel meer dingen die je kan regelen. Het hele idee is zo'n coding agent die moet voldoen aan de regels die opgesteld zijn. De omgeving corrigeert steeds de agent voortdurend. In plaats van dat de mens achteraf moet uitzoeken wat er is gebeurd. En de agent weet wanneer hij moet stoppen en iemand moet inschakelen. Dus hier zit ook het antwoord op de discussie over human-in-the-loop. Het idee dat er bij elke stap een mens moet meekijken. Dat klinkt misschien zorgvuldig. Maar het is wel behoorlijk uitputtend. Dus iemand die regel voor regel nakijkt of de agent binnen de stappen is gebleven, doet werk waar hij na een uur niet meer scherp bij blijft. Ik vind trouwens een uur nog steeds lang. Maar goed, je gaat het principe. En zo'n harnas, die verplaatst die controle. En wat in de omgeving is afgedwongen, hoeft niemand meer te controleren. Want de agent kon niet anders. Buiten zijn codebase komen, kan niet. Langs de testen komen, kan niet. De vraag verschuift daarmee van heeft deze agent zich aan de regels gehouden, naar staan de goede regels in ons harnas. Dat is een vraag waar je vak mensen wel scherp bij blijven, waar ze het verschil maken. Daar blijft de mens, de human echt in de loop. Alleen dus op een andere plek. Dus bij het inrichten van de kaders en bij de beslissingen die er echt inhoudelijk toe doen, in plaats van narekenen en nakijken van details. Één nuance van de collega van mij, Frank Thiele, die kan je dan ook teruglezen in het onderzoek. Er bestaat geen universeel harnas. Dus een interne medewerkers app vraagt om andere kaders dan een systeem dat energie-infrastructuur aanstuurt. Mijn verwachting is dat zo'n harnas net zo vanzelfsprekend wordt als geautomatiseerd bouwen en het uitleveren nu is. In mijn eigen boek Doeltreffend met AI-agents, schrijf ik dat we bij traditionele software vastleggen wat een applicatie moet doen en dat het bij agents zo belangrijk is vast te leggen wat een agent niet mag doen en wanneer hij moet stoppen. En dat is exact wat zo'n harnas afdwingt. Het beveiligingshoofdstuk voegt trouwens nog toe, dat je minimale rechten die tijdelijk en taakgebonden zijn, dat je een menselijke eigenaar per agent hebt en logging waaruit blijkt wat er is geraadpleegd en besloten. Ons onderzoek draagt de titel Sneller bouwen vraagt om sterker vakmanschap. En dat is geen mooie zin achteraf of zo, dat is echt de uitkomst. En hier komt hij vandaan. De verwachting was namelijk dat AI het vak makkelijker zou maken. Wat we gemeten hebben, wijst juist de andere kant op. Kijk waar de agent het werk overneemt, het schrijven van code, het draaien van testen, het eerst nakijken. Dat is het deel dat je leert, namelijk in je eerste jaren. Wat overblijft, is het deel dat je in tien jaar leert. Bepalen wat er gebouwd moet worden, beoordelen of een architectuur over vijf jaar nog houdbaar is, zien dat een oplossing werkt en toch niet deugt. En dat harnas maakt dat scherper. Iemand moet bepalen welke regels erin komen, wat een goede test is, waar de grens ligt tussen wat een coding agent zelf mag en wat niet. Dat kun je alleen als je weet hoe goede software eruitziet. Een organisatie zonder dat oordeel bouwt een harnas dat de verkeerde dingen afdwingt, en merkt dat pas zodra het misgaat. Daar komt bij wat ik eerder noemde over hoe overtuigend het werk van een coding agent eruit ziet. Dus beoordelen wordt daarmee moeilijker dan dat het was en echt niet makkelijker. Wie de fout niet herkent, keurt hem uiteindelijk dan wel goed. Dan het knelpunt. Ik zei al dat het verschuift naar requirements, architectuur aan de voorkant, deployment en beheer aan de achterkant. Dat zijn precies de plekken waar ervaring het verschil maakt en waar geen tool het van je overneemt. Sneller bouwen legt dus meer gewicht op minder mensen en op de zwaarste oordelen in het vak juist. Dus daarmee wordt vakmanschap wat mij betreft geen romantisch begrip, echt een investering die je kunt plannen. Dus wie coding agents wil opschalen, schaalt eerst het oordeel op waarmee hij zelf beoordeelt. Genoeg diagnose, wat mij betreft. De vraag die je nakrijgt, is natuurlijk: ja, waar begin ik dan morgen maandag. Ik zie drie fasen. De eerste is weten waar je staat. Vervang de vraag: gaat het sneller door een cijfer uit je eigen pipeline doorlooptijd, reviewrondes, aantal teruggedraaide releases. Laat daarna bestuur, architecten, teams, onafhankelijk van elkaar dezelfde vragen beantwoorden over volwassenheid en controle. Het verschil tussen die antwoorden is dan je agenda voor de aankomende periode. De tweede fase is het harnas inrichten. Bepaal per applicatie, per dataverzameling, wat via welke route verwerkt mag worden. Want daar volgt uit hoe streng dat harnas moet zijn. Dwing die grenzen vervolgens technisch af in plaats van alleen maar op te schrijven als een soort van beleidsdocument. Zet je ervaren mensen juist op die kaders en niet op het nakijken van allerlei details op de reviewzaken. Het laatste is de stap die het vaakst wordt overgeslagen en de stap waar het staat of valt. De derde fase is van alles leren. Dus ruim een derde van de IT-beslissers zegt dat teams soms successen delen en zelden mislukkingen. Draai dat nou eens om. Want een foutpatroon laat je zien welke regel namelijk in je harnas ontbrak. Wil je die stappen op papier? Dan heb ik ze in ieder geval uitgewerkt voor je tot een checklist met vragen die per fase op tafel horen. De link vind je in de shownotes en op AITodayLive.nl. Ik ben al veel verder en langer bezig dan iedere andere korte aflevering. Even terug naar de openingsvraag. De bestuurder en de engineer hoeven het niet eens te worden over een gevoel. Ze kunnen het eens worden, wat mij betreft, over de meting. En over wat erachter ligt, want het harnas bouwt zichzelf niet. Iemand moet bepalen welke regels erin horen. Dat is echt het zwaarste werk in ons vak geworden. Vandaar de titel van ons onderzoek: sneller bouwen vraagt om sterker vakmanschap. Het volledige onderzoek, de checklist en de overige bronnen vind je in de shownotes. En denk tot slot eens even na over je eigen organisatie. Waarop baseer jij je oordeel dat een coding agent in jouw ontwikkelstraat goed gaat, op een cijfer of op een indruk. Dank je wel voor het luisteren. Iets langere aflevering dan normaal, vergeet niet. AI niet de oplossing voor alles, maar onmisbaar waar het past. Tot de volgende keer.