← Alle inzichten

Architectuur met AI: standaarden in weken, adoptie blijft mensenwerk

Jacques Domenie · 7 oktober 2026 · 7 min lezen

AI kan in een dag een architectuurstandaard schrijven. Of je daar iets aan hebt, hangt af van de regels eromheen, en van het deel dat AI niet kan: zorgen dat mensen de standaard gebruiken.

Softwareontwikkelaars hebben deze discussie al gevoerd. In februari 2025 gaf AI-onderzoeker Andrej Karpathy een nieuwe manier van programmeren een naam: vibe coding. Je beschrijft wat je wilt, accepteert wat de AI maakt en leest de code niet meer. Acht maanden later gaf ontwikkelaar Simon Willison het tegenovergestelde een naam: vibe engineering. Ervaren engineers gebruiken dezelfde tools met dezelfde snelheid, maar met tests, specificaties, versiebeheer en review, en ze blijven verantwoordelijk voor de software die ze opleveren. Zijn punt was dat AI de discipline beloont die ervaren engineers al hebben.

Architectuur kent dezelfde splitsing, en daar weegt die zwaarder. Anderen gebruiken al de termen vibe architecture en vibe architecting voor architectuurkeuzes die AI of een prompt ter plekke maakt, zonder doordacht ontwerp. Slechte code komt niet door de test. Slechte architectuur leest goed en wordt goedgekeurd.

Wat er verandert als het schrijven een dag kost

In de architectuurfuncties die ik leidde voordat ik zo ging werken, kostte een set organisatiebrede architectuurprincipes naar mijn schatting zes tot acht maanden van eerste versie tot goedkeuring. Een enkele standaard kostte vier tot zes maanden. De meeste tijd ging op aan schrijven, feedback verwerken en het document consistent houden met al het andere. Intussen verschoof de grond: de technologie veranderde, de business veranderde, mensen vertrokken, en nieuwe opvattingen trokken het document een andere kant op.

In mijn ervaring schrijf ik met AI en onder strikte regels de eerste versie van een set principes of een standaard nu in minder dan een dag. Elke feedbackronde levert binnen een paar uur een bijgewerkte versie op. De hele cyclus, inclusief goedkeuring, kost weken tot een maand. Mijn schatting is verder dat een architectuurfunctie in dezelfde periode drie tot vijf keer zoveel standaarden kan opleveren. Daarin vergelijk ik verschillende organisaties en rollen, dus het is een ruwe schatting.

De grotere winst is dat een document dat in weken is geschreven nog actueel is als het wordt goedgekeurd. En de oude klacht van het management, dat architectuur eindeloos duurt terwijl de business door moet, houdt geen stand meer. In mijn ervaring is architectuur niet langer het knelpunt om een standaard goedgekeurd te krijgen, ook niet het vermeende knelpunt.

De regels die de snelheid bruikbaar maken

AI zit er vaak naast. De mens ook. Samenwerken betekent niet dat je blind op elkaars werk vertrouwt. Zonder afgesproken controlemomenten blijft het resultaat steeds achter bij wat er verwacht werd, en een prompt alleen bevat zelden genoeg context.

Een klein voorbeeld. In architectuurpresentaties schreef de AI steeds koppen die klonken als verkooptekst en voor het publiek niets betekenden. We stelden een regel op: beschrijvende, neutrale titels. De regel helpt, en we corrigeren de koppen nog steeds keer op keer. De eerste presentatie in het juiste sjabloon kostte dagen en veel rondes; een presentatie kost nu ongeveer een uur. Het verschil kwam van de regels en van het leren aan beide kanten. De fouten die zwaarder wegen zitten in de inhoud, en die zijn de reden voor de reviewregel.

De regels die ik niet zou opgeven:

  • Controlemomenten en validaties, afgesproken voordat het werk begint.
  • Niets gaat de deur uit zonder review.
  • Klantmateriaal blijft lokaal. Eerst de beveiligingsregels, dan de snelheid.
  • Itereren tot het goed is, en vasthouden wat beide kanten leerden, zodat de volgende ronde sneller gaat.

Die regels bedoel ik met AI-engineered architecture: architectuur die onder vaste regels met AI wordt gemaakt. De engineering zit in de voorwaarden die je vooraf kunt controleren: principes en standaarden die zijn opgeschreven en onder versiebeheer staan, een besluitenregister, een benoemde reviewstap, een veilige werkomgeving, en vooral een architectuurfunctie met een mandaat en een besluitvormend gremium dat kan goedkeuren wat er wordt geschreven. Waar die voorwaarden ontbreken, maakt AI alleen vibe architecture sneller.

Wat AI-engineered architecture een CTO oplevert

Zodra de standaarden er zijn, wordt toetsen aan die standaarden goedkoop. Een team vraagt om een oplossingsvalidatie; een optie voor de toekomstige situatie moet kritisch worden bekeken; het management wil weten wat een hypothese zou breken. Vroeger moesten die toetsen strijden om weken architectentijd. Met de standaarden op papier en AI die het leeswerk doet, verwacht ik dat ze dagen kosten in plaats van weken, vroeg genoeg om mee te wegen in het besluit, voordat er geld wordt vastgelegd. Gemeten heb ik dat nog niet.

