Ik zit al twee maanden op iets bijzonders, en ik krijg het niet uitgelegd.

Dat is een rare zin om mee te beginnen. Normaal gesproken weet ik precies hoe ik iets moet vertellen. Al dertig jaar werk ik op dezelfde manier als ik nieuwe ideeën ontwikkel: losse gedachten, veel telefoontjes, en dan kristalliseert het. Na een gesprek of dertig weet ik wat er blijft hangen, welke vragen ik kan beantwoorden, hoe ik het moet vertellen.

Maar dit keer loopt het anders.

Op plekken waar ik kom laat ik vaak één of twee van de inmiddels vijf iPhone-apps zien die ik onlangs razendsnel zelf maakte (een maand geleden had ik nog nooit geprobeerd zoiets te maken). De reactie is vrijwel altijd hetzelfde: "Wat vet ziet dit eruit." "Wat werkt dit lekker." Mensen snappen op knopjesniveau wat ik heb gebouwd. Ze zien direct waar het voor mij handig is, en vaak ook waar het voor henzelf nuttig kan zijn.

Maar dan stokt het gesprek.

Want als ik probeer uit te leggen waaróm dit bijzonder is, merk ik dat ik steeds hetzelfde verhaal vertel: kijk wat ik kan bouwen met AI. Een dark mode-knopje in drie minuten. Een werkende iPhone-app in een kwartier. Honderden uren code zonder zelf een regel te schrijven. Dat verhaal klopt. Maar het is het verkeerde verhaal.

Mark Meinema schreef er een scherp stuk over. Hij begon met de metafoor van de beroemde schilder Magritte: "We kijken niet naar een pijp, want we kijken naar een schilderij dat een pijp verbeeldt." En zo leek ons gesprek te gaan over een app, over snelle coole functies. Maar daar ging het eigenlijk helemaal niet over.

Zijn conclusie was dat ik geen app gebouwd had maar een nieuwe zienswijze had ontwikkeld over hoe je ook naar informatie kunt kijken, en wat er gebeurt als je de wanden van alle informatiesilo's rücksichtslos sloopt en dan gaat spelen met de ontketende mogelijkheden ervan.

Wat ik eigenlijk aan het doen ben, is weigeren te accepteren dat informatie opgesloten moet blijven in de gereedschappen waar het toevallig is binnengekomen. En nu ik sinds een tijd over de vaardigheden beschik om mijn eigen digitale werkgereedschap zelf te bouwen, kan ik daar ook iets aan doen.

E-mail in je mail-app. Taken in je takenlijst. Bankzaken in je bankapp. Gezondheidsdata in je gezondheidsapp. Boeken in Goodreads. Locaties in Foursquare.

We hebben geleerd om informatie te zien als iets dat thuishoort in vakjes. Maar dat is een aanname, geen natuurwet. En ik geloof er niet meer in. Nu zit informatie vast in apps. En je kunt hooguit een export doen. Maar wat als we iets kunnen doen met de relaties tussen die informatie? Want daar zit betekenis in. En veel bruikbaars.

Een banktransactie is niet alleen een bedrag in je bankapp. Het is een gebeurtenis met een datum, een locatie, een andere persoon of organisatie. Net als een lezingaanvraag. Of een etentje. Of een e-mail van een klant. Al die dingen hebben met elkaar te maken: personen, plekken, projecten, momenten. Maar omdat ze in verschillende apps zitten, zie je die verbanden nooit.

Het moment dat ik dertig jaar aan data kon verbinden die al die tijd verspreid zat over losse silo's, gebeurde er iets. Opeens praatten die dingen met elkaar.

In januari schreef ik een uitgebreide ontologie. Gewoon omdat ik voor mezelf wilde begrijpen hoe ik informatie benoem. Na twintig jaar nadenken over hoe ik entiteiten, gebeurtenissen, locaties en relaties beschrijf, documenteerde ik mijn eigen systeem. Het maken van die ontologie bood me grip en inzicht. En anderen kopieerden er voor zichzelf hele stukken van.

Wat ik deed was simpel en tegelijk fundamenteel. Ik besloot dat elke persoon die ik ontmoet een eigen pagina krijgt: 👥 Jan Janssen. Elke organisatie waar ik mee werk: 🛗 AFAS. Elke plek die ik bezoek: 🏣 voor gebouwen, 🚉 voor stations, ✈️ voor vliegvelden. Elke activiteit die ik onderneem: 🎤 voor optredens, 🍽️ voor etentjes, 👣 voor wandelingen. Entiteiten en gebeurtenissen.

