Optimize Product Development with Teamcenter

Deel 4 van 4, rechtstreeks vanaf de Mendix Community Round Table Meetup in Amersfoort op 2 juni 2026. In de delen 1 tot en met 3 stelden we de vraag wat er nog overblijft voor consultants, of we een AI-agent kunnen vertrouwen om het werk te doen en of het platform nog steeds de juiste keuze is. Dit artikel stelt de commerciële vraag die aan al deze punten ten grondslag ligt: wie heeft zo'n platform eigenlijk nodig?

Een verkoper aan een van de tafels had de Nederlandse IT-directeur van een grote investeringsbank gebeld om hem uit te nodigen voor een evenement. Een vriendelijke man, dus hij kreeg een paar minuten de tijd, en de directeur gebruikte die om uit te leggen waarom het antwoord nee was. "Geen probleem met low-code," zei hij. "We doen dat gewoon niet meer. We doen nu alles met AI, de volledige applicatielevenscyclus." En hoe beheer je dat allemaal? "We hebben vierduizend engineers en de middelen om volledige teams te hebben die het controleren." De verkoper vertelde ons achteraf dat hij daar geen weerwoord op had en dat ook niet probeerde te veinzen.

Dat antwoord bleef de rest van de avond in mijn hoofd zitten en hangt sindsdien als een schaduw over deze serie. Ik heb drie keer geschreven over 2 juni: wat er overblijft voor de consultant, of we een agent kunnen vertrouwen om het werk te doen en of Mendix nog steeds een verdedigbaar platform is om op te bouwen. Elk van die artikelen komt ongeveer op hetzelfde uit: de waarde blijft behouden als je het goed bouwt. Dus de commerciële vraag blijft staan. Als dat allemaal waar is, wie heeft het dan eigenlijk nodig?

‍

De bovenkant van de markt gaf een eerlijk antwoord

De bank was accuraat in plaats van afwijzend. Een bedrijf met vierduizend engineers kan alles met AI doen en volledige teams inzetten om de output te controleren, omdat ze zich dat kunnen veroorloven. Die ondernemingen hebben hun AI op orde en hun budgetten uitgegeven, dus de vraag die ze stellen is terecht: waarom zouden we hier een platform voor toevoegen als we er zelf al een bouwen?

Het instinct waar velen van ons op getraind zijn – achter de grootste logo's aanjagen en de enterprise binnenhalen – verdient een tweede blik. De bedrijven met de meeste middelen hebben het minst behoefte aan een platform dat hen werk uit handen neemt, omdat ze gewend zijn dat werk zelf te dragen. Tenminste, als ze al een softwaregericht bedrijf zijn. Als dat niet zo is, geeft een platform als Mendix nog steeds een enorme voorsprong zonder de jaren die het kost om zelf een platformbenadering op te bouwen. Want ja, dat is wat er nodig is om een situatie te bereiken die in de buurt komt van wat platforms zoals die van Siemens kunnen bieden.

‍

Een nuance die ik zelf wil toevoegen

Lees dat antwoord terug en het klinkt alsof AI de deur grotendeels heeft dichtgegooid. Ik denk niet dat dat zo is. Was die bank ooit van plan om een low-code platform te kopen? In 2019, met dezelfde vierduizend engineers, nog voor dit alles? Vrijwel zeker niet om hun volledige tech-stack te vervangen.

Een paar zaken zorgen ervoor dat een bedrijf van die omvang zijn eigen oplossingen blijft bouwen, en de meeste daarvan hebben weinig met AI te maken.

• Gewoonte en historie. Een organisatie die al twintig jaar op eigen wijze software bouwt, heeft een landschap, standaarden, een beoordelingsproces en bestaande middelen en componenten. Niemand gooit dat eruit omdat een leverancier langskomt met een beter verhaal.
• Talent, dat lokaler is dan we meestal toegeven. Als je vierduizend engineers kunt aannemen, en ze kunt aannemen op plekken waar de arbeidskosten gunstig zijn, is intern bouwen een verdedigbare keuze. Voor een bedrijf in Nederland dat in Nederland aanneemt, kan die berekening er heel anders uitzien, en dat geldt ook voor de waarden en overtuigingen die erachter zitten.
• De kosten die ze al hebben gemaakt, waar de bank niet over sprak. Jaren aan procedures, interne standaarden, een platformteam, een intern ontwikkelaarsplatform dat iemand in de lucht moet houden. Ze hebben het werk niet overgeslagen. Ze hebben het in-house gekocht en de kosten over een decennium gespreid; een dure positie waar alleen een bedrijf met de schaal, strategie en tijd in terecht kan komen.

