Vorige week bouwde ik mijn eerste Mac-app. Niet veel later doken Mark Meinema en Frank Meeuwsen in mijn code, maakten hun eigen variant, en ineens hadden we iets nieuws: echte data over hoe vaak wij op die sneltoetsen drukken.

Het blijkt dus dat Alt-Tab bij Windows-gebruikers en Cmd-Tab bij Mac-gebruikers honderden tot duizenden keren per dag worden gebruikt. Mijn eigen daggemiddelde blijkt een paar duizend keer. Zo vaak wissel ik dus van venster. Dat vermoedde ik al, maar nu weet ik het dus exact. Leuk om te weten, en nog leuker om op door te bouwen.

Ik zou het heel leuk en waardevol vinden als tegen het einde van de 5e Maand van de Digitale Fitheid komende maart duizenden mensen dit experiment hebben uitgeprobeerd. Wat begon als een vraag vanuit verwondering, loopt inmiddels behoorlijk uit de hand.

Toen ik mijn eerste app vorige week aan de praat had smaakte het naar meer. Nu ik dit kan, wat kan er dan nog meer? Wat als ik alles dat ik de afgelopen 20 jaar leerde over apps en informatie en over interfaces meenam in een eigen ontwerp?

Het begon ooit met een Commodore 64 en een exemplaar van het BASIC-handboek. Als veertienjarige programmeerde ik aan Omni, een systeem dat allerlei lijstjes moest bijhouden en waarmee ik snel van de ene lijst naar de andere kon schakelen. De naam Omni verraadde mijn ambitie (en in de jaren 80 kon je best veel platte tekst kwijt op een floppy). Gebrek aan programmeerkennis, geduld en referentiekader maakten dat het project na honderden uren werk terzijde werd geschoven. Maar het nadenken over use-cases en het ontwerpen van een eigen systeem leverde al plezier en voldoening op.

Diep en lang nadenken over een eigen systeem is me dus niet vreemd.

In de afgelopen twintig jaar heb ik veel todo-apps uitgeprobeerd. De afgelopen jaren ontdekte ik dat veel dingen die mensen in een todo-systeem zetten geen todo's zijn, maar intenties en kansen. Omdat er altijd veel meer van die intenties en kansen zijn dan van echte taken raakt je systeem verstopt en vervuild, en mis je overzicht.

Een todo-app is natuurlijk niet ontwikkeld voor kansen en intenties. Het kan er wel in, met tags en mapjes kun je van alles doen. Maar toch voelt het niet alsof het daar bedoeld of geschikt voor is. In elk geval gaan mijn hoofd en die apps niet goed samen.

Sinds ik een jaar of drie bezig ben met Obsidian en nadenk over alle brokjes informatie en alle elementen waar die uit opgebouwd zijn, krijg ik meer inzicht over het organiseren, filteren en weergeven van informatie. En vooral hoe je dat snel ergens in krijgt en ook weer uithaalt op de door jou gewenste manier.

Ik heb een systeem nodig dat op maat is gemaakt voor wie ik ben, wat ik doe en wat er speelt. Een hefboom voor overzicht, snelle beslissingen en een radar voor signalen. Met informatieliquiditeit om alles snel te kunnen delen en te archiveren op mijn eigen manier in Obsidian.

Softwarematig is dit het equivalent van een hutje in een bos. Maar vorige week besloot ik iets radicaals uit te proberen: de architectuur en bouwvoorschriften van het Pentagon gebruiken voor dat hutje.

Ik schreef twee weken terug al over het systeem dat ik aan het bouwen was. Het werkte goed en ik breidde het steeds verder uit. Maar juist omdat het zo succesvol was, liep ik tegen de grenzen aan: nieuwe elementen ontwikkelen duurde te lang en voelde buggy. Tussen de bedrijven door stak ik daarom zo'n dertig uur in een grondige herziening van de architectuur.

Ik werkte tot voor kort vooral met Claude Desktop, maar ben nu over op Claude Code in de terminal. Die is bloedsnel en stabieler. Mijn startprompt was deze:

Stel dat ik de enige programmeur was die zowel Netflix als Spotify in de lucht moest houden. Hoe bouw ik dan een state-of-the-art, robuust en toekomstbestendig systeem, waarin ik moeiteloos nieuwe functies toevoeg en duizend keer meer data aankan dan nu? En absoluut geen data kwijt kan raken?