Veel mensen vroegen zich toen af waarom ik toch al die moeite deed. Maar inmiddels blijkt het de motor achter de snelheid en vindbaarheid van mijn informatie.

Als ik een optreden geef bij de Erasmus Universiteit, dan linkt die pagina automatisch naar de organisatie, de locatie, de contactpersoon, het project waarvoor ik sprak, en de reacties die ik erna kreeg. Als ik een jaar later wil weten hoeveel mensen er in totaal naar mijn optredens kwamen, is dat een zoekopdracht van twee seconden. Hoeveel reacties ik kreeg op al mijn lezingen door de jaren heen? Twee seconden. Welke boeken ik dit jaar las, welke series ik keek, hoeveel ik uitgaf aan welke categorie aankopen? Twee seconden.

Voordat ik dit had, was het onmogelijk om dit soort vragen snel te beantwoorden. Nu is het triviaal.

Pas later ontdekte ik hoe sterk ontologieën en AI met elkaar verweven raken. Als je consequent beschrijft wat een persoon is, wat een locatie is, wat een gebeurtenis is, en hoe die zich tot elkaar verhouden, dan kan AI daar iets mee. Door je eigen data te structureren en interpreteerbaar te maken, kun je AI veel effectiever benutten dan anderen. Blijkbaar had ik onbewust een vooruitziende blik.

Het helpt enorm dat ik personen, locaties, bestemmingen en gebeurtenissen consequent beschrijf. Net als boeken, series en afleveringen. Alles krijgt een plek, een rol, een relatie. Niet omdat ik zo van orde hou (ik kan goed omgaan met chaos), maar omdat er betekenis ontstaat in verbindingen.

Het voelt alsof ik een fabriek heb gebouwd die steeds sneller prachtige auto's produceert. Verschillende modellen, allemaal werkend, en nog zuinig ook. Die willen wel meer mensen hebben.

Maar als het gesprek gaat over hoe die fabriek precies in elkaar zit, stokt het. Het ontbreekt me aan de juiste taal. Zelfs met ervaren programmeurs lukt het me niet goed uit te leggen wat ik nou precies heb gebouwd, of waarom het misschien bijzonder is. Die metafoor klopt, maar hij klopt om de verkeerde reden.

Ik heb geen fabriek gebouwd die auto's maakt. Ik heb een andere manier van kijken naar vervoer ontwikkeld, en de auto's zijn daar een heel bruikbaar nuttig bijproduct van.

Iemand die meedacht over deze taalpuzzel wees me op het feit dat ik eigenlijk vier verhalen tegelijk probeerde te vertellen:

Het zichtbare verhaal: kijk eens wat ik kan bouwen met AI. Apps, knopjes, dashboards, snelheid. Spectaculair, maar ook het minst interessant. Het roept bewondering op, geen begrip (en daar was ik naar op zoek, om erover te kunnen sparren).

Het onderliggende verhaal: informatieliquiditeit. Ik weiger informatie te accepteren zoals tools die hebben opgesloten. E-mail, taken, boeken, locaties, personen, geldstromen en gezondheid zijn geen app-domeinen, maar verschijningsvormen van dezelfde onderliggende werkelijkheid: gebeurtenissen, entiteiten en relaties daartussen.

Het procesverhaal: leren bouwen met AI. De-mystificatie van IT. Waarom prompten overrated is, en je vooral boerenverstand moet gebruiken en veel moet klooien en uitproberen. En hoe je audit- en controlesystemen maakt om je code te checken. Veelbelovend en een nieuw perspectief op AI dat ik niet veel hoor.

Het verhaal waar ik nu zelf in zit: ik ben geen appbouwer die toevallig in informatieliquiditeit is beland. Ik ben blijkbaar een informatiearchitect die nu voor het eerst zijn eigen gereedschap kan maken. Zonder vendor-lock-in en volledig autonoom.

Die laatste stap heb ik nog niet volledig hardop benoemd. Tot nu.

Het kan geen toeval zijn dat ik soms maar een kwartier nodig heb om een werkende app te maken die er daarvoor niet was. Dus ja, ik doe iets met code en AI. Maar wat precies?

Na een paar mislukte pogingen ben ik zo'n twintig à dertig uur met AI in gesprek gegaan. Niet over features, maar over architectuur. Over hoe je robuuste code ontwerpt. Hoe je voorkomt dat alles vervuilt en in de war raakt. Samen bouwden we een model. Sindsdien audit ik mijn code continu.