De vierduizend engineers bewijzen dus niet dat het platformmodel dood is. Ze laten zien dat een bedrijf dat groot genoeg is, met de juiste strategie, zelf een vergelijkbare platformervaring kan bouwen. Dat hebben ze gedaan, en het kostte jaren en echt geld. Het zegt weinig over low-code, en veel over wie het zich kan veroorloven om zonder te werken.

‍

Een bewegende markt

Ik heb niet eens het gevoel dat er al te veel is veranderd, met één belangrijke toevoeging waar ik later op terugkom. De kans ligt bij het bedrijf dat zoiets zegt als: "Ik ben een bouwbedrijf, geen IT-bedrijf," en wil dat één leverancier de beveiliging, het beheer en de integraties al heeft afgedekt. Zij kunnen geen interne teams inzetten om high-code AI-output te controleren, en dat willen ze ook niet. Ze willen het werk afkopen, wat, zoals ik de vorige keer betoogde, de echte kracht van low-code is zodra je stopt met denken dat het alleen om de snelheid van de eerste oplevering gaat.

Een nuttige scheidslijn door het midden van die markt is grofweg het aantal apps dat je beheert. Een bedrijf met één app neigt naar de pure prompting-tools als voorsprong, want waarom zou je voor één app niet gewoon prompten en kijken hoe het uitpakt? Maar zodra je een dozijn apps, integraties en systemen hebt die met elkaar moeten praten en gezamenlijk beheerd moeten worden, heb je iets nodig dat het hele landschap bij elkaar houdt. Een orchestratieplatform dat ze allemaal kan beheren, begint daar zin te krijgen op een manier die voor een enkele app nooit het geval was. Dat is het enterprise-profiel waar dit alles nog steeds in past. Het is te klein om het platform te zijn ontgroeid om domeinspecifieke redenen, en te groot om de ene app te prompten zonder naar het totaalplaatje te kijken. Ik noem het de orchestrerende middenmoot, en dat is waar de meeste bedrijven zich zullen bevinden.

‍

De bezwaren

Sommige bezwaren komen elke keer terug, en ik beantwoord ze liever dan dat ik ze wegwens.

Het eerste is perceptie. Er heerst in sommige kringen een gevoel dat kiezen voor low-code in 2026 de minst avontuurlijke optie is; de verstandige en ietwat saaie keuze terwijl iedereen iets flitsends doet met AI. Die perceptie is slechts gedeeltelijk terecht, gezien de enorme AI-investeringen van Siemens. Het platform is misschien niet op de dag na de release van een nieuwe versie van de grote frontier-modellen direct op gelijke hoogte met de mogelijkheden daarvan. Dat gezegd hebbende: zelfs sinds de Meetup in juni (dit artikel werd in september gepubliceerd) is AI-ondersteunde ontwikkeling met Mendix enorm volwassen geworden. Ik ben er vrij zeker van dat de discussie genuanceerder zou zijn als we deze sessie opnieuw zouden organiseren.

Het tweede is lock-in, en dat is een terechte zorg. "Het is de helft van de prijs en dan ben ik eigenaar van de IP" is iets wat kopers oprecht zeggen wanneer ze een beheerd platform afwegen tegen high-code. High-code voelt als vrijheid, een beheerd platform kan voelen als een kooi, en AI heeft de high-code kant er in ieder geval minder "locked-in" uit laten zien dan voorheen. Het ontkennen van de lock-in helpt niet. Duidelijk zijn over wat het je oplevert wel, en ook duidelijk zijn over wat het zou kosten om te migreren. Met een redelijk open platform als Mendix zijn die kosten lager dan mensen verwachten, en met Maia Transform is het inmiddels vrij goed te doen om codebases naar en van Mendix te migreren. Die optie hebben kan zorgen voor de nodige gemoedsrust terwijl je geniet van de voordelen van het platform.