Wat daarop volgde was een lang gesprek vol documentatie en nieuwe concepten. Eén daarvan kende ik nog niet, maar bleek cruciaal: MVC.

MVC staat voor Model-View-Controller. Het is een architectuurpatroon dat wordt gebruikt bij het bouwen en ontwikkelen van software. Hiermee breng je structuur, overzicht en herbruikbaarheid in de code.

Het Model gaat over de data en de logica: wat er echt gebeurt. De View bepaalt hoe het er visueel uitziet en de Controller regelt hoe die data op de goede manier en plek getoond wordt.

Door die drie van elkaar te scheiden kun je makkelijker uitbreiden, testen en onderdelen hergebruiken. Dat voelde compleet logisch en verklaarde waarom ik eerder vastliep en liep te klooien met een speels aan elkaar geknutselde codebase. Gaaf dat je met AI conceptueel en metaforisch gewoon de bouwtekeningen van het Pentagon, inclusief funderingen, kunt gebruiken voor een robuust hutje in een bos, een leuk én waardevol experiment.

Dat leverde zo'n dertig uur dialoog en meer dan zeventig pagina's architectuurbeschrijving op. Daarmee kon ik stap voor stap een heel robuust systeem bouwen dat moeiteloos honderd keer zo groot kan worden en zo nodig duizend keer meer data kan bevatten.

Dit was V2 van mijn Theta-systeem, een grondige herziening van al het werk uit de voorgaande maand.

Dat was even frustrerend: ik moest eerst leren ontleden, herontwerpen en structureren voor ik weer kon bouwen. Terwijl ik zo blij was met wat ik allemaal al gebouwd had en met plezier en succes aan het gebruiken was. Maar dat bleek precies het verschil tussen iets wat net werkt en iets wat oneindig uitbreidbaar is.

Door code slim te hergebruiken en de onderliggende structuur strakker op te zetten, kon ik me richten op hoe informatie door het systeem beweegt in plaats van alleen op wat er op het scherm verschijnt.

Wat ik nu bouw is meer dan wat code uit AI-prompts. Het is een systeem dat ook als het groeit, en zelfs als het fors groeit, heel snel blijft werken. Alle data komt uiteindelijk in Obsidian terecht. En met informatieliquiditeit als ontwerpprincipe: wat ik zie kan ik in één klik in het juiste formaat naar mijn klembord sturen, klaar om te appen, mailen of waar ik het ook maar nodig heb.

Elke keer als ik een werkend stukje code heb, een bug vind of een fout oplos, laat ik dat vastleggen. Niet als losse notities, maar als groeiende stapel referentiemateriaal. Het is mijn gezamenlijke geheugen met de machine: een archief waarin elke fout, fix en ontdekking wordt bewaard.

Zo bouw ik niet alleen code, maar ook kennis. De AI leert van mijn context, ik leer van haar uitleg. En samen leggen we alles vast, zodat ik later kan teruggrijpen op wat al eens is opgelost, getest of verbeterd. Het voelt als een co-evolutionair ontwikkelproces, zoals de concepten waar Garri Kasparov over vertelde in deze TED-talk: ik train het systeem, dat op zijn beurt mij verder helpt ontwikkelen.

Een van mijn meest gebruikte tools is Drafts. Ik druk op mijn Apple Watch, spreek wat in, en het belandt in mijn inbox. Dingen als: "Peter bellen, melk kopen, linkje checken."

Mijn systeem weet dat "Peter" [[👥 Peter Ros]] is, dat "Mark" [[👥 Mark Meinema]] betekent (niet Mark Vletter), en dat woorden als kopen, plannen, appen of uitzoeken elk hun eigen pad en plek en dynamiek hebben binnen mijn systeem.

Die structuur maakt dat informatie vanzelf op de juiste plek terechtkomt, waar ik het later weer nodig heb.

Bij alles wat ik bouw draait het om informatieliquiditeit: de snelheid waarmee ik bij informatie kan en die kan delen. Elke entiteit (persoon, organisatie, plek, boek of bestemming) wordt als wikilink opgeslagen, compleet met emoji en naamgevingsconventie. Alles sluit aan op mijn Obsidian-ontologie.

Het menselijk hoofd maakt geen onderscheid tussen werk en privé. Vandaar dat ik vind dat informatie juist door elkaar heen moet lopen, zodat alles beschikbaar is op het moment dat je het nodig hebt, los van welke context. Het gevolg: werk en privé vloeien samen in één slim systeem, hierdoor stroomt informatie zonder onnodige frictie, en heb ik veel meer grip op wat er binnenkomt, waar het hoort en hoe ik het eruit haal om te delen of er iets mee te doen.