Elke dag bouw ik iets bij, en daarna vraag ik aan Claude: "Mooi dat dit werkt. Hebben we ons gehouden aan alle gedragsregels en instructies die we hebben afgesproken voor robuuste, veilige, stabiele en bloedsnelle code?" Soms doe ik dat tien keer per dag. De audit vindt hiaten, kwetsbaarheden of ontwerpfouten, en herstelt ze.

Het begon met één vraag: wat als dit honderd keer zo groot wordt? Wat als er straks vijfduizend keer zoveel data in zit? Dan maak je andere keuzes dan wanneer je even snel een leuk appje in elkaar knutselt. Dus ik rekende terug vanuit een denkbeeldige eindtoestand. Enterprise-niveau software, maar dan voor persoonlijk gebruik.

Hier zit het verhaal dat ik al een tijd probeer te vertellen maar waar ik de taal niet voor kon vinden. Niet de apps zijn bijzonder. De architectuur eronder is bijzonder. En de manier waarop ik die architectuur heb ontwikkeld en voortdurend blijf valideren.

Wat ik ontdekte: je kunt als niet-programmeur enterprise-niveau software bouwen, maar alleen als je een systeem hebt dat voortdurend checkt of wat je bouwt ook echt solide is.

Mijn audit begon als een simpele checklist. Zeventien regels waar de code aan moest voldoen. Regels over hoe je snel data ophaalt zonder de database te overbelasten. Regels die voorkomen dat kwaadwillenden je systeem kunnen hacken. Regels over hoe knoppen en formulieren met elkaar praten. Ik noemde het gekscherend "Eredivisie Light": niet de Champions League van softwareontwikkeling, maar wel een niveau waar je trots op kunt zijn.

Die zeventien regels werden er vijfenvijftig. En toen honderd. Elke keer als er iets misging, documenteerde ik wat er fout was, waarom het fout ging, hoe je het kunt detecteren, hoe je het oplost, en hoe je het voorkomt. Dat document heet "Common Pitfalls" en het is inmiddels twintigduizend regels lang 😳 Twintigduizend regels aan geleerde lessen. Elke fout die ik tijdens die vierhonderd uur bouwen maakte, vastgelegd zodat hij niet nog een keer gebeurt.

Op 24 november ging de hele navigatie van mijn systeem kapot. Alle knoppen stopten met werken, geen foutmelding, gewoon niets. Achteraf bleek dat ik per ongeluk twee dingen dezelfde naam had gegeven, en dat is in code niet toegestaan. Eén typfoutje en het hele systeem lag plat.

In een normaal ontwikkelproces zou dit een frustrerende bug zijn die je oplost en vergeet. Maar in mijn systeem werd het een nieuwe regel in de audit. "PITFALL #-1: Duplicate variable declarations break all navigation." Met detectiecommando's, oplossingen, en preventielagen.

Nu checkt mijn systeem automatisch op dubbele declaraties voordat ik iets mag opslaan. Die fout kan niet meer voorkomen. Het systeem leerde van de fout.

Dit is de cyclus die ik voortdurend volg: een nieuwe functie bouwen na een nieuw idee (de hele dag 🤣), checken of het werkt, daarna een audit doen, fouten opsporen, die oplossen en daarna documenteren hoe ik dat deed, nieuwe regels toevoegen, en dan weer bouwen.

Elke cyclus maakt het systeem sterker. Dat is waarom ik inmiddels in een kwartier een app kan bouwen die ook echt werkt. Niet omdat AI zo slim is, maar omdat ik honderden uren heb geïnvesteerd in een systeem dat voorkomt dat AI dezelfde fouten twee keer maakt. En voor elk nieuw stukje dat ik maak, vraag ik Claude Code, mijn AI-tool, die documenten door te lezen.

Afgelopen week zat ik een uurtje met Mark Vletter. Met zijn ervaring met front-end development keek hij heel anders naar mijn werk. Hij was onder de indruk van de functionaliteit en de robuustheid. Ik had al 231 keer de code gemigreerd (overhoop gehaald), zonder dat er iets stuk ging. Maar hij schoot ook een gat in mijn audit. Heel fijn! Eindelijk een echt mens die naar mijn fabriek keek en slimme dingen zei.

Mijn audit checkt voortdurend of de code de regels volgt. Maar hij checkte niet of de code goed gestructureerd was. Je kunt honderd procent compliant zijn en tegelijk een architecturele puinhoop hebben.