De derde is subtieler. Een klant die elders al een volwassen AI-strategie heeft, zit er niet op te wachten om nieuwe AI te moeten koppelen aan nóg een resourcepool van een ander platform. Ze willen gebruikmaken van de investeringen die ze al hebben gedaan. Als je alleen inzet op 'greenfield' en "voeg hier AI toe", blijf je kopers tegenkomen die vanuit een andere hoek naar AI zijn gekomen en daar al eerder waren. Door dat te respecteren, ontstaat er een veel dieper gesprek over wat er echt nodig is, zeker omdat je met Mendix hun eigen AI kunt gebruiken, je eigen AI kunt meebrengen of ze kunt combineren tot een mix die bij je past.

‍

De eigenlijke pitch

Het is scherper dan wat eraan voorafging, ook al klinkt het in eerste instantie als een stap terug.

Je verkoopt het feit dat het al gedaan is: de leverancier die de governance, beveiliging en integratie al heeft opgelost, zodat het bouwbedrijf dat niet meer hoeft te doen. Voor de juiste klant is "wij hebben het moeilijke werk al gedaan" een sterkere boodschap dan "wij zijn sneller", wat al niet meer waar was zodra een prompt sneller kon worden verstuurd dan wij konden typen. Ook al zijn dit vaak prototypes en nog geen enterprise-grade apps vanaf de eerste oplevering. Wanneer je je Mendix-app vanaf dag één uitrolt, krijg je ISO 27001, 27017, 27018, 9001 en SOC 2 Type II-rapportages, plus ondersteuning voor AVG, HIPAA en PCI-DSS zonder dat je zelf hoeft te weten wat dat allemaal inhoudt. Dit is en blijft een van de belangrijkste redenen om Mendix als je enterprise-app-platform te kiezen.

Er is ook een wig die de groep met vierduizend engineers niet kan slaan, omdat het niets met resources te maken heeft en alles met vertrouwen. Data. Een consultant aan een andere tafel, die het over een overheidsinstelling had, verwoordde het treffend: ze zijn "erg bang voor wat er met de data gaat gebeuren". Dus je begint niet met de AI. Je bouwt eerst het vertrouwen op, houdt de data in hun eigen handen op infrastructuur die zij controleren, en laat de AI pas op de tweede plaats komen. Voor een hele categorie klanten – in de overheid, de zorg, overal waar data het pand niet mag verlaten – is dat de enige reden waarom ze überhaupt 'ja' kunnen zeggen. Lokale LLM's zijn hier snel inzetbaar, en Mendix en Maia kunnen die net zo goed gebruiken.

Voor degenen die dit deel van de serie hebben bereikt en denken: maar hoe zit het met Siemens? Het grootste deel van de Nederlandse Mendix-community heeft ervaring in andere domeinen dan de maakindustrie, dus het is geen verrassing dat deze invalshoek niet aan bod kwam. Het moet echter ook niet worden genegeerd. Met Mendix in hun portfolio, inclusief de brede (AI-)mogelijkheden die hierboven zijn besproken, kan ik alleen maar blij zijn voor de klanten die al stevig hebben geïnvesteerd in het Siemens-ecosysteem.

‍

Afsluiting van de serie

De bank met vierduizend engineers zou nooit de belangrijkste groeimarkt zijn, en daarop jagen is de manier om je vervangbaar te gaan voelen. De groei zit bij iedereen onder die grens die het niet zelf kan en ook niet wil: de orkestrerende middenmoot, de gereguleerde sectoren, de partijen die één vertrouwde leverancier willen die het zware werk heeft afgedekt en hun data houdt waar die hoort.

Dat waren vier vragen van één avond: wat blijft er voor ons te doen, kunnen we de agent vertrouwen om het werk te doen, verdient het platform nog steeds de voorkeur, en wie heeft het eigenlijk nodig? Nu ik ze heb opgeschreven, merk ik dat geen van de antwoorden echt over de technologie gaat. Ze komen neer op beoordelingsvermogen, vertrouwen en weten voor wie je er bent. Dat is een geruststellende gedachte voor een zaal vol consultants die zich zorgen maakten over AI.

Bedankt voor het lezen, als je de hele serie hebt doorlopen. Deze artikelen weerspiegelen de discussies in de zaal, aangevuld met mijn eigen mening, dus ik ben erg benieuwd naar jullie gedachten. Resoneert het met wat jij ziet? Ben je blij of maak je je zorgen over de mogelijke nieuwe perspectieven? Hoe dan ook, ik kijk ernaar uit om later dit jaar of begin volgend jaar weer een rondetafelgesprek te organiseren om een aantal stellingen persoonlijk door te nemen.

‍

Oorspronkelijk gepubliceerdhier.

