Whitepaper: onder de motorkap van Agentic Application Development
Hoe Ciphix enterprise-applicaties bouwt op low-code-snelheid, met volledig eigenaarschap en zonder platform-lock-in.
Onze eerste whitepaper, “van AI-experiment naar productie”, ging over de strategische stap: waarom organisaties hun AI-initiatieven uit de pilotfase krijgen en wat Agentic Application Development (AAD) voor de business betekent. Dit document gaat een laag dieper. Het is geschreven voor de mensen die de techniek moeten kunnen beoordelen: hoe een AAD-applicatie is opgebouwd, hoe beveiliging en kwaliteit structureel worden afgedwongen, waar de applicatie draait, en waarom het eigenaarschap bij de organisatie blijft.
In één zin: AAD combineert een productieklare applicatiebasis met AI-gestuurde ontwikkeling, zodat enterprise-applicaties ontstaan op hoge ontwikkelsnelheid, terwijl het resultaat standaard, draagbare software is die de organisatie volledig bezit.
- Bouw sneller zonder concessies
Ontwikkel productiewaardige applicaties in weken in plaats van maanden. - Voorkom losse AI-experimenten
Werk vanuit één fundament voor integraties, governance en architectuur. - Houd controle over je software
Bouw zonder platform lock-in en behoud volledige flexibiliteit.
Van belofte naar architectuur
De kernbelofte van AAD is eenvoudig samen te vatten: de snelheid van een kant-en-klaar ontwikkelplatform, zonder de prijs die daar normaal voor wordt betaald in de vorm van lock-in, gebruikerslicenties en een aanpassingsplafond. Die belofte is alleen geloofwaardig als de techniek eronder klopt. Snelheid die ten koste gaat van kwaliteit is geen voordeel, en eigenaarschap dat alleen op papier bestaat is geen eigenaarschap.
Dit hoofdstuk en de volgende laten zien dat de snelheid niet uit het overslaan van stappen komt, maar uit het elimineren van herhalend werk, en dat de kwaliteit niet uit individuele expertise komt, maar uit systematische afdwinging. Drie bouwstenen maken dat mogelijk:
- De Base. Een productieklare applicatiebasis die alles bevat wat een enterprise-applicatie nodig heeft, nog vóór de eerste regel bedrijfslogica.
- Een AI-agent die binnen kaders werkt. Niet “AI die willekeurige code genereert”, maar een agent die opereert binnen een gestructureerde basis met vaste conventies en geautomatiseerde kwaliteitspoorten.
- Afdwinging in plaats van afspraken. Beveiligings-, architectuur- en kwaliteitsregels zijn in de tooling ingebakken, niet vastgelegd in een document dat iemand hoort te volgen.
De anatomie van een AAD-applicatie
Elke applicatie die op de Ciphix Base wordt gebouwd, volgt dezelfde vorm. Wie er één begrijpt, begrijpt ze allemaal. Dat is een bewuste keuze: voorspelbaarheid maakt zowel mensen als AI-agents betrouwbaarder.
- Eén applicatie, twee helften. De interface (de frontend) en de motor (de backend) zijn twee delen van één geheel. Ze delen één set afgesproken datacontracten, zodat beide kanten altijd in de pas lopen en een wijziging aan de ene kant onmiddellijk een fout oplevert aan de andere, tijdens het bouwen, niet in productie.
- Toegangscontrole vóór elke request. Voordat een verzoek bij de data komt, passeert het één gedeelde toegangslaag. Die bevestigt wie de gebruiker is, beperkt de resultaten tot de records die diegene mag zien, en verbergt de velden die diegene niet mag lezen of wijzigen. Omdat die laag gedeeld is en overal geldt, gelden overal dezelfde regels.
- Gedeelde bouwstenen. De veeleisende, beveiligingsgevoelige onderdelen (inloggen, toegangscontrole, bestandsbeheer, e-mail, notificaties, achtergrondwerk) komen uit gedeelde, geversioneerde pakketten die elk project hergebruikt. Ze zijn één keer gebouwd, grondig getest, en verbeteren voor alle projecten tegelijk.
- Data en opslag. Applicatiedata leeft in PostgreSQL, een bewezen enterprise-database. Geüploade bestanden staan in beheerde objectopslag. Werk dat tijd kost of een externe dienst aanroept, zoals e-mail versturen, documenten genereren of grote imports verwerken, draait op de achtergrond zodat de applicatie responsief blijft.
De technische stack
De Base is gebouwd op breed gedragen, open technologieën. Dit zijn geen niche-keuzes: het zijn de meest voorkomende talen en frameworks in de moderne webontwikkeling, en daarmee ook de talen die elke AI-codeerassistent het beste begrijpt.
De rode draad: standaardtools die elke webontwikkelaar herkent en die op gewone cloudinfrastructuur draaien. Er is geen proprietary runtime en geen licentie die aan de technologie zelf hangt. In de praktijk betekent dat geen talentschaarste (elke TypeScript- of Vue-ontwikkelaar kan eraan werken), geen vendor-sunset-risico (open technologie wordt niet stopgezet of opgekocht) en volledige compatibiliteit met het hele ecosysteem van AI-ontwikkeltools.
“Build the right thing”, in de praktijk!
De Base en het pakket-ecosysteem
Geen enkele grote capaciteit van de Base, zoals authenticatie, e-mail, notificaties, PDF-generatie of AI, is rechtstreeks in elke applicatie ingebouwd. In plaats daarvan leeft elke capaciteit in een apart, geversioneerd pakket onder de @ciphix/*-namespace. De Base zelf is een dunne laag die deze pakketten aan elkaar knoopt met projectspecifieke configuratie.
Dat heeft drie concrete gevolgen:
- Consistentie over projecten heen. Elke Ciphix-applicatie krijgt dezelfde authenticatie, dezelfde e-mailafhandeling en hetzelfde beheerpaneel, omdat ze allemaal dezelfde pakketten gebruiken. Een verbetering of fix in een pakket stroomt naar elk project bij de volgende update.
- Scheiding van verantwoordelijkheden. De pakketten worden onderhouden door het platformteam. Projectteams richten zich op bedrijfslogica, niet op infrastructuur.
- Samenstelbaarheid. Een project dat geen PDF-generatie nodig heeft, laat dat pakket simpelweg weg. Een project dat AI-functies nodig heeft, neemt het AI-pakket mee.
Functioneel vervullen deze pakketten dezelfde rol als de ingebouwde modules van een kant-en-klaar ontwikkelplatform: de beheermodule, de e-mailmodule, enzovoort. Het verschil is dat wij ze bezitten, kunnen uitbreiden, en dat er geen licentiekosten aan verbonden zijn. De capaciteiten dekken onder meer: identiteit en toegang, e-mail en Microsoft 365, notificaties en push, bestandsopslag, PDF-generatie, Excel-import, datavisualisatie, AI en agents, realtime en locking, achtergrondtaken, internationalisatie, en het designsysteem.
De set groeit in de tijd: terugkerende behoeften over projecten heen worden omgezet in gedeelde bouwstenen. Hier komt ook de doorlopende waarde vandaan. Het jaarlijkse onderhoud geeft toegang tot updates en verbeteringen over het hele pakket-ecosysteem, inclusief proactieve beveiligingspatches en framework-upgrades, zodat de applicatie actueel blijft in plaats van langzaam legacy te worden.
Het designsysteem: visuele consistentie als bouwsteen
Enterprise-applicaties hebben visuele consistentie nodig. Op kant-en-klare ontwikkelplatforms komt die uit ingebouwde widget-bibliotheken; in AAD komt die uit een eigen designsysteem: een bibliotheek van vooraf gebouwde, gestandaardiseerde interface-componenten (formuliervelden, datatabellen met ingebouwde paginering en filtering, dialogen, panelen, lege en laadtoestanden). De ontwikkelaar, of de AI-agent, begint nooit bij ruwe opmaak, maar stelt pagina’s samen uit deze componenten, vergelijkbaar met het slepen van widgets in een visuele bouwomgeving. Een interactieve catalogus (Storybook) toont elk component in isolatie en dient als het “palet” waaruit de agent put. Het gevolg: ook een nieuw gegenereerde pagina ziet eruit en voelt als elke andere pagina in de applicatie.
Het modulesysteem
Binnen een applicatie is alles georganiseerd als modules. Een module is een zelfstandige plak functionaliteit (bijvoorbeeld een CRM-, planning- of facturatiemodule) die zijn eigen onderdelen meebrengt:
Modules komen uit twee bronnen, maar volgen exact hetzelfde contract: de herbruikbare @ciphix/*-modules uit het pakket-ecosysteem, en de applicatiespecifieke modules die het team toevoegt om het domein van een concrete applicatie te modelleren.
Waarom dit voor de techniek uitmaakt: elke beveiligingsbeslissing leeft naast de code die zij regelt, niet in een centrale configuratie ver weg. Welke rollen bestaan, welke velden leesbaar zijn, welke rijen een gebruiker mag raken, welke acties hij mag aanroepen: het staat bij de module zelf. Verdwijnt een module, dan verdwijnen zijn rechten mee. Komt er een module bij, dan declareert die zijn eigen rollen. Dit voorkomt de stille rechtenophoping die grote applicaties op den duur onveilig en onleesbaar maakt.
Herkenbaar voor Mendix-teams: Het rollenmodel zal vertrouwd aanvoelen. Rollen per module, gebundeld tot gebruikersrollen op applicatieniveau. Dezelfde splitsing als op zulke platforms, maar uitgedrukt in standaard code in plaats van in een proprietary model.
Het beveiligingsmodel: defense in depth
Beveiliging zit in het fundament, niet als laagje erbovenop. Het model rust op één principe: standaard wordt alles geweigerd. Toegang ontstaat alleen waar een regel die expliciet verleent. Dat principe wordt op meerdere onafhankelijke lagen afgedwongen, zodat een fout in één laag niet meteen tot een datalek leidt.
Identiteit en rollen
Gebruikers dragen rollen op applicatieniveau. Bij elke request worden die vertaald naar de volledige set concrete rechten die de betrokken modules hebben gedefinieerd. Code controleert vervolgens altijd op die fijnmazige module-rechten, nooit op een grofmazige “is dit een admin?”-vraag. Het resultaat is dat rechten centraal en consistent worden uitgerekend, en dat een nieuwe capaciteit toevoegen neerkomt op het declareren van een recht, niet op het verspreiden van controles door de hele codebase.
Databasebeveiliging in lagen
De data zelf wordt op vier elkaar versterkende lagen beschermd, alle in de applicatie afgedwongen:
Toegangsregels zijn additief: een rij is zichtbaar als een toepasselijke regel dat toestaat. Geldt er geen enkele regel, dan is er geen toegang. Gevoelige kolommen, zoals API-sleutels en OAuth-geheimen, worden bovendien versleuteld opgeslagen (AES-256-GCM), zodat ze ook bij directe databasetoegang onleesbaar blijven.
Kwaliteit op AI-snelheid
De terechte vraag bij AI-gegenereerde code is of die te vertrouwen is. AAD beantwoordt dat niet met vertrouwen in het model, maar met een keten van geautomatiseerde poorten. Of code nu door een mens of door een agent is geschreven maakt niet uit: hij passeert dezelfde controles, en niets bereikt productie dat ze niet allemaal haalt.
Het netto-effect: consistente kwaliteit bij hoge snelheid. De snelheid komt niet ten koste van de betrouwbaarheid, want de betrouwbaarheid is geen menselijke discipline maar een eigenschap van het systeem.
Beveiliging van acties
Elk endpoint declareert wie het mag aanroepen, eventueel met aanvullende voorwaarden op het verzoek zelf (bijvoorbeeld “alleen als het de eigen gegevens van de gebruiker betreft”). Die controle gebeurt vóór de handler draait, zodat de bedrijfslogica niet bezaaid hoeft te worden met eigen veiligheidschecks. Achtergrondtaken, die geen gebruikerssessie hebben, draaien onder een afgebakende systeemidentiteit en worden bij het opstarten gevalideerd: klopt de rechtenverklaring niet, dan start de applicatie niet. Zo wordt afwijking vroeg gevangen in plaats van in productie.
De kern: Standaard weigeren, fijnmazig verlenen, en op elke laag afdwingen. Authenticatie, toegangscontrole en auditing komen uit de gedeelde pakketten, zodat elke applicatie aan dezelfde standaard voldoet in plaats van afhankelijk te zijn van of één project het goed heeft gedaan.
Hoe het bouwen werkt
Bouwen met AAD voelt vertrouwd voor wie met een visueel ontwikkelplatform heeft gewerkt. Het begint vanuit een sjabloon, de structuur van een functie wordt gegenereerd, de gewenste functionaliteit wordt in gewone taal beschreven, en de tooling houdt de kwaliteit hoog. De rol van de ontwikkelaar verschuift van zelf code schrijven naar de agent aansturen en de uitkomsten valideren, net zoals een platformontwikkelaar vandaag modules configureert en pagina’s bouwt, maar met de volle kracht van echte code eronder.
- Start vanuit de Base. Het project wordt geforkt en in minuten ingericht, met de ontwikkelomgeving en alle infrastructuur klaar voor gebruik.
- Genereer een module. Eén commando zet een nieuw functiegebied op: zijn data, zijn schermen, zijn vertalingen en zijn toegangsregels, allemaal bedraad en volgens de conventies.
- Beschrijf wat nodig is. In gewone taal, bijvoorbeeld: “voeg een statusveld toe aan orders met de waarden concept, ingediend, goedgekeurd en afgewezen. Admins zien alle orders, gebruikers alleen die van henzelf.”
- De agent schrijft de code. De agent kent de conventies en patronen en produceert de datawijzigingen, de backend, de schermen, de vertalingen en de toegangsregels.
- Geautomatiseerde controles valideren het werk. Kwaliteitsregels, typecontrole, reviewstappen en tests bevestigen dat de functie de standaarden volgt en daadwerkelijk werkt.
- Ship het. De geautomatiseerde pijplijn draait alle controles en de functie wordt uitgerold, in uren in plaats van weken.
Wat dit mogelijk maakt is niet “AI die code schrijft”, maar de combinatie: een goed gestructureerde, goed gedocumenteerde basis waarin de agent duidelijke patronen heeft om te volgen; conventie-afdwingende tools die afwijkingen vangen; generatoren die nieuwe modules correct laten beginnen; een designsysteem met catalogus; en gedeelde pakketten die de moeilijke problemen al hebben opgelost.
Hosting, deployment en portabiliteit
Een AAD-applicatie is een standaard webapplicatie die in containers draait. Hetzelfde container-image draait, zonder codewijziging, in een eigen cloud of op door Ciphix beheerde infrastructuur. Dat is een bewuste ontwerpkeuze: de applicatie heeft geen afhankelijkheid van haar hostingomgeving buiten de gewone bouwstenen (een database, objectopslag en een container-runtime).
Ciphix Cloud (beheerde hosting)
Voor organisaties die de infrastructuur liever niet zelf beheren, draait Ciphix Cloud op EU-infrastructuur. Het platform is multi-tenant, maar data is fysiek gescheiden, niet slechts logisch gefilterd. Elke omgeving krijgt:
- een eigen, geïsoleerde werkruimte op een beheerd Kubernetes-cluster, met netwerkbeleid dat omgevingen op kernelniveau van elkaar scheidt;
- een eigen, dedicated PostgreSQL-database;
- eigen objectopslag voor bestanden;
- eigen encryptiesleutels.
Geen enkele applicatie-query kan bij de data van een andere tenant, omdat die data in gescheiden opslag leeft. De infrastructuur draait in AWS Frankfurt, verdeeld over drie onafhankelijke beschikbaarheidszones, zodat het platform doordraait als één zone uitvalt. Alle data is versleuteld in transit (TLS) en at rest; back-ups draaien automatisch met herstel naar een tijdstip. Een aparte beheerlaag (de Portal, zelf op AAD gebouwd) regelt het inrichten van omgevingen en het uitrollen van releases, gescheiden van de draaiende applicaties.
Omgevingen worden per stuk afgenomen (bijvoorbeeld test en productie) in verschillende formaten, met optionele uitbreidingen voor hoge beschikbaarheid en regionale uitwijk. Voor wie zwaardere eisen aan datasoevereiniteit stelt, is een variant in EU-jurisdictie zonder Amerikaanse extraterritoriale reikwijdte voorzien.
Eigen beheer (self-hosted)
De applicatie kan ook in een eigen cloud-abonnement draaien (Azure, AWS, of elk container-platform), met volledige controle over infrastructuur, netwerkbeleid en beveiligingsconfiguratie. Ciphix levert de container-images en infrastructuursjablonen. PostgreSQL is standaard, dus elke beheerde databasedienst voldoet, net als een zelf gedraaide instantie. Optioneel beheert Ciphix de operatie via gedelegeerde toegang, terwijl het eigenaarschap bij de organisatie blijft.
Portabiliteit: Geen technische barrière om te wisselen: hetzelfde image draait in beide modellen. Beginnen op Ciphix Cloud voor snelheid en eenvoud en later verhuizen naar eigen infrastructuur kan, net als andersom. Schakelen vereist geen aanpassing aan de code.
Eigenaarschap en geen lock-in
Dit is waar AAD fundamenteel verschilt van een gesloten platform. De applicatie is standaard TypeScript, Vue en PostgreSQL, draaiend in Docker-containers. Er is geen proprietary runtime, geen licentiesleutel, geen kill switch. De gevolgen zijn concreet:
Wordt het onderhoud niet verlengd, dan blijft de applicatie werken. Niets stopt, niets degradeert. De organisatie ontvangt een volledige broncode-kopie van alle platformpakketten op hun huidige versie, zodat elk gekwalificeerd ontwikkelteam de applicatie zelfstandig kan onderhouden. Wat vervalt is de toegang tot toekomstige updates, niet tot wat al is gebouwd. De prikkel om te verlengen is de waarde die we blijven leveren, niet een afhankelijkheid die in de architectuur is ingebouwd.
Omdat de organisatie de code bezit en op eigen infrastructuur kan draaien, is er ook geen afhankelijkheid van de compliance-roadmap van een leverancier. Specifieke beveiligings- of compliance-eisen kunnen direct in de applicatie worden gerealiseerd, zonder te wachten op een feature-request bij een platformleverancier.
Samengevat
- Eén voorspelbare vorm. Elke applicatie deelt dezelfde architectuur: gedeelde datacontracten, een centrale toegangslaag en herbruikbare bouwstenen.
- Modules bezitten hun eigen beveiliging. Rollen, regels, data en endpoints leven bij elkaar, niet in een centrale configuratie.
- Defense in depth, standaard weigeren. Toegang wordt fijnmazig verleend en op meerdere onafhankelijke lagen afgedwongen; gevoelige velden zijn versleuteld.
- Kwaliteit is een systeemeigenschap. Mens of AI: dezelfde geautomatiseerde poorten, niets bereikt productie zonder ze te halen.
- Draagbaar en in eigendom. Standaard code in containers, geen proprietary runtime, geen kosten per gebruiker, en een gegarandeerde uitweg.
Klaar om dieper te kijken?
Meer weten over hoe de architectuur zich verhoudt tot een concrete situatie, over de migratie-opties, of het platform in actie zien? Ciphix denkt graag mee over de specifieke use case.
Wij horen graag van jou!
Sprint 0
Aanpak op maat
Resultaten
De vragen die je waarschijnlijk hebt
Zijn we niet afhankelijk van jullie als dit eenmaal gebouwd is?
Nee. De software is volledig van jou, standaard code die elk gekwalificeerd development team kan overnemen. Je bent niet afhankelijk van Ciphix. Stop je met het onderhoudspakket, dan blijft de applicatie gewoon draaien.
Hoe voorkomen we dat het project uitloopt?
Elk traject begint met Sprint 0, scope en prioriteiten worden vastgesteld vóórdat de bouw begint. De iteratieve aanpak zorgt dat je continu werkende software ziet en op elk moment kunt bijsturen.
Is AI-gegenereerde code betrouwbaar genoeg voor bedrijfskritische software?
Kwaliteit is geen kwestie van vertrouwen, het is een kwestie van controle. Alle output wordt automatisch gecontroleerd op kwaliteit en veiligheid voordat het productie bereikt. De snelheid zit in het elimineren van repetitief werk, niet in het overslaan van kwaliteitsstappen.
We werken al met platformen. Moeten we die vervangen?
Nee. AAD vervangt je bestaande IT-landschap niet, het vult het aan. Bestaande systemen en platformen blijven intact. Welke applicaties baat hebben bij AAD, bepaal je zelf, wij helpen die vraag scherp te stellen.
Hoe weten we dat we het juiste bouwen?
Door te beginnen met Sprint 0. Niet met technologie, maar met het probleem. Wat wil je bereiken? Is maatwerk de juiste keuze of is er een betere weg? Pas als die vragen beantwoord zijn, beginnen we met bouwen.