Eén geval laat zien waarom toetsen vóór de investering ertoe doet. Data moest tussen twee interne platforms worden uitgewisseld. Architectuur liet vooraf zien hoe het volgens de standaarden moest, en hoe de cloudleverancier het zelf voorschrijft. De druk was groot om de data precies volgens de specificatie te leveren, en er werd toch een maatwerkoplossing gebouwd. Die werkte, doorstond de tests en ging live. Toen werden de lopende kosten zichtbaar, en het management trok de stekker eruit. Volgens de eigen berekening van architectuur had de standaardaanpak ongeveer een tiende gekost, en was die betrouwbaarder en beter te onderhouden geweest. Het alternatief lag op tafel en verloor toch; een beter kostenmodel vooraf had dat misschien veranderd, en ik kan niet aantonen dat het zo was gegaan. In dit geval is geen AI gebruikt. Met AI kun je dezelfde scenario's en hun kostenberekeningen veel sneller doorspelen, vroeg genoeg om het kostenargument vóór het besluit op tafel te leggen.

Wat AI niet doet

Het schrijven van de standaarden was nooit het moeilijkste deel. Het moeilijkste is zorgen dat mensen ze gebruiken. Ik werkte mee aan een set organisatiebrede architectuurprincipes. Toen die set was goedgekeurd, gingen de architecten de principes niet uit zichzelf toepassen. Ze hadden sessies nodig, oefening, coaching, correctie, aanmoediging en een stevige hand, en vooral moesten ze begrijpen waarom. Niets daarvan kan AI doen; zo leren mensen een nieuwe manier van werken.

Documenten zijn de voorwaarde voor volwassenheid; het gebruik ervan is de maat. Onderzoekers hebben het gebruik van enterprise-architectuur al eerder bestudeerd, en TOGAF, het architectuurraamwerk van The Open Group, kent compliance reviews. Ik zou het scherper maken. Tel de belangrijke besluiten en oplossingsvalidaties waarin een benoemd principe of een benoemde standaard de uitkomst aantoonbaar veranderde. Tel alleen die waarin iemand anders dan de auteur het inbracht. Alleen verwijzingen tellen zou uitnodigen tot afvinkgedrag; daarom vraagt de maat om een veranderde uitkomst.

Nog twee dingen blijven mensenwerk. Het eerste is oordeel: de politiek, de relaties met stakeholders, en de plotselinge veranderingen door wat mensen doen. Het tweede is eigenaarschap. Alles wat zo wordt gebouwd, moet eigendom worden van de architectuurfunctie die het gebruikt, zodat het blijft als de architect die het bouwde vertrekt. Mijn regel is dat het hoofd architectuur en het team binnen zes maanden eigenaar zijn van alles.

Wat dit niet bewijst

Dit rust op mijn eigen werk en één lopende opdracht, afgezet tegen mijn eigen eerdere manier van werken. Er zijn serieuze alternatieve verklaringen. De snelheid kan komen van discipline die er al was, met AI als snelle lezer van goed bijgehouden materiaal. En een ervaren architect was hoe dan ook sneller geweest; een deel van mijn versnelling komt van vele jaren praktijk. Met alleen mijn eigen werk als bron kan ik die niet uit elkaar halen. Mijn werkhypothese is dat de methode er eerst moet zijn, en dat AI daarna vermenigvuldigt wat die oplevert.

Architectuur-repositorytools, waarin een team zijn modellen en overzichten bijhoudt, bewaren die inhoud en helpen bij de analyse, maar ze zijn er niet voor gemaakt om de eigen principes en standaarden van een architectuurfunctie te schrijven. In softwarearchitectuur dekken twee werkwijzen hier al delen van af: fitness functions, controles (meestal geautomatiseerd) of een systeem zich nog aan een architectuurregel houdt, en architecture decision records, korte genummerde vastleggingen van één besluit. In de rest van het architectuurvak zijn ze veel minder ingeburgerd, en daar zie ik het gat. De publicaties over AI in architectuur die ik vond, gaan over het genereren van modellen, views en besluitvastlegging, of over het analyseren van bestaande documenten; geen ervan gaat over een architectuurfunctie die haar eigen principes en standaarden schrijft.

Waar begin je?

Kies één standaard waar je teams steeds naar vragen en die nooit is opgeschreven, bij een architectuurfunctie met een gremium dat hem kan goedkeuren. Schrijf eerst de spelregels op: wat wordt gecontroleerd, wie reviewt, wat binnen blijft. Schrijf de standaard daarna in een dag met AI, en besteed de gewonnen weken aan de sessies die zorgen dat hij gebruikt wordt.

Jacques Domenie leidde de IT-functie van een bank onder toezicht van de centrale bank en legde verantwoording af aan bestuur, toezichthouders en accountant. Via Delfen (delfen.com) werkt hij een deel van de week voor organisaties.

Contact: domenie@delfen.com of delfen.com/nl/contact.

Bronnen

Herkent u dit vraagstuk in uw eigen organisatie? Dan is dat een gesprek waard.

Neem contact op