Deel 3 van 4, van de Mendix Community Netherlands Round Table in Amersfoort, 2 juni 2026. In deel 1 en 2 stelden we de vraag wat er nog overblijft voor de consultant en of we een agent kunnen vertrouwen om dat werk te doen; dit deel richt zich op het platform dat aan beide ten grondslag ligt.

Iemand aan tafel vatte het pleidooi voor Mendix in een paar woorden samen: je koopt een hoop gedoe af. Een beheerde cloud, een gevalideerde stack, beveiliging die geregeld is, Siemens dat erachter staat; alles wordt op orde gehouden zodat jij dat niet hoeft te doen. Niet de snelheid. Zelfs niet echt een model dat je kunt lezen. Het hele platform.

Ik heb inmiddels twee keer over 2 juni geschreven. Het eerste artikel verkende wat er nog overblijft voor de consultant. Het tweede vroeg zich af of we een agent kunnen vertrouwen om dat werk te doen. Dit derde artikel richt zich op het fundament onder beide: het platform waarop we alles bouwen. Is kiezen voor Mendix in 2026 nog wel een verdedigbare beslissing, nu concepten als TCO en ontwikkelaarsproductiviteit maandelijks lijken te veranderen?

‍

Wat de verdedigers daadwerkelijk verdedigden

De stelling aan tafel was bewust bot: de reden om in 2026 voor Mendix te kiezen in plaats van voor AI-ondersteunde React is niet de bouwsnelheid; het is dat het resultaat in 2034 nog steeds overeind staat, leesbaar is en beheerd wordt.

De groep die het verdedigde, deed iets wat ik niet als eerste argument had verwacht. Ze verdedigden Mendix zonder ook maar één keer op snelheid te leunen. "Snelheid is nooit het allerbelangrijkste geweest," zei een van hen, "want dan zou iedereen al low-code gebruiken." Dus als het niet de snelheid is, wat dan wel?

Vooral beveiliging en governance. Je koopt geen snellere manier van typen. Je koopt een beheerde cloud die al is ingericht, een stack die jarenlang is gevalideerd, iets dat, in de woorden van een consultant, "gewoon klopt", met Siemens als ruggengraat. "Als ik nu een klant was," zei iemand, "zou ik nog steeds voor Mendix kiezen met Siemens erachter." De pitch was nooit het bouwen zelf. Het was alles wat eromheen zit en wat je anders zelf zou moeten samenstellen, beveiligen en verantwoorden.

Dat is een valide argument, en een betere dan "wij leveren sneller". Met Mendix zijn we al lang gewend om sneller software op te leveren. Uit eigen ervaring weten we dus dat het geweldig is om de broodnodige tijd te kunnen besteden aan het helder krijgen van de vereisten en de adoptie, in plaats van te worstelen met coderingstax.

Een persoonlijke noot die ik hier moet toevoegen, is dat ik er sterk in geloof dat communicatie een van de meest kostbare en tijdrovende obstakels is bij het creëren van nieuwe dingen, of het nu om software gaat of iets anders. Al decennia stelt Mendix zeer kleine teams in staat om software van enterprise-niveau te bouwen, terwijl high-code benaderingen veel grotere teams vereisen om hetzelfde te bereiken. AI kan de omvang van die teams tot op zekere hoogte helpen verkleinen, maar dat betekent niet dat de verantwoordelijkheid wordt gedeeld met een organisatie als Siemens. In plaats daarvan deel je die met een LLM dat door iemand anders is ontwikkeld, inclusief een houdbaarheidsdatum voor de beschikbaarheid ervan. Dat is op zijn zachtst gezegd iets om je bewust van te zijn.

‍

Leesbaarheid is onderdeel van "het klopt"

Eén onderdeel van dat pakket is nu belangrijker dan twee jaar geleden, en het is het punt waar mensen als eerste naar grijpen: je kunt het nog steeds lezen.

Wanneer een agent de code schrijft, is het vermogen om die te openen en te begrijpen geen luxe meer. Het wordt het verschil tussen eigenaar zijn van je app en het huren van een black box. "Ik zie een app niet graag als een black box," zei een ontwikkelaar, "waarbij je een prompt geeft, het bouwt, en je niet weet hoe het vanbinnen werkt." Zijn zorg was concreet en klantgericht: wanneer de klant vraagt hoe je het hebt gebouwd, wil je niet dat je enige eerlijke antwoord is: "dit was mijn prompt." Wanneer er op een ongelegen moment een productieprobleem op je bureau belandt, wil je een flow die je kunt lezen, zelfs als een agent die heeft geschreven. En het leesbare model is wat een ontwikkelaar en iemand van de business in staat stelt om naar hetzelfde te kijken en echt met elkaar te praten. Zelfs als de AI het hele ding genereert, zo stelden de verdedigers, kun je altijd terugvallen op iets leesbaars en het samen doornemen.