Mark vond dingen die ik nooit had gezien. 273 keer dezelfde opmaakregel gedefinieerd in 34 verschillende bestanden (alsof je in elk hoofdstuk van een boek opnieuw uitlegt wat cursief betekent). 26 identieke zoekfuncties, elk apart geschreven (alsof je 26 keer hetzelfde recept in je kookboek hebt staan). Eén bestand van 7.199 regels dat eigenlijk vijf kleinere bestanden had moeten zijn. 468 backup-bestanden die door de hele codebase zwierven.

Het mooie aan de interventie van Mark was dat een uurtje praten genoeg was om die inzichten te verwerken. Binnen een dag had ik een heel nieuw niveau aan de audit toegevoegd: Tier 3, Architecture Health. Niet alleen "volgt de code de regels?" maar ook "is de code goed gestructureerd?" De score van mijn systeem zakte van 91% naar 42%. Dat klinkt als slecht nieuws. Maar het was goed nieuws. De oude audit gaf me een vals gevoel van zekerheid. De nieuwe audit liet zien waar het werk nog lag.

Mijn audit heeft nu vier niveaus, elk met een eigen focus:
Tier 1: Compliance. Volgt de code mijn basisregels? Dit zijn de fundamentele afspraken die ik met Claude heb gemaakt over hoe Theta-code eruitziet. Bijvoorbeeld: als ik een lijst met lezingen opvraag, mag het systeem niet voor elke lezing apart naar de database gaan (dat zou bij vijfhonderd lezingen vijfhonderd losse verzoeken zijn). In plaats daarvan haalt hij alles in één keer op. Of: als ik data opvraag, moet dat altijd via een vaste structuur gaan zodat er geen rare tekens of typefouten de boel in de war kunnen schoppen. Dit soort regels. Dit niveau moet honderd procent scoren, anders is het geen Theta-code.

Tier 2: Production Hardening. Is het systeem klaar voor intensief dagelijks gebruik? Tier 1 zorgt dat de code de regels volgt, maar dat betekent nog niet dat alles soepel werkt als ik er de hele dag mee bezig ben. Wat gebeurt er als ik per ongeluk een datum verkeerd invoer? Krijg ik een nette melding of crasht alles? Hoe snel laadt mijn dashboard met vierduizend contactpersonen? Worden wijzigingen netjes opgeslagen of kan ik data kwijtraken als ik te snel klik? Honderd procent is het doel.

Tier 3: Architecture Health. Is de code goed gestructureerd? Dit is het niveau waar Mark het gat schoot. Tier 1 en 2 kunnen honderd procent scoren en toch kan de code een puinhoop zijn. Staat dezelfde opmaak voor een knop op twintig plekken gedefinieerd? Dan moet ik bij elke wijziging twintig bestanden aanpassen. Is het bestand dat mijn dashboard aanstuurt zevenduizend regels lang? Dan kan zelfs Claude niet meer overzien wat er gebeurt en maakt hij fouten. Dit niveau meet of de code logisch georganiseerd is, zodat ik ook over een jaar nog snap waar alles staat.

Tier 4: Technical Debt. Is de codebase schoon? Bij elke sessie met Claude ontstaan er backup-bestanden voor het geval er iets misgaat. Na een paar maanden had ik er 468 van, verspreid door het hele systeem. Staat er code in die ik ooit schreef maar niet meer gebruik? Zijn er notities van "dit moet ik nog fixen" die al weken oud zijn? Dit is als rommel in je garage: het werkt nog wel, maar het stapelt zich op tot ik niet meer kan vinden wat ik zoek. En Claude raakt er ook door in de war.

Je vraagt je misschien af waarom ik bij elke tier op honderd procent mik en net zo lang doorga totdat de audit geen fouten meer vindt. De reden is simpel: als ik nieuwe functionaliteit bouw op een fundament dat maar zestig of tachtig procent scoort, kom ik later gegarandeerd in de problemen. Elke onopgeloste fout vermenigvuldigt zich als het systeem groeit. Dus ga ik net zo lang door tot de audit honderd procent geeft. Het is een veiligheidsmaatregel voor de toekomst, voor als Theta vijftig keer groter is en een paar honderd keer meer data bevat.

Ineens realiseerde ik me dat ik het wiel opnieuw aan het uitvinden was. Er bestaan natuurlijk gewoon gouden standaarden voor het testen van code: ISO-normeringen. Op een gegeven moment vroeg ik me af: hoe weet ik zeker dat mijn audit deugt? Ik had een systeem gebouwd dat zichzelf checkt, maar wie checkt het systeem?

Toen kwam ik op een idee. Wat als ik mijn code toets aan bestaande wereldwijde software-audits?

