Je kunt Claude en MCP inzetten binnen je OutSystems-praktijk zonder op te geven wat low-code je juist heeft gebracht: een visueel model dat je kunt bekijken, beoordelen en vertrouwen.
De meeste low-code-teams die ik spreek, voelen dezelfde spanning. Ze zien wat AI-agents kunnen en willen profiteren van de snelheid die ze bieden. Maar tegelijkertijd horen ze: “AI schrijft de code” en zien ze een black box voor zich. Duizenden regels code die niemand heeft beoordeeld, een architectuur die langzaam uit de pas gaat lopen en governance die uit beeld verdwijnt. Voor een team dat juist voor OutSystems heeft gekozen vanwege de controle en transparantie, voelt dat als een stap terug.
Maar dat hoeft niet zo te zijn. In deze blog leg ik uit waarom, en laat ik zien hoe wij deze transitie in de praktijk aanpakken.
Waarom die angst begrijpelijk is
Die angst is niet onterecht. Low-code heeft namelijk een aantal echte problemen opgelost die door ongecontroleerd gebruik van AI bij softwareontwikkeling weer kunnen terugkomen.
OutSystems heeft ons veel meer gebracht dan alleen snelheid:
- Een visueel model als bron van waarheid. Schermen, logicaflows, entiteiten en rollen zijn dingen die je kunt openen en bekijken, geen tekst die je via reverse-engineering moet doorgronden.
- Ingebouwde guardrails. Validatie detecteert verbroken verwijzingen, typefouten en impact over modules heen voordat er iets wordt gepubliceerd.
- Governance by design. Omgevingen, deployment pipelines, rollen en dependency management zijn onderdeel van het platform, geen gedachte achteraf.
- Leesbaarheid voor het hele team. Een businessanalist of architect kan een logicaflow volgen zonder C# of JavaScript te hoeven lezen.
Stel je nu voor dat een AI-agent een traditionele codebase genereert. Elke wijziging is een diff van honderden regels. Architectuurstandaarden zitten in de hoofden van mensen. Reviews worden een kwestie van vluchtig doornemen. Dat is het scenario waar teams bang voor zijn, en terecht.
De vraag is niet of je AI moet gebruiken. De vraag is waar de AI zijn werk doet.
De verschuiving: AI past het model aan, niet een berg code
Met MCP genereert Claude geen aparte codebase naast OutSystems. Het werkt binnen het OutSystems-model, via hetzelfde platform dat jouw regels afdwingt.
Het Model Context Protocol (MCP) is een open standaard waarmee een AI-assistent op een gecontroleerde manier tools in een ander systeem kan aanroepen. Wanneer OutSystems zijn mogelijkheden via MCP beschikbaar stelt, kan Claude bijvoorbeeld:
- het datamodel, de schermen en de logica van een bestaande app lezen;
- een entiteit, een attribuut, een Server Action of een scherm toevoegen;
- validatie uitvoeren en de fouten en waarschuwingen teruglezen;
- Mentor vragen om een stuk functionaliteit te bouwen of te beoordelen;
- publiceren, maar alleen wanneer jij dat toestaat.
Het resultaat van elke wijziging is een gewoon OutSystems-element. Je opent Service Studio of ODC Studio en ziet precies wat er is gebouwd: de entiteit in het datamodel, de flow op het canvas, de widget op het scherm. Niets is verborgen in gegenereerde bestanden.
Dat is het belangrijkste inzicht: het visuele model blijft de enige bron van waarheid. Claude wordt een extra developer in het team, eentje die heel snel werkt, maar die werkt binnen jouw model, volgens jouw regels, en wiens werk je op dezelfde manier beoordeelt als dat van een collega.
Claude werkt in jouw model, jij bewaakt de poorten
Claude + MCP on OutSystems · 8 stappen, 3 poorten
Claude krijgt alleen toegang tot het model via de MCP-tools die jij toestaat. Validatie, jouw visuele review en jouw goedkeuring bevinden zich allemaal tussen het werk van Claude en de omgeving.
Vijf lagen van controle die je behoudt
Controle ontstaat niet door AI te vermijden, maar door controlepunten te plaatsen tussen de AI en productie. Met Claude + MCP op OutSystems krijg je vijf van zulke controlepunten.
| Laag | Wat het doet | Wie bepaalt |
| Toolrechten | Claude kan alleen de MCP-tools aanroepen die jij toestaat. Voor publiceren of deployen kan elke keer expliciete goedkeuring nodig zijn | Jij |
| Platform validatie | Elke wijziging doorloopt dezelfde OutSystems-validatie als een wijziging die door een mens is aangebracht. Fouten blokkeren het publiceren | Het platform |
| Visuele controle | Je opent de gewijzigde schermen, flows en entiteiten in Service Studio of ODC Studio en beoordeelt ze als een model, niet als een diff. | De ontwikkelaar |
| Kleine stappen | Het werk wordt opgedeeld in tickets. Elk ticket wordt gebouwd, gecontroleerd en bevestigd voordat aan het volgende wordt begonnen. | Het team |
| Lifecycle governance | Omgevingen, deployment pipelines en rollen werken precies zoals voorheen. Wijzigingen door AI komen terecht in Dev, niet in Prod. | Het platform team |
Twee gewoonten maken het grootste verschil:
- Houd publiceren en deployen achter een menselijke beslissing. Laat Claude vrij bouwen en valideren, maar maak de gang naar een volgende omgeving een expliciete beslissing.
- Leg je standaarden vast op een plek waar Claude ze kan lezen. Naamgevingsconventies, architectuurlagen (core, foundation, end-user) en regels voor hergebruik in een kort instructiebestand veranderen ‘kennis die alleen in de hoofden van mensen zit’ in iets wat de AI elke keer volgt.
Hoe het er in de praktijk uitziet
Een typische feature gaat in één cyclus van ticket naar beoordeeld scherm, waarbij de developer op elk beslismoment de controle houdt.
Stel dat het ticket luidt: ‘Voeg een Supplier-entiteit toe en een scherm om leveranciers weer te geven en te bewerken.’
- Claude leest de context. Via MCP bekijkt Claude het bestaande datamodel, de modulestructuur en je instructiebestand, zodat het weet waar entiteiten staan en hoe schermen worden genoemd.
- Claude stelt een plan voor. “Voeg Supplier toe aan de core-module met Name, Email en IsActive; maak de schermen Suppliers en SupplierDetail in de end-user-module.” Jij past het plan aan of keurt het goed.
- Claude bouwt in het model. Het maakt de entiteit, de CRUD-actions en de schermen, rechtstreeks of door Mentor aan te sturen.
- Het platform valideert. Claude leest de validatiemeldingen en corrigeert zijn eigen fouten voordat het jou iets vraagt.
- Jij beoordeelt het visueel. Je opent Service Studio of ODC Studio en bekijkt de entiteit, de flows en de schermen, op dezelfde manier als je het werk van een teamgenoot zou beoordelen.
- Jij besluit om te publiceren. Pas na jouw ‘akkoord’ gaat het naar de Dev-omgeving, en van daaruit je normale pipeline in.
Niets in deze cyclus vereist dat je gegenereerde code leest. Alles wat je beoordeelt, is iets waarvan je al weet hoe je het moet lezen.
Hoe start je de overgang
Begin klein, met alleen-lezen toegang en in een sandbox. Breid wat Claude mag doen pas uit naarmate het vertrouwen groeit.
- Begin met alleen-lezen toegang. Verbind Claude via MCP met OutSystems en laat hem alleen lezen: een app uitleggen, de architectuur ervan in kaart brengen, documenteren en afhankelijkheden vinden. Teams leren zo hoe Claude zich gedraagt zonder enig risico.
- Leg je huisregels vast. Leg conventies voor naamgeving, architectuurlagen en hergebruik vast in een kort instructiebestand. Dit is de belangrijkste manier om de kwaliteit te beïnvloeden.
- Kies een sandbox-app. Laat Claude echte features bouwen in een niet-kritische app in een Dev-omgeving. Beoordeel elke wijziging visueel.
- Houd mensen verantwoordelijk voor het publiceren. Vereis goedkeuring voor publiceren en deployen. Versoepel dit alleen waar je voldoende vertrouwen hebt, bijvoorbeeld bij persoonlijke development branches of prototypes.
- Werk ticket voor ticket. Kleine, goed beschreven tickets geven de beste resultaten en houden reviews snel.
- Meten en delen. Houd de tijd per ticket, het herstelwerk en validatiefouten bij. Deel binnen het team wat goed werkt, zodat het bestand met regels steeds verder kan worden verbeterd.
Low-code wordt niet vervangen. Je krijgt een copiloot.
De overstap naar Claude + MCP is geen stap weg van OutSystems. Het is een manier om er meer uit te halen.
Het visuele model, de validatie, de governance en de lifecycle waarop je vertrouwt, blijven allemaal bestaan. Wat verandert, is de snelheid waarmee ideeën worden omgezet in beoordeelde, werkende apps. De rol van de developer verschuift van het stuk voor stuk op zijn plek klikken van elk element naar sturen, beoordelen en beslissen.
Je verliest de controle niet. Je verplaatst die naar waar hij ertoe doet: het plan, de review en de publicatieknop.
En dit is nog maar het topje van de ijsberg. Wat Claude + MCP vandaag in OutSystems kan doen, geeft een eerste indruk van hoe apps de komende jaren zullen worden gebouwd. De teams die nu beginnen te leren, bepalen de koers. De teams die wachten, zullen op de harde manier kennismaken met de ijsberg.
Word dus niet de Titanic. Stuur op tijd bij, stuur zorgvuldig, maar stuur.
Benieuwd hoe dit eruitziet met je eigen apps? Neem contact op met CoolProfs. We laten het graag live zien.
Door Joost Landgraf, CTO, CoolProfs