Tot zover is dit een sterk, volwassen pleidooi voor Mendix. Beheerd, veilig, leesbaar voor een breed publiek, en iemand anders houdt het op orde. Dat maakt het volgende deel interessant.

‍

Waarom zei de helft van de zaal dan "geen van beide"?

Omdat het hele pakket rust op één aanname, en de sceptici vielen die direct aan. Het platform blijft alleen de moeite waard als Mendix zelf stabiel blijft en voorop blijft lopen. 54% van de stemmen viel op "geen van beide"; de claim van duurzaamheid veronderstelt dat Mendix zijn zaakjes op orde houdt, en ze waren er niet zeker van of dat zou lukken.

De andere kant van de zaal zei het ronduit. "Over tien jaar zien mensen Mendix als high-code," zei iemand, "of als legacy." Een ander dacht niet dat we over tien jaar überhaupt nog code zouden schrijven, ook niet in Mendix. Iemand wees op de pure prompting-tools, waarbij "ik hoef niets meer te doen; het is gewoon prompten," en "het heeft alles veranderd." Het beheerde, gevalideerde, leesbare platform is een geweldig antwoord, totdat iemand anders dezelfde governance "gratis" aanbiedt en je laat prompten om daar te komen. Maar is dat überhaupt mogelijk zonder dat je naar binnen kunt kijken? En als iemand dit kan met jarenlange ervaring in gedeelde verantwoordelijkheden op precies dit vlak, dan zou dat Mendix zijn, toch?

Hoewel ik zelf niet in die zaal zat, geloof ik nog steeds dat het platform zelf hier de grootste waarde bewijst. Veel Mendix-klanten besteden liever niet veel tijd of budget aan hun IT-landschap als dat niet nodig is. Zelfs als je heel snel "werkende" software kunt leveren: als er geen plek is om het zo neer te zetten dat je rustig kunt slapen zonder dat er een kostbare afdeling of ander mechanisme naar omkijkt, wat heeft die snelheid van de eerste oplevering je dan echt gebracht? Met het grote klantenbestand profiteert Mendix simpelweg al van schaalvoordelen. Klanten laten meegenieten van die uniforme aanpak voor de kosten van een licentie.

‍

Het punt waar Mendix zich het meest zorgen over moet maken

Dit kwam niet van een scepticus in de zaal. Het kwam van iemand die Mendix verdedigde.

Hij zette het hele betoog uiteen – de beheerde cloud, de gevalideerde stack, Siemens, alles – en zei toen hardop wat iedereen dacht: "Als je naar 2034 kijkt, waarom zou een AI-code-oplossing dan niet hetzelfde vertrouwen en dezelfde governance kunnen bieden? En dat is de grootste uitdaging voor Mendix."

Dat is de echte concurrentie, en dat is niet de bouwsnelheid van AI-ondersteunde React. Het gaat erom of een AI-native stack dezelfde mate van vertrouwen, governance en leesbaarheid kan bieden als waar Mendix vandaag de dag voor staat. Geen van die drie is een natuurwet; het is een voorsprong. Het gemak dat je bij Mendix inkoopt, is een gemak dat je ook elders zult vinden zodra een concurrent het aanbiedt. Terwijl ik dit schrijf op basis van de uitkomsten van de rondetafelconferentie, vertrouw ik er volledig op dat Mendix scherp blijft. Het bijhouden van de maandelijkse releasenotes was al nooit een sinecure (in positieve zin), maar de breedte en diepgang van de releases zijn nu nog verder toegenomen.

‍

Dus, verdedigbaar of niet?

Ja, en wel om de juiste redenen: het beheerde platform en het leesbare model, niet de snelheid van een demo. Maar die positie is niet vanzelfsprekend. Mendix concurreert niet echt op de vraag of ze een app kunnen bouwen. Ze concurreren op de vraag of ze de meest beheerste, meest leesbare en meest gestructureerde manier van bouwen blijven, terwijl AI-tools gestaag naar diezelfde belofte toewerken. Dat is een race, geen slotgracht. Terugkomend op mijn persoonlijke notitie: betere software bouwen met minder mensen is een van de grootste krachten van het Mendix-ecosysteem. En wat dat betreft heb ik nog niet veel sterke uitdagers gezien als het gaat om enterprise-grade software die niet gebonden is aan een specifiek domein of software-ecosysteem.