ISO 25010 meet softwarekwaliteit op acht kenmerken: werkt het, is het betrouwbaar, is het te onderhouden, is het efficiënt? ISO 5055 meet code-kwaliteit geautomatiseerd, niet wat iemand ervan vindt maar wat tools kunnen meten. ISO/IEEE 42010 beschrijft hoe je architectuur documenteert. IEEE 1028 definieert hoe audits uitgevoerd moeten worden.

Ik verzamelde die standaarden en mapte mijn eigen audit erop. Mijn "Eredivisie Light" bleek te vertalen naar officiële terminologie. Keer op keer kwam mijn systeem door die toetsen. Goed gedocumenteerd ook, want ik laat alles uitschrijven zodat het reproduceerbaar is.

De ISO-normen zijn niet een doel op zich. Ze vormen een referentiekader voor mijn audits, en die blijken heel bruikbaar voor het checken van mijn systeem.

Wat ik uiteindelijk heb gebouwd is geen app. Het is ook geen verzameling apps. Het is een systeem dat zichzelf verbetert.

De audit groeit mee met de code. Elke fout wordt een nieuwe regel. Elke externe review wordt verwerkt. Het Common Pitfalls-document bevat inmiddels twintigduizend regels aan "dit ging fout, en zo voorkom ik het". Claude leest dat document voordat er ook maar één regel code wordt geschreven.

Samen vormen ze een feedbackloop die sterker wordt naarmate ik meer bouw. Dat is waarom de snelheid toeneemt in plaats van afneemt. Versie één kostte acht uur. Versie vijf kostte drie uur. Op dit tempo kost versie acht een kwartier.

En dankzij dit systeem kan ik eindeloos veel apps en diensten voor mezelf ontwikkelen die allerlei delen van mijn leven en werk simpeler, makkelijker en beter maken. Het is een digitale informatiearchitectuur, helemaal op maat gemaakt voor allerlei situaties in mijn leven. Grote delen ervan zijn universeel, dus anderen kunnen daarvan leren en zelf zoiets maken.

Ik kan geen code lezen. Ik ben geen programmeur, geen tester. Maar ik durf mezelf inmiddels wel informatiearchitect te noemen. En ik heb het gevoel dat ik iets bijzonders op het spoor ben. Wat ik ontdekt heb is een methode om kwaliteitsborging te doen voor een compleet nieuwe manier van software bouwen. Een manier waarbij AI de code schrijft, maar jij de architect bent van wat er ontstaat.

Als je zelf de structuren kunt bouwen waarin je denkt, werkt en leert, verschuift macht van systemen naar mensen. Ik noem dit informatieliquiditeit: het vermogen om informatie die jarenlang opgesloten zat in losse apps te laten stromen, te bevrijden uit silo's, en er dingen mee te doen.

Dit blog is voor mensen die al voelden dat er iets wringt aan hoe we met informatie omgaan, en die willen zien wat er mogelijk is. Ik ga dit blijven delen. Niet om te verkopen, want ik ben niet van plan om voor anderen te bouwen. Maar om hardop na te denken over wat er gebeurt als je informatie niet organiseert rond tools, maar rond betekenis.

Als je nieuwsgierig bent: volg de artikelen op mijn blog, of regel een zaaltje en laat me een demo geven!

Voor wie wil weten welke normen ik precies toepas:

ISO 25010 is de internationale standaard voor softwarekwaliteit. Acht kenmerken: functionele geschiktheid, prestatie-efficiëntie, compatibiliteit, bruikbaarheid, betrouwbaarheid, beveiliging, onderhoudbaarheid, overdraagbaarheid. Mijn systeem scoort 83% op de relevante kenmerken.

ISO 5055 meet code-kwaliteit geautomatiseerd via tools als Plato. Maintainability Index, cyclomatic complexity, code duplicatie. Objectieve metingen, geen meningen.

ISO/IEEE 42010 beschrijft hoe je softwarearchitectuur documenteert: logische view, data view, deployment view, process view. Plus Architecture Decision Records voor elke ontwerpkeuze.

IEEE 1028 definieert hoe audits uitgevoerd moeten worden: scope, methode, rapportage, vervolgacties, geldigheidsduur.

Standaarden als OWASP Top 10, SOC 2 en GDPR/AVG heb ik bewust niet toegepast. Die zijn bedoeld voor software die aangevallen kan worden, in de cloud draait, of met data van anderen werkt. Theta is lokale software voor één gebruiker, met alleen mijn eigen data.