In mijn systeem zit een boodschappenmodule. Ik koop bij zo'n acht vaste winkels in Haarlem. Klik ik op hutspot, dan voegt het systeem automatisch alle ingrediënten toe aan mijn boodschappenlijst.

Het slimme deel: elke winkel heeft een klembord-knop (📋). Ik heb één keer uitgelegd hoe de indeling van mijn supermarkt werkt. Ongeacht de volgorde waarin de boodschappen in mijn lijstje staan, klik ik op die knop. Dit doet twee dingen: het forceert de opmaak en rangschikt de boodschappen naar het gangpad van mijn supermarkt. Daarnaast plakt het dat gefilterde format op mijn klembord, zodat ik het via WhatsApp, Teams of mail acuut ergens heen kan sturen. Het is schitterend in zijn eenvoud, maar extreem bruikbaar en toepasbaar op andere manieren.

En toen viel het kwartje: informatie sorteren op gebruiksvolgorde in plaats van op invoervolgorde, dat principe kan ik hergebruiken. Een lijstje met optredens vraagt om andere informatie dan een lijstje met contactpersonen. En wat ik naar een assistent stuur verschilt van wat een opdrachtgever nodig heeft.

Op veel plekken in mijn systeem kan ik nu met één druk op de knop alle zichtbare informatie in het juiste format op mijn klembord zetten. Een lijst met komende optredens krijgt een andere weergave dan boodschappen. Precies contextueel zoals ik het nodig heb, of zoals de mensen aan wie ik iets delegeer of waarmee ik samenwerk het nodig hebben.

Een boodschappenlijst alfabetisch sorteren is technisch netjes maar praktisch onhandig. Als je de lijst sorteert op de volgorde waarin je door de supermarkt loopt ontstaat er efficiency. Je vertaalt de fysieke ruimte naar informatiearchitectuur.

Dit principe geldt breder. Informatie sorteren op gebruiksvolgorde in plaats van op invoer of alfabet maakt systemen intuïtiever. Function follows context, niet data. De meeste tools missen deze dimensie volledig omdat ze alleen naar de data zelf kijken, niet naar hoe mensen ermee werken.

Het is de gangpad-metafoor: software moet de werkelijkheid volgen waarin ze wordt gebruikt, niet de logica van databases en algoritmes.

Bij de meeste applicaties moet je informatie eerst exporteren, keuzes maken in dialoogvensters en vaak naar een andere tool overschakelen om iets te kunnen delen. Mijn systeem draait dat om door de flow van idee naar context naar actie te stroomlijnen.

Ik ben me bewust dat ik heel anders naar informatie kijk dan de meeste mensen. Ik zie het als een kapitaalvorm: de munteenheid van de informatiesamenleving die, als je deelt en weggeeft, je veel waardevollers brengt, namelijk sociaal kapitaal. Gunnen en vertrouwen, of gewoon mensen helpen omdat het een goed idee is en het juiste is om te doen.

Ik neem dat informatiekapitaal en de informatieliquiditeit, de snelheid waarmee ik erbij kan, extreem serieus. Daarom ben ik bereid vele honderden uren op te offeren om te onderzoeken of ik anders, beter en slimmer kan. Dit systeem komt vrij dicht in de buurt van wat ik zou wensen: acuut bij mijn informatie kunnen zijn en die op de juiste manier kunnen delen door het te kopiëren en plakken in het juiste format.

Informatieliquiditeit als uitgangspunt nemen - dat klinkt voor de hand liggend, maar op deze manier verandert het mijn manier waarop ik met een computer samenwerk.

Mijn veertienjarige zelf met zijn Commodore 64 wilde al lijstjes kunnen bijhouden en snel schakelen tussen contexten. Veertig jaar later lukt dat eindelijk, niet alleen met betere tools maar met beter begrip van wat er eigenlijk moet gebeuren. Het ging nooit om de lijstjes zelf, maar om de flow tussen intentie en actie. Het Pentagon-hutje is inmiddels bewoond. En het blijkt dat goede architectuur ook werkt op kleine schaal.

Het is meer dan goed genoeg, en steeds beter. En er extra kamers, schuurtjes en zolder aan vasttimmeren gaat nu moeiteloos, want daar begon het allemaal mee. De wens om snel uit te breiden zonder dat het qua code een bende wordt.