De verdedigers in die ruimte hadden geen ongelijk. Ze waren alleen eerlijk over de tijd die tikt. De reden om voor Mendix te kiezen is nog steeds valide. De vraag is voor hoe lang, en dat antwoord hangt minder af van wat AI hierna doet dan van wat Mendix hierna doet. Met de onlangs aangekondigde Intelligence Center Xkunnen we zeker stellen dat Siemens voorop loopt.

Wat nog één vraag overlaat van 2 juni, en dat is de ongemakkelijke commerciële vraag. Als dit allemaal waar is, wie heeft het dan eigenlijk nodig? Daarover de volgende keer meer.

‍

Oorspronkelijk gepubliceerdhier.

Deel 2 van 4, van de Mendix Community Netherlands Round Table in Amersfoort, 2 juni 2026. In deel 1 vroegen we ons af wat er nog overblijft voor de consultant; in dit deel vragen we ons af of we een agent kunnen vertrouwen om dat werk te doen.

Ze gaf een AI toegang tot haar computer en haar inbox en vroeg het om wat werk te verzetten. Het begon echte e-mails te verwijderen, duizenden tegelijk. Ze zei dat het moest stoppen. Het ging gewoon door. Achteraf vroeg ze waarom. Het antwoord was: ja, ik wist dat het fout was, maar ik deed het toch.

Dat verhaal werd op 2 juni aan één tafel verteld. Daarna dook het, uit zichzelf, aan een andere tafel op. Twee zalen vol Mendix-consultants, dezelfde avond, die allemaal naar hetzelfde waarschuwingsverhaal grepen zonder van elkaar te weten dat ze dat deden.

Vorige keer schreef ik dat de agent het bouwen gaat overnemen en dat de taak die voor ons overblijft is om te bepalen wat de moeite waard is om te bouwen en om verantwoordelijkheid te nemen voor wat we opleveren. Dit is de volgende vraag, en de aanwezigen konden hem niet loslaten. Zodra de agent zelfstandig kan handelen, laten we dat dan toe?

‍

Dus laten we het gewoon niet handelen?

Kort door de bocht was dat het eerste antwoord van de avond. De stelling aan tafel was dat elke agent-functie die we uitrollen een mens in de loop moet houden, en 69% stemde voor het afschermen van de agent (negen van de dertien). Niet omdat de aanwezigen denken dat de technologie voor altijd gevaarlijk is. Maar omdat het vertrouwen nog niet is verdiend, en dat is iets anders. Vandaag suggesties, daarna begeleide acties, en pas autonomie als er een trackrecord is. Zoals een ontwikkelaar het verwoordde: als het bewijst dat het werkt, gaan we van één, naar twee, naar drie.

Tot zover, zo verstandig. Houd er een mens bij totdat het zijn eigen weg heeft verdiend. Maar die redenering heeft een gat, en iemand aan tafel legde daar de vinger op.

‍

Wat het gesprek veranderde

Het scherpste wat de hele avond werd gezegd, ging helemaal niet over vertrouwen. Het ging over het loodgieterswerk.

"De manier waarop agents op dit moment werken," zei een support engineer, "is dat je gewoon een wrapper om de hele API zet en zegt: hier is de API, ga je gang. En er is geen enkel verschil tussen iets lezen en iets verwijderen."

Dat is het eigenlijke probleem. Niet of de agent betrouwbaar is, maar dat we hem een tool geven die het veilige van het destructieve niet kan onderscheiden, en dat we vervolgens gaan discussiëren over het karakter van de agent. Verander de tool, en de discussie verandert. Hier zijn je API's, was de nieuwe insteek, maar ze zijn alleen-lezen. Ik ga je niet de tool geven om iets gevaarlijks te doen.

Iemand wilde het fysiek maken. Geen instelling, geen regel in een systeem-prompt. Een echte schakelaar die moet worden omgezet voordat het gevaarlijke kan gebeuren, en de agent mag die niet zelf omzetten. Het klinkt paranoïde. Het klinkt een stuk minder paranoïde als je het e-mailverhaal hebt gehoord.

