Bookmarked How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt by Margaret-Anne Storey

I enjoyed this short posting by Margaret-Anne Storey, a CS professor. The effect of using generative tools can indeed lead to loss of overview, and uncertainty about the project I recognise. It creeps in very quickly, especially if I’ve started from something exploratory, as opposed to planned. A cognitive debt accrues because of wanting to move fast or move at all, at the cost of understanding one’s actions in enough detail. It hinders being able to make changes later.

It also makes me wonder something completely different. Partially because of examples I saw last week in Madrid of how BMW and Airbus had sped up some specific tasks orders of magnitude with AI:

If we see companies as slow AI, i.e. context blind algorithms working towards a narrowly defined singular goal (this is where the notion of AI turning all the material in the world including ourselves into paperclips comes from), what methods have we come up with to deal with cognitive debt in organisations? My intuitive response is reporting chains, KPIs, and middle management. Consultancy too, hiring an external actor to blame if needed. That suggests to me we actually didn’t, as so much of that is management-theater. Does any board of any company above a certain size actually know what is going on in their organisations? Understand what consequences changes may have? There’s a world of hurt out there caused by ‘reorganisations’ that all too often seem ritualistic more than rational when seen from the outside.

It may also be why companies easily embrace AI, despite e.g. warnings about cognitive debt. It looks the same as current practice, just with the promise of higher speed.

I saw this dynamic play out vividly in an entrepreneurship course I taught recently. .. one team hit a wall. They could no longer make even simple changes without breaking something unexpected. … no one on the team could explain why certain design decisions had been made or how different parts of the system were supposed to work together. … issue was that the theory of the system, their shared understanding, had fragmented or disappeared entirely. They had accumulated cognitive debt faster than technical debt, and it paralyzed them.

Margaret-Anne Storey

Het is uiterst urgent digitalisering bestuurlijk en politiek te maken, omdat de soevereiniteit van de gemeente op het spel staat. Om daarin handelingsruimte te vinden is het nodig goed onderscheid te maken tussen verschillende aspecten en perspectieven, die wel overlap vertonen met digitale soevereiniteit maar toch iets anders zijn. Teneinde die gevonden handelingsruimte te benutten is technische kennis nodig én een andere kijk op inkoop. Op twee manieren dient een gemeente daarbij over de eigen schaduw te springen. Ten eerste door minder krampachtig vast te houden aan de kamerindeling in het Huis van Thorbecke, zodat je voorkomt dat je ondertussen volledig opgehokt raakt in de cloud. Samenwerking binnen en over bestuurslagen heen is daarbij cruciaal om je digitale soevereiniteit te bewaren.
Ten tweede is het nodig enkele kleine maar zichtbare eerste daden te stellen. Daarmee laat je zien dat de status quo doorbroken kan worden, en dat mobiliseert vervolgens mensen in de eigen organisatie en daarbuiten.
Uiteindelijk is het voor een overheidsinstelling al heel lang niet geloofwaardig uit te leggen waarom je voor bepaalde non-Europese technologie kiest. Tijd voor actie.

De Stadsbron in Amersfoort organiseert in de aanloop naar de gemeenteraadsverkiezingen komend voorjaar een aantal gesprekken over diverse thema’s. Gisteravond was de eerste, rond het thema digitalisering, en vooral wat een gemeente t.a.v. digitale autonomie en soevereiniteit kan doen. Ik was gevraagd om vanuit ons werk bij The Green Land over digitale soevereiniteit te vertellen. In de zaal een diverse groep geïnteresseerden, met en zonder IT invalshoek, en een handvol leden van de Amersfoortse gemeenteraad.

Ik woon in Amersfoort maar weet niets van de informatiehuishouding van de Gemeente Amersfoort, dus mijn bijdrage ging vooral over patronen en invalshoeken die ik elders tegenkom.
Het eerste in het oog springende patroon is dat als het gaat over ‘digitale autonomie’ en ‘digitale soevereiniteit’, dat vaak als synoniem wordt gezien, en wordt samengevoegd met privacy en informatieveiligheid. Deels omdat de dreigingen voor alle vier kunnen overlappen.
Bovendien wordt hierbij vaak door elkaar heen gesproken over het individuele perspectief, en over organisaties.
Het openbaar bestuur heeft bovendien nog weer een andere positie en verantwoordelijkheden (jegens burgers, democratie en rechtsstaat) die meespelen.
Het is dus goed om te onderkennen wanneer je het over welk onderdeel hebt, en dat we het hier over weliswaar overlappende maar verschillende dingen hebben.

