Whitepaper: the new economics of software
Hoe AI-codeeragents en Agentic Application Development veranderen hoe snel enterprise-software er is, wat die kost en wie hem bezit. In volledig eigenaarschap en zonder lock-in.
Sneller is niet het interessante deel
Decennialang werd de hoeveelheid software die een organisatie kon produceren begrensd door één ding: het aantal goede ontwikkelaars dat ze kon vinden, en de uren die zij konden maken. Die grens verschuift. AI-codeeragents produceren werkende software, en ze doen het sneller dan mensen.
Voor een board is de vraag daarom niet langer of dit echt is, dat is het al, maar hoe je de winst pakt zonder er nieuwe afhankelijkheden voor terug te krijgen. Dit document beantwoordt die vraag vanuit strategisch perspectief: wat de komst van capabele AI-agents betekent voor wat een organisatie bouwt, wat het kost en welke risico’s ermee meekomen. In gewone taal, en onderweg gaat het in op de zorgen die in dit stadium terecht meespelen.
In één zin:
Met AI-agents die binnen strakke kaders werken, bouwt één persoon meer en geavanceerdere software dan ooit, op hogere en constantere kwaliteit, tegen lagere kosten. En het resultaat is standaardsoftware die de organisatie volledig bezit.
Wat er echt verschuift
Het is verleidelijk om de komst van AI-agents te lezen als “de computer schrijft nu de code”. Dat klopt, maar het is niet het interessante deel. Het interessante deel is de hefboom eronder.
Tot voor kort deed een ontwikkelaar één ding tegelijk. Nu stuurt diezelfde persoon meerdere agents tegelijk aan, die parallel aan verschillende onderdelen werken. Denk aan een dirigent met een orkest, of een teamlead die een team aanstuurt, met dit verschil: de spelers worden niet moe, verliezen hun concentratie niet, en werken door de nacht heen als het moet. De mens blijft stevig aan het roer. Die bepaalt wat er moet komen, beoordeelt wat er terugkomt, en neemt de beslissingen. Wat verandert is hoeveel werk er tegelijk vordert onder die aansturing.
Sneller. De agent doet het schrijfwerk dat vroeger uren of dagen kostte. En sneller in het kwadraat, omdat één persoon niet één maar meerdere van die agents tegelijk aanstuurt.
Goedkoper. De output per medewerker stijgt fundamenteel, en de kosten van software zijn grotendeels arbeidskosten.
Snelheid alleen is echter een valkuil. Software die snel maar slordig ontstaat, betaalt zichzelf later met rente terug, in storingen, datalekken en beheer. De echte vraag aan de bestuurstafel is dus niet of het sneller kan, maar of het sneller én beter kan. Precies dat is waar de rest van dit document over gaat.
Waarom gecontroleerde agents beter werk leveren dan mensen
Dit is de meest contra-intuïtieve claim in dit document, dus laten we er eerlijk over zijn. De claim is niet dat een AI-model slimmer is dan de beste engineer in huis. Op losse momenten is dat misschien niet zo. De claim gaat over consistentie.
Mensen zijn briljant, maar wisselvallig. Onder tijdsdruk wordt een test overgeslagen, een beveiligingscheck vergeten, of documentatie uitgesteld tot een “later” dat nooit komt. De ene ontwikkelaar is grondiger dan de andere. Dezelfde ontwikkelaar is op vrijdagmiddag minder scherp dan op dinsdagochtend. In grote organisaties is softwarekwaliteit in de praktijk dus een gemiddelde van wisselende menselijke discipline.
Een goed gecontroleerd agent-systeem haalt die variatie eruit. Het past bij elke wijziging dezelfde striktheid toe, elke keer weer. Tests worden altijd geschreven. Beveiligingspatronen worden nooit overgeslagen. Documentatie ontstaat vanzelf, niet als er tijd voor is. De discipline die zelfs goede teams moeilijk volhouden, wordt een automatische eigenschap van het systeem.
De woorden die al het gewicht dragen zijn “met de juiste controles”. Ongecontroleerde AI die zomaar code uitspuugt is echt een risico, en wie iets anders beweert verkoopt een illusie. Het antwoord van AAD is even eenvoudig als streng: elke wijziging, of die nu van een mens of een agent komt, passeert dezelfde geautomatiseerde poorten voordat hij in productie mag. Niets dat die controles niet haalt, bereikt de gebruikers.
De vier dingen die die poorten bewaken
- Kwaliteit. Vaste architectuurregels en strikte controles zorgen dat elke wijziging de afgesproken structuur volgt. Afwijkingen worden geblokkeerd, niet bediscussieerd.
- Beveiliging. Het startpunt is “standaard weigeren”: toegang ontstaat alleen waar een regel die expliciet verleent, afgedwongen op meerdere onafhankelijke lagen, zodat één fout niet meteen een datalek wordt.
- Testen. Geautomatiseerde tests controleren zowel de losse onderdelen als complete functies vanuit het perspectief van de gebruiker, bij elke wijziging opnieuw.
- Documentatie. Omdat de agent binnen vaste patronen werkt en zijn werk vastlegt, blijft de software leesbaar en overdraagbaar, in plaats van een doolhof te worden dat alleen de oorspronkelijke auteur begrijpt
De verschuiving. Wie de code schreef, bepaalt de kwaliteit niet meer. Kwaliteit is een eigenschap van de keten geworden. Hoge snelheid én constante kwaliteit, omdat betrouwbaarheid niet meer afhangt van menselijke discipline.
Meer, geavanceerder, voor minder
Als één persoon meer werk verzet en kwaliteit een systeemeigenschap is, verschuift de economie van software op een manier die direct de bottom line raakt. Vijf effecten versterken elkaar.
- Het repetitieve werk verdwijnt. Elke applicatie heeft hetzelfde fundament nodig: inloggen, rechten, data, e-mail, beheer. In AAD wordt dat één keer goed gebouwd en elke keer hergebruikt. De investering gaat naar wat een applicatie uniek maakt.
- De hefboom van meerdere agents. Eén persoon levert de output van wat vroeger een team was, zonder de coördinatielast van dat team.
- Geen afhankelijkheid van schaars talent. AAD draait op gangbare, breed gedragen technologie. Geen afhankelijkheid van een kleine groep gecertificeerde specialisten, maar toegang tot een wereldwijde community van ontwikkelaars.
- Geen kosten per gebruiker. Of een applicatie tien of tienduizend mensen bedient, er hangt geen licentieprijs aan. Succes wordt niet bestraft.
- Software die met je meegroeit in plaats van veroudert. De applicatie blijft actueel door onderhoud, in plaats van langzaam legacy te worden die binnen een paar jaar herbouwd moet worden.
Samen verandert dit niet alleen de prijs, maar ook wat de moeite waard is om te bouwen. Software die eerder werd weggelegd als te duur of te ambitieus komt binnen bereik. Maatwerk waar een organisatie eerder genoegen moest nemen met een standaardpakket dat net niet paste. De grens van wat verstandig is om zelf te laten bouwen verschuift, en in de goede richting.
De bold companies die nú de juiste keuzes maken, worden de koplopers van morgen
Hoe AAD dit op koers houdt
De techniek hoeft niet leesbaar te zijn om te kunnen beoordelen of dit verantwoord is. Drie ideeën volstaan.
Het begint nooit bij een blanco pagina. Elke AAD-applicatie start vanaf de Ciphix Base: een productieklaar fundament dat alles bevat wat een bedrijfsapplicatie nodig heeft, nog vóór de eerste regel bedrijfslogica. Niemand bouwt elke keer een auto uit ruwe plaatstaal; het werk start vanaf een beproefd chassis, waarna alleen wordt toegevoegd wat deze auto bijzonder maakt. De Base is dat chassis. Inloggen, beveiliging, databeheer en meer zijn al opgelost en al getest.
De agent werkt binnen kaders, niet vrij. Omdat het fundament een vaste structuur en vaste conventies heeft, schrijft de agent geen willekeurige code op een blanco pagina, maar volgt hij een duidelijke kaart. Hij weet welke patronen gelden, welke beveiligingsregels van kracht zijn, en aan welke standaard hij moet voldoen. Dat is het verschil tussen “AI die iets verzint” en “AI die binnen een betrouwbaar systeem werkt”.
Regels worden afgedwongen, niet afgesproken. De kwaliteits-, beveiligings- en architectuurregels zijn in de tooling ingebakken, niet vastgelegd in een document dat iemand hoort te volgen. Afdwinging gebeurt automatisch en is niet onderhandelbaar. Een wijziging die de regels niet haalt komt simpelweg niet door de poort, ongeacht wie of wat hem maakte.
De kern. De snelheid komt niet uit het overslaan van stappen, en de kwaliteit komt niet van individuele helden. Beide komen uit een goed ontworpen systeem dat het zware werk overneemt en de standaard bewaakt.
De zorgen die bij dit tijdperk horen
Een nieuwe manier van bouwen verdient gezonde scepsis. Hieronder de vragen die in elke boardroom opkomen, met eerlijke antwoorden.
“Kunnen we code die door AI is geschreven wel echt vertrouwen?” Het vertrouwen hoeft niet bij het model te zitten, maar bij het systeem eromheen. Elke wijziging passeert dezelfde geautomatiseerde controles, of die nu van een mens of een agent komt. Wat door de poort komt voldoet aan de standaard; wat niet voldoet, komt er niet door.
“Zetten we niet in op een hype die ons over drie jaar met onbruikbare code achterlaat?” De output van AAD is geen exotische technologie, maar de meest voorkomende bouwstenen van moderne webontwikkeling: standaard code die elke ontwikkelaar herkent. Die code hangt niet af van welk AI-model hem schreef. Het is geen gok op een mode. Het is een bezit dat losstaat van de grillen van welke leverancier dan ook.
“Worden we afhankelijk van één AI-leverancier?” Nee. De agents zijn gereedschap, niet het product. Het product is gewone software, die morgen door een ander model, een ander team of een andere tool kan worden doorontwikkeld. Het platform werkt met meerdere AI-leveranciers naast elkaar. De code overleeft elk model.
“Wat betekent dit voor de mensen in de organisatie?” Hun rol stijgt, in plaats van te verdwijnen. Waarde verschuift van zelf code typen naar agents aansturen en de uitkomst beoordelen. Domeinkennis, de business, de data, de gebruikers, wordt belangrijker in plaats van minder belangrijk. Consultants die vandaag productief zijn op een low-code-platform kunnen meteen instappen.
“Is dit veilig en compliant genoeg voor onze sector?” Beveiliging zit in het fundament, niet als laagje erbovenop, en wordt op meerdere lagen afgedwongen. Omdat de organisatie de code bezit en op eigen infrastructuur kan draaien, is ze ook niet afhankelijk van de compliance-planning van een leverancier. Stelt een toezichthouder een specifieke eis, dan is het antwoord “dat bouwen we in”, niet “dat zetten we op de wensenlijst van de vendor”.
“Als AI programmeren goedkoop maakt, waarom is Ciphix dan nog nodig?” Het eerlijke antwoord: het ruwe model is een commodity geworden, en dat is een goede zaak. De blijvende waarde zit in het gecontroleerde platform eromheen: de kaders, de geautomatiseerde poorten, de gedeelde bouwstenen die de moeilijke problemen al hebben opgelost, en het onderhoud dat de applicatie actueel houdt. Ciphix verdient een verlenging met de waarde die het blijft leveren, niet met een afhankelijkheid die in de architectuur verstopt zit.
Het modulesysteem
Veel van het bovenstaande is een impliciete vergelijking met low-code-platforms, dus het is goed om die vergelijking expliciet en eerlijk te maken.
Low-code-platforms zoals Mendix, OutSystems en Power Apps zijn succesvol geworden om een echte reden: ze maakten applicatieontwikkeling toegankelijk voor mensen die geen traditionele software-engineers waren. Voor rechttoe rechtaan CRUD-applicaties, interne tools en snel prototypen blijven ze effectief, en niets hier bestrijdt dat.
Maar enterprise-applicaties blijven zelden rechttoe rechtaan. Ze stapelen maatwerkintegraties, genuanceerde bedrijfsregels, wettelijke eisen en prestatie-eisen op. Daar komen vier beperkingen boven water.
Het aanpassingsplafond. Elk low-code-platform heeft er een. Zodra de eisen verder gaan dan wat de visuele builder ondersteunt, zijn de opties platformspecifieke extensies binnen een afgebakende sandbox (Java-actions in Mendix, C# in OutSystems), of te horen krijgen dat het niet wordt ondersteund. Bij AAD is er geen plafond: als het in code kan, kan het in de applicatie.
De abstractiebelasting. Microflows, nanoflows, domeinmodellen en marketplace-modules versnellen eenvoudige gevallen en worden beperkingen in complexe. De abstracties van AAD zijn standaard programmeerpatronen, gedocumenteerd door de hele software-industrie in plaats van door één leverancier.
Het licentiemodel. Low-code-prijzen schalen doorgaans mee met gebruikers, omgevingen, of beide. Dat creëert een perverse prikkel: organisaties beperken toegang om kosten te beheersen, in plaats van toegang te verbreden om waarde te creëren.
De lock-in-realiteit. Een Mendix-applicatie draait op Mendix; een OutSystems-applicatie draait op OutSystems. De investering in het bouwen van de applicatie wordt een permanente verbintenis met de prijzen en de roadmap van die leverancier.
Recent veranderd. Migreren weg van Mendix was vroeger zo goed als onmogelijk: de applicatielogica zat in binaire bestanden die geen enkele externe tool kon lezen. De eigen CLI-tooling van Mendix ontsluit dat model nu als gestructureerde tekst, wat betekent dat AI-agents een bestaande Mendix-applicatie kunnen lezen en een equivalente implementatie kunnen genereren. Een uitweg die er eerder niet was, is er nu wel.
Naast elkaar gezet
Geen lock-in: eigenaarschap als principe
Dit is waar AAD fundamenteel verschilt van een gesloten platform, en het verdient de aandacht van elke bestuurder die ooit vastzat in een leverancierscontract. Er zijn twee soorten afhankelijkheid die je hier niet aangaat.
Geen platform-lock-in. De applicatie is standaardsoftware die in containers draait. Er is geen proprietary runtime, geen licentiesleutel, geen knop waarmee een leverancier de boel kan stilleggen.
Geen AI-lock-in. De agents die de software schreven zijn inwisselbaar gereedschap; het eindproduct is leesbare, gewone code die niet afhangt van welk model hem produceerde.
De gevolgen zijn concreet.
Wordt het onderhoud niet verlengd, dan blijft de applicatie gewoon werken. Niets stopt, niets degradeert. De organisatie ontvangt een volledige kopie van de broncode op de huidige versie, zodat elk gekwalificeerd team de applicatie zelfstandig kan voortzetten. Wat vervalt is de toegang tot toekomstige verbeteringen, niet de toegang tot wat al is gebouwd. De relatie blijft daarmee eerlijk: je blijft omdat het loont, niet omdat het moet.
De strategische keuze
Waarom nu? Omdat drie ontwikkelingen tegelijk samenkomen. AI-codeeragents hebben productiekwaliteit bereikt: in 2023 waren ze een noviteit, handig voor autocomplete maar niet vertrouwd met productielogica; vandaag produceren ze complete functies, houden ze architecturale context vast, en volgen ze complexe conventies betrouwbaar. De economie van low-code staat onder druk, nu de snelheid die daar tegen een premie werd gekocht ook op een open manier beschikbaar is. En de eisen van organisaties rond datasoevereiniteit, integraties en beveiliging bewegen sneller dan de roadmaps van platformleveranciers ze kunnen invullen.
Tegen die achtergrond is elke nieuwe applicatie op een gesloten platform een toekomstig migratieproject. AAD levert het omgekeerde: een bezit dat aangroeit. Standaard code die elk team jarenlang kan onderhouden, uitbreiden en draaiend houden, in plaats van software die uiteindelijk vervangen of afgeschreven moet worden.
Klein beginnen. Dit is een keuze op bestuursniveau, omdat ze raakt aan hoe een organisatie de komende tien jaar software gaat bouwen, wat dat kost, en waar de controle ligt. Geruststellend: je hoeft niet meteen een hele organisatie te committeren. Eén applicatie is genoeg om het van dichtbij te zien.
Zes punten om mee te nemen
- De economie verandert. AI-agents schrijven sneller dan mensen, en één persoon stuurt er meerdere tegelijk aan. De output per medewerker stijgt fundamenteel.
- Kwaliteit wordt een systeemeigenschap. Met de juiste controles leveren agents consistenter werk dan mensen, omdat tests, beveiliging en documentatie automatisch worden afgedwongen in plaats van af te hangen van discipline.
- Meer voor minder. Minder repetitief werk, een bredere talentmarkt en geen kosten per gebruiker verschuiven de grens van wat de moeite waard is om te bouwen.
- Low-code heeft een plafond; AAD niet. Het aanpassingsplafond, de abstractiebelasting, licenties per gebruiker en lock-in zijn structureel voor die platforms, niet toevallig.
- Begrijpelijk en beheersbaar. Een productieklaar fundament, agents die binnen kaders werken, en regels die worden afgedwongen in plaats van afgesproken.
- In eigendom, zonder lock-in. Standaard code zonder proprietary runtime en zonder afhankelijkheid van één AI-leverancier. De organisatie bezit wat ze bouwt, met 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