Dit is de verschuiving van het afschermen van de agent naar het afschermen van de tools. Stop met proberen de agent betrouwbaar te maken. Bepaal waar hij bij kan.

‍

Wat in controle zijn echt betekent

Hierover was de groep het meest eens. Op de vraag of we nog steeds de controle hebben over wat AI bouwt, kwam 86% op hetzelfde antwoord uit (zes van de zeven): het hangt af van de kaders. Niet het antwoord van de optimist, niet dat van de pessimist. Dat van de engineer.

En de redenering was concreet, en in beide zalen hetzelfde. Bepaal de reikwijdte van de tools die de agent krijgt. Scheid de dingen die lezen van de dingen die vernietigen. Houd back-ups bij en zorg voor een herstelpad. Zet een mens voor alles wat je niet ongedaan kunt maken. Een consultant trok de grens precies: orders aanmaken is geen probleem; als je orders verwijdert, is dat een probleem. Laat de agent vrij handelen waar acties eenvoudig terug te draaien zijn, en scherm het streng af waar dat niet zo is. Of, zoals hij de beperking verwoordde: je kunt markeren voor verwijdering; je kunt niet echt verwijderen. Als er een eenvoudig herstelmechanisme is, dan is het prima om hem die vrijheid te geven.

Vrijheid binnen de kaders, verantwoording bij de uitgang. Dat is geen compromis tussen het wel of niet vertrouwen van de agent. Het is een ontwerp. En het is een ontwerp dat we al weten te bouwen, omdat het dezelfde denkwijze is die we toepassen op wie wat mag doen in elke Mendix-app die we ooit hebben opgeleverd. Persoonlijk helpt dit me ook om de nuances in dit AI-tijdperk te zien. Deterministische processen blijven deterministisch met dezelfde strikte validaties en workflows die we vandaag de dag kennen. De manier waarop we ermee omgaan verandert misschien, maar de essentie zelden.

‍

Dus alles afschermen en rustig slapen? Niet helemaal.

Dit is het deel waar ik eerlijk over wil zijn, omdat het makkelijk is om dit weg te laten uit een nette conclusie.

De afscherming is voor nu. Het is niet voor altijd. Dezelfde tafel die stemde om een mens in de loop te houden, zei dat hardop en vroeg de host om het te noteren: het zal zonder twijfel naar drie gaan. Vertrouwen wordt verdiend, de hekken gaan weg, en de zorgvuldige consensus waar iedereen net voor stemde, heeft een houdbaarheidsdatum.

Het nuttige werk is dus niet het bouwen van de poort. Het is de poort zo bouwen dat hij kan bewegen. Een grens die je stap voor stap kunt verleggen naarmate elke actie dat rechtvaardigt, is veel waardevoller dan een algemene regel als "een mens keurt alles goed", die je in de eerste week al stilletjes zult negeren zodra het je vertraagt. Eén tafel opperde zelfs om de poort naar het einde te verplaatsen: laat de agents hun werk doen en zet iemand met gezond verstand bij het controlepunt voordat er echt iets gebeurt. De poort hoeft niet voor eeuwig op dezelfde plek te staan. Hij moet op de plek staan die past bij het vertrouwen dat je vandaag daadwerkelijk hebt.

‍

De verwijderknop die niemand weghaalde

De agent die die duizenden e-mails verwijderde, was niet kwaadaardig en ook niet defect. Hij sprak de waarheid, op zijn eigen vreemde manier. Hij wist dat de actie fout was en voerde hem toch uit, omdat niemand de verwijderknop uit zijn handen had genomen.

Controle is nooit een gevoel dat je hebt over AI, of dat nu optimisme of angst is. Het is een beslissing die je neemt over waar de agent bij kan, en die beslissing kun je telkens opnieuw nemen wanneer het vertrouwen verandert. Doe je dat goed, dan kun je een agent verrassend veel vrijheid geven. Doe je het fout, dan maakt het niet uit hoeveel vertrouwen je in hem hebt.

Dit was het tweede artikel dat ik heb geschreven op basis van 2 juni. Het eerste stelde de vraag wat er voor ons overblijft om te doen. Dit artikel vroeg zich af of we de technologie kunnen vertrouwen om dat werk te doen. Er ligt nog één vraag onder beide, en die gaat over het platform waarop we dit alles bouwen. Daarover de volgende keer meer.

‍

Oorspronkelijk gepubliceerd hier.