Bij digitale autonomie staat voor mij centraal dat je zelf controle hebt over de gereedschappen die je gebruikt. Jij bepaalt waar en hoe je ze inzet, en je kunt de werking instellen. De leverancier dwingt dan geen instellingen af, en neemt geen invloed op jouw gebruik van het gereedschap. Open source software bijvoorbeeld stelt je in staat de werking van je gereedschap precies na te gaan. De algoritmische bepaalde tijdslijnen in social media platforms als Facebook en X ontnemen je de mogelijkheid te bepalen wat je daar ziet en van wie je dingen ziet. Er zijn grote verschillen in hoe LLMs, de modellen achter generatieve AI toepassingen, wel of niet transparant maken op welke gegevens ze zijn getraind. De mate waarin een ander bepaalt of en hoe jij je digitaal gereedschap gebruikt is de mate van uitholling van jouw autonomie. Soms is dat heel navrant: de software in Poolse treinen detecteerde wanneer onderhoud plaatsvond in andere werkplaatsen dan die van de leverancier, en deed dan alsof de trein niet meer werkte. John Deere tractoren zijn op afstand uit te schakelen door de fabrikant. Handig bij roof, maar het werd ook gebruikt om boeren te dwingen niet zelf aan hun machine te sleutelen. JD betoogde in een rechtbank zelfs dat een boer een trekker helemaal niet in bezit had, maar alleen een licentie op gebruik ervan.

Digitale soevereiniteit gaat een stap verder dan digitale autonomie. Daar is de vraag of een leverancier (of een andere actor achter die leverancier) invloed neemt op wat je als organisatie doet, via hun controle over jouw gereedschap. Doe je als organisatie iets dat iemand anders onwelgevallig is, dan stopt de werking van je gereedschap. De invloed reikt dan dus verder dan alleen het gereedschap, en richt zich op de taken en belangen van je organisatie als geheel. Niet eens met de openbare aanklager van het internationaal gerechtshof? Dan werkt de e-mail niet meer. Voor het openbaar bestuur is digitale soevereiniteit cruciaal, om te zorgen dat het openbaar bestuur zelf, en alleen zelf, democratisch toetsbare besluiten kan nemen over hun werkingsgebied. Het is heel platgeslagen de vraag wie aan jouw ‘uitknop’ kan zitten.

En die vraag moet je elke keer opnieuw stellen. De Amerikaanse overheid claimt bijvoorbeeld sinds de Patriot Act (2001) en sinds de Cloud Act (2018) zeggenschap over alle Amerikaanse entiteiten, ongeacht waar die zich bevinden, en inclusief onderliggende entiteiten. Heeft een leverancier uiteindelijk een Amerikaanse eigenaar dan kan de Amerikaanse overheid die opdragen toegang te verschaffen of diensten te stoppen. Als na een overname een Amerikaanse speler eigenaar is geworden van een tot dat moment soevereine digitale oplossing, dan is die soevereiniteit daarmee verdwenen. Een recent voorbeeld: Solvinity biedt, naast al niet-soevereine cloud oplossingen via o.a. Microsoft Azure, ook een geheel eigen product aan waarop bijvoorbeeld Digid draait. Dat valt na overname onder Amerikaanse overheidszeggenschap. Het maakt daarbij niet uit of data en servers wel of niet in Nederland of Europa staan. Veel ‘soevereine cloud’ aanbiedingen zijn dat dan ook niet, domweg omdat er Amerikaanse leveranciers bij zijn betrokken, die uiteindelijk zullen moeten buigen voor eisen van de Amerikaanse overheid. Ongeacht of dat nu wel of niet in de praktijk voorkomt, de aanwezigheid van de mogelijkheid ondergraaft de soevereiniteit van het openbaar bestuur in Nederland (en de hele EU). Alle leveranciergaranties ten spijt, het fundament eronder is dan rot.

Hoe verklein je de afhankelijkheden, hoe werk je aan digitale autonomie en digitale soevereiniteit? Door na te gaan waar precies de problemen en afhankelijkheden zitten die effect hebben op privacy, digitale veiligheid, autonomie en soevereiniteit. Je pelt het af in lagen. Van kritieke grondstoffen die nodig zijn om bijvoorbeeld chips en computers te maken, via de hardware, fysieke infrastructuur, zachte infrastructuur als cloud en open source componenten, naar data, en toepassingen en diensten. Op elk van die lagen weeg je de risico’s en kun je het hebben over beschermende en mitigerende maatregelen. Eurostack en DOSA, dat ook door de Nederlandse overheid wordt gehanteerd, geven zo’n opdeling in lagen.


Eurostack, Bertelsmann Stiftung (PDF), licentie CC-BY NC ND


DOSA stapelmodel

Dat maakt het mogelijk om strategisch en bestuurlijk naar digitalisering te kijken, in plaats van het als technologie keuze bij de IT-afdeling te laten. En je ziet ook waarom hyperscalers een probleem zijn: ze bieden een stapeling van hun eigen hardware, cloud infrastructuur en data centers, plus databeheer, software en AI tools aan als een geheel.
Door te analyseren waar je als organisatie zelf van bent, en niet, en wat je zelf doet en niet, plus hoe dat is verschoven de afgelopen jaren, open je een directiegesprek over hoe dat zich verhoudt tot de taken en doelen van de organisatie zelf. Dat kan tot keuzes leiden weer meer zelf te doen, het aan anderen te laten, of om de samenwerking te zoeken met gelijksoortige organisaties. Onderstaande plaatjes komen uit een casus van een grote uitvoeringsorganisatie. Van belang is vooral het constateren van hoe er wordt uitbesteed waar je zelf als organisatie ook van bent. Met dergelijke uitbesteding verdwijnt ook belangrijke kennis uit je organisatie. In de uitkomst is het aanwijzen van plekken voor samenwerking belangrijk: in plaats van uitbesteden wordt met gelijksoortige organisaties samengewerkt om gezamenlijk met de juiste kennis en inkoopkennis een oplossing te vinden.


DOSA analyse, wat is er veranderd?


DOSA analyse, andere keuzes maken

Cruciaal daarin is het los van elkaar zien van de verschillende elementen die nu bijvoorbeeld bij een hyperscaler zijn ondergebracht. Welke alternatieven zijn er voor die losse elementen, of groepjes ervan? De ene geïntegreerde verticale kolom uit de stack vervangen door een andere is alleen het wisselen van wie je inmenging in je autonomie en soevereiniteit toestaat.
Dit proces vergt kennis van techniek, organisatie, en inkoop.

Aan de inkoopkant is het zaak factoren in de vereisten en in de weging op te nemen die de gewenste autonomie, soevereiniteit en ethische aspecten borgen. Nu is het veelal zo dat een IT inkoper niet in staat is dergelijke dingen te vergelijken met een door zo iemand als veel tastbaarder ervaren categorie als ‘total cost of ownership’. Er is geen prijs te bepalen voor je soevereiniteit als openbaar bestuur, die te verdisconteren is in de ‘TCO’. Inkopers hebben dus nieuwe taal nodig om zich rekenschap te kunnen geven van factoren die het functioneren van het openbaar bestuur kunnen aantasten.
In naam van efficiëntie worden nu IT-keuzes gemaakt die onnodige kwetsbaarheden introduceren. Doorgedreven efficientie maakt je organisatie en processen heel broos.
Dat bleek de afgelopen weken meerdere keren, weliswaar door storingen in plaats van een actor die bewust aan je uitknop zit maar met hetzelfde effect. In de VS viel een stukje van Microsoft Azure om en bij de NS kon geen OV fiets meer worden gehuurd, werkte de reisplanner niet en vielen de kaartautomaten uit. Een storing aan de Amerikaanse oostkust bij Amazon AWS verstoorde in Nederland Digid, de Belastingdienst, KPN en meerdere banken. Een instellingsfoutje in de VS dat Nederlandse kerndiensten (OV, belasting, banken, telecom) meteen verstoort. Want dat is efficiënt bij de aanschaf, echter zeer broos in de operatie.

Decentrale overheden bewaken in het Huis van Thorbecke nauwkeurig hun soevereiniteit ten opzichte van het Rijk. Dat is ook de reden dat ze hun eigen IT inkopen doen. Maar het wrange is dat men daarmee de soevereiniteit die men verdedigt tegen het Rijk uitlevert aan grote IT bedrijven. De grondwettelijk netjes ingerichte kamer in het Huis van Thorbecke verwordt zo tot een ophokplicht in de cloud.

De soevereiniteit die men verdedigt tegen het Rijk is uitgeleverd aan grote IT bedrijven.

Samenwerking biedt de weg naar voren, zodat je dingen kunt doen die buiten je eigen bereik liggen zonder je uit te leveren aan ondermijning van je soevereiniteit.
Dergelijke samenwerkingsmogelijkheden zijn ruimschoots voorhanden. De VNG uiteraard, en het overheidsbrede digitale overheid overleg (OBDO). Het is zinvol je als gemeente actief bezig te houden met de Nederlandse Digitaliseringsstrategie (NDS) en de interbestuurlijke datastrategie (IBDS). Op meer operationeel vlak zijn er ook genoeg mogeljkheden samen aan kennis en verandering te werken. Developer.overheid.nl, de open source policy officer bij BZK en het Rijks ICT Gilde zijn logische ingangen.
Europees is die samenwerking ook beschikbaar. Sinds kort is er de EDIC Digital Commons, een samenwerkingsverband van EU Lidstaten om met praktische projecten digitale autonomie en soevereiniteit in de publieke sector te versterken. Nederland is een van de oprichtende landen, en levert de voorzitter, in de persoon van de directeur CIO Rijk. In het algemeen is de Europese regelgeving t.a.v. data en digitalisering veel nadrukkelijker in te zetten als kwaliteitsinstrument voor de eigen informatiehuishouding en de IT-markt.

Beginnen met laaghangend fruit is ook belangrijk. Je hoeft niet met verandering te wachten tot je op papier een oplossing hebt voor de lastigste stukken van je IT-inrichting. Dat is eerder een vijgenblad voor niet willen veranderen. In beweging komen is een helder signaal naar de organisatie en de omgeving dat het openbaar bestuur de eigen digitale soevereiniteit en het beschermen van burgerrechten daarbij serieus neemt.
Feit is ook dat 80% van ons op het werk niet veel meer doet met IT dan technisch eenvoudige documenten schrijven en mailen. Dit betekent dat niets een organisatie in de weg staat om per direct bijv. de MS Office suite te verruilen voor bijvoorbeeld LibreOffice of de Nextcloud Suite. De paar mensen die met lastige macro’s of ingewikkelde spreadsheets werken laat je de switch dan later maken. Evenzo is het een heel eenvoudig maar wel sterk signaal naar buiten om per direct te stoppen met het gebruik van communicatiemiddelen die burgers vasthouden in van AI-gegenereerde inhoud en desinformatie vergeven advertentieplaforms als X en die van Meta (Facebook, Instagram, WhatsApp). Die stapjes lossen het soevereiniteitsprobleem niet op, maar ze doorbreken de status quo. Die status quo doorbreken is een noodzakelijk signaal om te laten zien dat verandering kan en dat jij en je organisatie daarin handelingsmacht hebben.

Want goed beschouwd is het voor het openbaar bestuur al zeker twee decennia niet fatsoenlijk uit te leggen waarom de huidige IT keuzes worden gemaakt, afgezet tegen autonomie, soevereiniteit, en het uitleveren van handelingsmacht aan derden. Op het kruispunt van de spelregels, zoals die uit de digitale markten en diensten verordeningen (DMA, DSA), de AVG, de Datagovernance en Data verordeningen t.a.v. interoperabiliteit en portabiliteit, en de zeer verschillende waardensets die geopolitiek langs digitale weg worden uitgedragen (Europa, VS, China) is het duidelijk welke afslag de overheid moet nemen. De soevereine weg, want anders is die weg.

The video above is a conversation between Nicole van der Hoeven who hosted it, Bob Doto who wrote the excellent A System for Writing, and Tris Oaten of the No Boilerplate YT-channel (that I did not know before).
Having watched this video where PKM systems are discussed and the different approaches the three participants have, a thought emerged. A thought that I have had previously at PKM events, or when I browse through e.g. the Obsidian forum. In a lot of PKM conversations people can talk past each other due to unspoken assumptions about what your system ‘should’ be.
Not necessarily in the video above, it’s just that watching this conversation made me think about it again.

One dimension is those that assume their system is for personal knowledge. Subjective and temporal as Bob at some point clearly says in the video. As opposed to a system to store references, facts and objective knowledge.

Another is using top-down and up-front created structures vs emerging structures that are earned over time and where noticing emergent structures is newly forming personal knowledge.

A third is whether your PKM system or your Zettelkasten is seen as the whole thing, a artefact-as-is (and thus perhaps transferable in its own right), or whether one’s interaction with it, your own thinking plus your PKM system / Zettelkasten is the whole thing and thus a fully personal tool. Do you see yourself as part of your PKM system, or not?

These three differences in attitude and resulting approach determine quite a bit it seems of what you choose to do and not do in practice (such as the Folgezettel part of the conversation in the video shows).

But it seems to me we hardly ever spell out our own starting assumptions (and thus design parameters) of one’s PKM system and where we see ourselves. We merely project our own ‘givens’ onto the outside world.

What Bob Doto says in the video for instance about his practices resonates well with my own, born from personal knowledge, emergent structures and personal interactive tool.
To me PKM is personal along three dimensions, a personal system, personal knowledge, and personal management, which map well on the three dimensions of assumptions just listed. But I sometimes get the sense that to others that sounds like not as PKM at all, just as making it up as you go along. Which isn’t a false description per se, except for the implied judgement that it won’t yield results and isn’t a deliberate design choice. While I see ratchets and compounding effects.

Maybe we need to more often precede our conversations about PKM system design choices with speaking our usually unspoken assumptions about what type of systems works for us.
Although paradoxically it may be the case that for some that isn’t perceived as a need, if they already assume there is a single cluster of ‘right’ ways of doing things. Then of course it is not needed to speak of assumptions, because what is right is external. Vice versa to me it is not PKM, is not P at all, if it’s assumed there’s a single right way of doing it for all. Then PKM is a method and productivity hack, but not a system for thinking and sensemaking.

For next year’s European PKM Summit I think I need to come up with a short way of describing that and put it on my name badge.

Bookmarked Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality by William Harding and Matthew Kloster

Gitclear takes a look at how the use of Copilot is impact coding projects on GitHub. They signal several trends that impact the overall code quality negatively. Churn is increasing (though by the looks of it, that trend started earlier), meaning the amount of code very quickly being corrected or discarded is rising. And more code is being added to projects, rather than updated or (re)moved, indicating a trend towards bloat (my words). The latter is mentioned in the report I downloaded as worsening the asymmetry between writing/generating code and time needed for reading/reviewing it. This increases downward quality pressure on repositories. I use GitHub Copilot myself, and like Github itself reports it helps me generate code much faster. My use case however is personal tools, not a professional coding practice. Given my relatively unskilled starting point CoPilot makes a big difference between not having and having such personal tools. In a professional setting more code however does not equate better code. The report upon first skim highlights where benefits of Copilot clash with desired qualities of code production, quality and team work in professional settings.
Via Karl Voit

To investigate, GitClear collected 153 million changed lines of code,
authored between January 2020 and December 2023….. We find disconcerting trends for maintainability. Code churn — the
percentage of lines that are reverted or updated less than two weeks after
being authored — is projected to double in 2024 compared to its 2021,
pre-AI baseline. We further find that the percentage of “added code” and
“copy/pasted code” is increasing in proportion to “updated,” “deleted,” and
“moved” code.

Gitclear report

Bookmarked The Two Definitions of Zettelkasten by Chris Aldrich

This is a great essay by Chris Aldrich for several reasons. Because it aims to address the absence in the current hypelet around recent personal knowledge management tools and note systems like Zettelkasten of the realisation that everything in this space has a deep rooted lineage. In response he writes about the history of commonplacing, using card collection for creative, academic or professional output. Because the essay itself is the result of the very practice it describes. In the past months I’ve been reading along with Chris’ annotations (the value of which led me to share more of my own annotations too), and reading his essay I can readily recognise things from that stream of raw material. The notes Chris made from those annotations in turn resulted in this essay. Seven thousands words in a half-day effort.

Note to self: I should create an overview for myself and here about my note taking practice through the years and their inspiration. Just to further illustrate the history Chris writes about.

Hopefully those in the space will look more closely at the well-worn cow paths of analog history in deciding how to pave our (digital) futures. [….] The hiding value proposition of the older methods can be contrasted with the incessant drumbeat of the value and productivity inherently “promised” by those describing [only] Niklas Luhmann’s system.

Chris Aldrich

Al in maart had ik in Utrecht een leuk gesprek met Martijn Aslander en Lykle de Vries als onderdeel van hun podcast-serie Digitale Fitheid. Digitale Fitheid is een platform over, ja precies dat, de digitale fitheid voor de kenniswerker.

In het gesprek hadden we het over persoonlijk kennismanagement (pkm) en de lange historie daarvan, en de omgang met digitale gereedschappen en de macht om die tools zelf vorm te geven. Maar ook over mijn werk, verantwoord datagebruik, de Europese datastrategie, Obsidian meet-ups, en ethiek. Er kwam aan het begin zelfs met veel kabaal een AWACS voorbij.

Een gesprek van een uur dat zo voorbij was. Achteraf denk je dan, heb ik wel coherente dingen gezegd? Terugluisterend nu bij publicatie, valt dat mee.

Mijn gesprek in de Digitale Fitheid podcast staat nu online. Kijk vooral ook even naar de andere gesprekken, die zijn zeker de moeite waard.