Openai/69457f3e-d040-8006-b78a-a23accaf6668
This conversation was exported from ChatGPT[1]
gpt-5-2 edit
User: Graag een samenvatting van het artikel dat je hier kunt aantreffen: edit
Graag een samenvatting van het artikel dat je hier kunt aantreffen: https://www.computable.nl/2025/12/19/acict-duo-eindelijk-op-goede-weg-met-systeem-bekostiging/
Assistant: Hier is een samenvatting van het artikel over DUO en de systeem-bekostiging zoals gepubliceerd op Computable op 19 dece… edit
Hier is een samenvatting van het artikel over DUO en de systeem-bekostiging zoals gepubliceerd op Computable op 19 december 2025:
Het Adviescollege ICT-toetsing (AcICT) oordeelt dat de Dienst Uitvoering Onderwijs (DUO) eindelijk op de goede weg is met de heroriëntatie van het langlopende moderniseringsproject voor de bekostigingssystemen van onderwijsinstellingen, maar er blijven belangrijke verbeterpunten. Computable.nl[2] edit
- DUO werkt al bijna vijf jaar aan het project Doorontwikkelen Applicatielandschap Bekostiging (DAB) om systemen te vernieuwen die de bekostiging van scholen en andere onderwijsinstellingen regelen. Computable.nl[3] edit
- In 2021 kreeg het project een zeer negatief oordeel van het toenmalige BIT (nu AcICT), dat DUO adviseerde radicaal te stoppen met de oorspronkelijke aanpak. Computable.nl[4]
DUO heeft belangrijke keuzes herzien: edit
- Het schrappen van het destijds gekozen platform Blueriq en overstap naar nieuwbouw met Java. Computable.nl[5]
- Gebruik van de ALEF-generator van de Belastingdienst voor automatisering van regels en berekeningen, met meer aandacht voor continuïteit en stapsgewijze vervanging van systemen. Computable.nl[6]
Het resultaat: het traject is minder problematisch dan voorheen en biedt nu een beheersbaardere aanpak. Computable.nl[7]
AcICT blijft kritisch en noemt verschillende zaken die nog moeten worden verbeterd: edit
- Organisatiecultuur en risicobeheersing moeten beter worden ingebed; de nieuwe aanpak is technisch verbeterd maar organisatorisch kwetsbaar. Computable.nl[8]
- Het architectuurproces van het systeemlandschap is onvoldoende uitgewerkt, wat toekomstige onderhoudbaarheid en schaalbaarheid belemmert. Computable.nl[9]
Het adviescollege geeft concrete aanbevelingen, waaronder: edit
- Beter vastleggen en beschrijven van de huidige én gewenste architectuur als geheel. Computable.nl[10]
- Actiever zorgen voor tegengeluid en inhoudelijke discussies over architectuurkeuzes – met besluiten op directieniveau waar nodig. Computable.nl[11]
- Terugdraaien van risicovolle keuzes (zoals eigen bouw van tools) en nadruk leggen op bewezen componenten zoals ALEF. Computable.nl[12]
- Interne expertise versterken in plaats van afhankelijk zijn van externe krachten. Computable.nl[13]
AcICT benadrukt dat de grootste uitdagingen niet technologisch zijn, maar in de organisatiecultuur zitten – en dat de voltooiing van dit megaproject waarschijnlijk pas rond 2032 zal plaatsvinden. Computable.nl[14] edit
Wil je een uitgebreide opsomming van de aanbevelingen of een duidelijk tijdpad van hoe DUO hier is gekomen en wat er daarna nog moet gebeuren?
User: Nu verschijnt op dit artikel de volgende reactie: edit
Nu verschijnt op dit artikel de volgende reactie:
whatever, gaat erom dat er niet iets met SOA, 5GL of beslissingstabellen wordt ingevoerd. Gelukkig geeft good-old Javatechnologie gecombineerd met iets met Agile goede hoop. Veel herorientatie ook. Das altijd mooi. Weet je wat, doe gelijk maar “een andere technologie” 😛
“Een ander zwak punt is het architectuurproces. De onderhoudbaarheid van het toekomstig landschap wordt bemoeilijkt door een gebrekkige opzet daarvan. Een passende architectuur biedt structuur en is de drager van systeemkwaliteiten als schaalbaarheid, aanpasbaarheid en beveiliging. Het proces om tot die architectuur te komen moet daarom worden verbeterd.”
Wat een taal. “Wordt bemoeilijkt door een gebrekkige opzet daarvan.” Zucht In gewoon Nederlands: Het deugt niet omdat het allemaal verrot is. enneEueehh, moet allemaal beter. ..
Net een analyse van een voetballer meteen na een slechte wedstrijd, waar die tegengoal die het niets kwam nooit had mogen gebeuren en dat ze daarna achter de feiten aanliepen. Hoe dat kan, we moeten het nog eens analyseren..
Nog ff Geduld, dankzij die wendbare ALEF generator is het 2032 alweer klaar. Zeggen ze dan..
Graag een analyse.
Assistant: Hier is een analyse van de reactie, op het niveau van retoriek, houding en impliciete aannames dus niet feitelijk-techn… edit
Hier is een analyse van de reactie, op het niveau van retoriek, houding en impliciete aannames (dus niet feitelijk-technisch, maar hermeneutisch — aansluitend bij jouw voorkeur voor retorische valsheid).
De reactie is consequent ironisch en licht sarcastisch van toon: edit
- “whatever”, “gelukkig”, “das altijd mooi”, “zeggen ze dan”
- Emoji 😛 versterkt de afstand en het niet-serieus-nemen
👉 Dit is geen poging tot inhoudelijke weerlegging, maar een affectieve positionering:
Dat is op zichzelf een begrijpelijke reactie op bestuurlijk-technocratische taal, maar het blokkeert ook eigen precisie.
De schrijver reduceert het artikel tot een technologisch smaakconflict: edit
- SOA, 5GL, beslissingstabellen → “gelukkig niet”
- Java + Agile → “good-old”, “geeft hoop”
- ALEF → “wendbaar”, maar met hoorbare spot
Dit is een retorische versimpeling:
- Architectuurproblemen worden voorgesteld als modegrillen
- Alsof eerdere mislukkingen vooral veroorzaakt zijn door verkeerde buzzwords
👉 Daarmee verdwijnt de structurele kritiek van AcICT (governance, besluitvorming, architectuurproces) uit beeld.
Het geciteerde AcICT-fragment wordt taalkritisch gefileerd: edit
De reactie vertaalt dit scherp naar:
Hier raakt de schrijver wel degelijk een kern:
- De AcICT-taal is depersonaliserend, procesmatig en verantwoordelijkheidsloos
- Niemand doet iets fout; “het wordt bemoeilijkt”
👉 Dit is een klassiek probleem van ambtelijke waarheidsproductie: taal die problemen erkent zonder iemand aanspreekbaar te maken.
De vergelijking met een voetbalinterview is zeer raak: edit
- “Die tegengoal had nooit mogen gebeuren”
- “We liepen achter de feiten aan”
- “We moeten het analyseren”
Dit benoemt een ritueel van schijnreflectie:
- Er is erkenning van falen
- Maar geen nieuwe inzichten, breuk, of verantwoordelijkheid
👉 De reactie suggereert:
Dat is een sterke hermeneutische observatie.
: edit
Hier wordt de tijdsdimensie gebruikt als delegitimatie:
- “Wendbaarheid” ↔ zeven jaar resterende doorlooptijd
- Innovatietaal ↔ uitgestelde realiteit
👉 Dit ondermijnt precies het kernverhaal van het artikel: voorzichtig optimisme.
Volgens jouw eigen criterium (hermeneutische eerlijkheid), zou ik zeggen: edit
- Ontmaskering van leeg bestuurlijk taalgebruik edit
- Herkenning van rituele evaluaties
- Wantrouwen tegenover techno-optimisme zonder breukmoment
- Karikatuur van architectuurkritiek als “technologiewissel” edit
- Geen onderscheid tussen: - ALEF als hulpmiddel - en het falen van besluitvorming en architectuurproces
- Cynisme vervangt analyse
👉 De reactie zegt iets echts, maar denkt het niet uit.
Deze reactie is: edit
- ❌ geen inhoudelijke tegenanalyse
- ✔ wel een symptoomanalyse van bestuursretoriek
- ⚠️ maar gevangen in ironie, waardoor ze niet productief wordt
Of scherper geformuleerd (in jouw register):
Als je wilt, kan ik:
- deze reactie herformuleren tot een sterke inhoudelijke kritiek, of
- haar plaatsen binnen een Heideggeriaanse analyse van techniek en bestuurlijk spreken, of
- expliciet verbinden met jouw eerdere ALEF-kritiek (ontologie vs. regelmachine).
User: Heb je ook nog een cijfer op de schaal van valsheid? edit
Heb je ook nog een cijfer op de schaal van valsheid?
Assistant: Ja. edit
Ja. Op jouw schaal van valsheid (retorische, hermeneutische valsheid — niet feitelijk) zou ik deze reactie het volgende cijfer geven:
### edit
Waarom niet hoger (dus niet “zeer vals”)?
- De reactie doorziet terecht: - het lege, ritualistische karakter van bestuurlijke evaluatietaal; - de afwezigheid van verantwoordelijkheid in formuleringen als “wordt bemoeilijkt door”; - de voorspelbaarheid van techno-optimisme met lange tijdshorizonten.
- Ze is existentiëel eerlijk in haar irritatie: het wantrouwen is niet gespeeld.
Waarom ook niet lager (dus niet “waarachtig”)?
- De kritiek blijft steken in ironische afstand.
- Architectuurkritiek wordt gereduceerd tot technologie-mode (Java vs. SOA vs. ALEF).
- Cynisme vervangt onderscheid: - geen analyse van waar het architectuurproces faalt, - geen normatief criterium voor wat “deugt” zou betekenen.
- De spreker neemt geen risico: alles wordt vooraf geneutraliseerd door spot.
: edit
Of nog scherper:
- Morele intuïtie: aanwezig
- Conceptuele precisie: afwezig
- Verantwoordingsbereidheid: laag
Daarom: 6/10 — herkenbaar, raak, maar uiteindelijk te comfortabel ironisch om werkelijk waarachtig te zijn.
User: Ok, er is door een andere persoon een volgende reactie opgevoerd: edit
Ok, er is door een andere persoon een volgende reactie opgevoerd:
Waarom eerst nog de doodlopende weg inslaan die ALEF heet?
“je intuïtie klopt op twee punten tegelijk:
- regelmachines exploderen in complexiteit, en
- ALEF heeft inderdaad géén expliciete ontologie “
Graag weer een analyse en cijfer.
Assistant: Hier is opnieuw een analyse op hermeneutisch/retorisch niveau, gevolgd door een cijfer op jouw schaal van valsheid. edit
Hier is opnieuw een analyse op hermeneutisch/retorisch niveau, gevolgd door een cijfer op jouw schaal van valsheid.
In tegenstelling tot de vorige reactie is deze: edit
- veel compacter
- minder ironisch
- inhoudelijk explicieter
De openingszin:
is normatief en risicovol: de spreker neemt een standpunt in dat falsifieerbaar is. Dat is hermeneutisch al een winst.
De aanhalingstekens en de formulering “je intuïtie klopt op twee punten tegelijk” doen twee dingen: edit
- Ze verankeren de uitspraak in een eerder betoog (kennelijk een discussie over ALEF).
- Ze positioneren de spreker niet als roeper, maar als iemand die een reeds ontwikkeld inzicht samenvat.
Dat geeft de reactie epistemische ernst: ze pretendeert niet alles nieuw te zeggen, maar iets te bevestigen.
De twee punten zijn inhoudelijk sterk geformuleerd: edit
- Dit is een structurele kritiek, geen smaakverschil. edit
- Impliceert: - combinatorische explosie, - ondoorzichtigheid, - verlies van beheersbaarheid.
- Sluit direct aan bij bekostigingslogica, uitzonderingen, overgangsregimes.
Dit punt raakt de kern van waarom eerdere trajecten faalden.
Dit is het meest wezenlijke punt, zeker in het licht van jouw eerdere opmerkingen: edit
- Geen expliciete ontologie betekent: - geen expliciet begrip van wat er is (entiteiten, relaties, statussen), - alleen procedures en transformaties.
- Daardoor: - betekenis ontstaat pas in uitvoering, - niet in een gedeelde, toetsbare wereldbeschrijving.
👉 Dit is geen technisch bezwaar, maar een filosofisch-architectonisch bezwaar.
Impliciet wordt hier iets belangrijks blootgelegd: edit
- AcICT spreekt over: - onderhoudbaarheid, - architectuurproces, - systeemkwaliteiten.
- Deze reactie benoemt waarom die problematisch blijven: - omdat zonder ontologie architectuur procedureel blijft, - en dus niet normatief richtinggevend kan zijn.
Dit is precies de ontbrekende schakel in veel ICT-rapporten.
De reactie is sterk, maar niet af: edit
- “Doodlopende weg” wordt niet verder onderbouwd: - Is het doodlopend per definitie? - Of alleen bij deze schaal en governance?
- Ontologie wordt genoemd, maar niet gespecificeerd: - domeinontologie? - juridische ontologie? - bekostigingsontologie?
Dit is geen valsheid, maar onafheid.
### edit
✔ Hermeneutisch waarachtig edit
- Neemt een expliciet standpunt in.
- Benoemt structurele oorzaken, geen symptoombestrijding.
- Vermijdt ironische distantie.
- Sluit aan bij eerdere doordenking (continuïteit van inzicht).
⚠️ Beperkingen
- Compactheid laat veel impliciet.
- Vereist voorkennis bij de lezer.
Maar: dat zijn geen retorische trucs, eerder tekenen van inhoudelijke concentratie.
: edit
In jouw register:
- Intuïtief juist
- Conceptueel raak
- Retorisch sober
Daarom: 3/10 valsheid — dicht bij hermeneutische eerlijkheid.
User: En dan is er nog een derde reactie van weer een ander persoon: edit
En dan is er nog een derde reactie van weer een ander persoon:
Het enige wat je nodig hebt is een goede “general purpose” programmeertaal en een message queue.
En liefst een gecompileerde programmeertaal zoals C++ of Rust. Maar JIT talen zoals C# en Java zijn ook acceptabel. Iedereen die Python of JavaScript voorstelt moet er meteen uitvliegen.
Qua architectuur moet het gewoon een monoliet zijn. Geen microservices of CQRS.
Ook weer graag een analyse.
Assistant: Hier is opnieuw een hermeneutische analyse, in dezelfde lijn als eerder — en ik voeg ook een cijfer op de schaal van va… edit
Hier is opnieuw een hermeneutische analyse, in dezelfde lijn als eerder — en ik voeg ook een cijfer op de schaal van valsheid toe, omdat dit nu impliciet onderdeel van het spel is geworden.
Deze reactie is radicaal normatief: edit
- “Het enige wat je nodig hebt…”
- “moet het gewoon…”
- “Iedereen die X voorstelt moet eruit vliegen”
Dit is geen analyse, maar een beslissingsretoriek: de spreker presenteert zich als iemand die boven het debat staat.
Hermeneutisch gezien is dit een sluitende houding: het gesprek wordt beëindigd in plaats van geopend.
De kernclaim is: edit
Dat blijkt uit:
- focus op programmeertalen (C++, Rust, Java, C#)
- afwijzing van andere talen op quasi-morele gronden
- reductie van architectuur tot monoliet vs microservices
👉 Dit is technisch essentialisme: alsof falen en slagen primair voortkomen uit taalkeuze en deploymentstijl.
Daarmee wordt alles wat AcICT juist problematiseert — besluitvorming, veranderlijkheid van wetgeving, semantiek van bekostiging — buiten beeld gehouden.
De pleidooi voor: edit
- monoliet
- message queue
- compiled languages
is niet onzinnig op zichzelf. Integendeel:
- het is een reactie tegen over-engineering;
- het weerspiegelt ervaring met falende microservices.
Maar hermeneutisch gebeurt hier iets belangrijks:
👉 Complexiteit wordt verplaatst van het domein naar de techniek in plaats van begrepen als inherent aan de werkelijkheid (bekostiging, recht, uitzonderingen).
De monoliet wordt zo een mythisch object:
Dat is precies de illusie die eerdere generaties systemen óók hadden.
In contrast met de tweede reactie: edit
- Geen enkel woord over: - wat het systeem is, - welke entiteiten bestaan, - hoe juridische betekenis wordt vastgelegd.
- Alles is: - uitvoering, - performance, - discipline.
👉 Daarmee bevestigt deze reactie onbedoeld de kritiek op ALEF: ook hier is er geen expliciete ontologie, alleen een uitvoeringsideaal.
Ironisch genoeg staat deze reactie dus dichter bij ALEF-denken dan haar auteur vermoedelijk wil.
Zinnen als: edit
zijn hermeneutisch problematisch:
- Ze vervangen argumentatie door loyaliteitstoetsing.
- Ze creëren een ingroup van “echte engineers”.
- Ze suggereren dat falen veroorzaakt wordt door domme mensen i.p.v. door structurele omstandigheden.
👉 Dit is retorische agressie vermomd als pragmatisme.
Positief (en dat telt): edit
- Er spreekt ervaring uit.
- Er is weerzin tegen modieuze architecturen.
- Er is een verlangen naar: - stabiliteit, - eenvoud, - beheersbaarheid.
Maar: dit verlangen wordt niet doordacht, slechts geproclameerd.
### edit
❌ Hermeneutisch onwaarachtig edit
- Sluit betekenis af in plaats van haar te ontsluiten.
- Verwisselt technische discipline met waarheid.
- Doet alsof complexiteit een keuze is, geen gegeven.
- Ontkent impliciet de normatieve dimensie van het domein.
✔ Niet maximaal vals
- Geen ironie of cynisme.
- Oprechte overtuiging.
- Ervaring als bron.
Maar overtuiging ≠ waarachtigheid.
: edit
In jouw termen:
- Retorisch krachtig
- Hermeneutisch arm
- Ontologisch leeg
Daarom: 7,5/10 valsheid — overtuigend gebracht, maar fundamenteel reductionistisch.
Als je wilt, kan ik deze drie reacties:
- naast elkaar leggen in één schema,
- of expliciet verbinden met Heidegger: Gestell vs. wereldontsluiting,
- of herformuleren tot één inhoudelijk serieuze tegenkritiek op het AcICT-rapport.
User: naast elkaar leggen in één schema edit
naast elkaar leggen in één schema
Assistant: Hier is een schema waarin de drie reacties expliciet naast elkaar worden gelegd, langs dezelfde hermeneutische assen. edit
Hier is een schema waarin de drie reacties expliciet naast elkaar worden gelegd, langs dezelfde hermeneutische assen. Dit maakt zichtbaar waar ze elkaar raken, waar ze elkaar missen, en waar het debat ontspoort.
| | | | | edit
| --- | --- | --- | --- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Je ziet hier drie fundamenteel verschillende manieren om met falen om te gaan: edit
- Reactie 1 zegt: “Ik doorzie het spel en doe niet meer mee.” → scherp, maar steriel.
- Reactie 2 zegt: “Hier ontbreekt een wereldbeschrijving; dáárom ontspoort alles.” → inhoudelijk dragend.
- Reactie 3 zegt: “Stop met denken, begin met discipline.” → daadkrachtig, maar blind.
Hermeneutisch gezien is reactie 2 de enige die werkelijk ontsluit: zij benoemt wat er ontbreekt zonder het gesprek te sluiten.
- Reactie 1: 6 / 10 edit
- Reactie 2: 3 / 10
- Reactie 3: 7,5 / 10
Of in één zin:
Als je wilt, kan ik dit schema ook:
- herleiden tot één kernconflict (ontologie vs. uitvoering),
- of expliciet Heideggeriaans duiden (Gestell, wereld, spreken),
- of omzetten in een inhoudelijk weerwoord op het AcICT-discours.
User: Hoe waardeer je de 3 reacties inhoudelijk ten aanzien van wat gesteld wordt in het hoofdartikel? edit
Hoe waardeer je de 3 reacties inhoudelijk ten aanzien van wat gesteld wordt in het hoofdartikel?
Kun je hier ook cijfers voor geven?
Assistant: Hier is een inhoudelijke waardering van de drie reacties ten opzichte van het hoofdartikel het AcICT-oordeel over DUO/D… edit
Hier is een inhoudelijke waardering van de drie reacties ten opzichte van het hoofdartikel (het AcICT-oordeel over DUO/DAB), los van toon of retoriek. Dus: in hoeverre raken ze feitelijk en conceptueel wat het artikel zelf stelt en problematiseert?
Ik sluit af met cijfers per reactie.
Referentiekader: wat stelt het hoofdartikel inhoudelijk? edit
Samengevat zegt het artikel (en het AcICT-rapport):
- DUO is technisch rustiger vaarwater ingeslagen (af van Blueriq, meer stapsgewijs).
- ALEF wordt gezien als bewezen hulpmiddel, mits verstandig ingezet.
- De grote zwakte zit niet primair in technologie, maar in: - architectuurproces, - besluitvorming, - borging van onderhoudbaarheid, - en organisatorische volwassenheid.
- Architectuur wordt expliciet benoemd als drager van systeemkwaliteiten, maar: - het proces om die architectuur te ontwikkelen schiet tekort.
- De risico’s zijn structureel en langdurig (doorlooptijd tot ~2032).
Dit is het ijkpunt.
Reactie 1 – Ironisch cynisme edit
Inhoudelijke relatie tot het artikel edit
- ✔ Raakt terecht: - de leegte en ritualisering van bestuurlijke taal; - het spanningsveld tussen “wendbaarheid” en extreem lange doorlooptijd.
- ❌ Mist: - onderscheid tussen technische verbetering en organisatorisch falen; - de kern van AcICT’s architectuurkritiek.
- ❌ Zet ALEF weg als hype, terwijl het artikel juist voorwaardelijk positief is.
Inhoudelijke waarde edit
Deze reactie leest het artikel vooral als genre, niet als analyse. Ze bekritiseert hoe er gesproken wordt, maar nauwelijks wat er wordt vastgesteld.
Cijfer (inhoudelijk t.o.v. artikel) edit
5 / 10
- Begrijpt de sfeer en de zwakte van het discours,
- maar mist de analytische kern van het rapport.
Reactie 2 – Ontologische kritiek op ALEF edit
Inhoudelijke relatie tot het artikel edit
- ✔ Sluit direct aan op het architectuurprobleem: - waarom blijft onderhoudbaarheid problematisch? - waarom explodeert complexiteit?
- ✔ Verheldert iets wat het artikel niet expliciet benoemt, maar wel impliceert: - architectuur zonder ontologie blijft procedureel en fragiel.
- ⚠️ Gaat verder dan het artikel: - noemt ALEF principieel “doodlopend”, terwijl AcICT dat niet zo stelt.
Inhoudelijke waarde edit
Deze reactie is niet volledig in lijn met het artikel, maar verdiept het. Ze levert een verklarend kader voor precies de zwakte die AcICT signaleert.
Cijfer (inhoudelijk t.o.v. artikel) edit
8 / 10
- Niet letterlijk wat er staat,
- maar inhoudelijk het meest verklarend voor waarom AcICT gelijk heeft.
Reactie 3 – Technisch absolutisme (monoliet + taalkeuze) edit
Inhoudelijke relatie tot het artikel edit
- ❌ Gaat langs het kernprobleem heen: - AcICT bekritiseert geen programmeertalen; - ook microservices vs monoliet is geen centraal punt.
- ❌ Negeert: - governance, - architectuurproces, - betekenismodellering.
- ✔ Sluit alleen zijdelings aan bij: - kritiek op over-engineering (impliciet aanwezig in rapport).
Inhoudelijke waarde edit
Deze reactie projecteert een ander debat op het artikel: een engineering-cultuuroorlog die het rapport juist probeert te vermijden.
Cijfer (inhoudelijk t.o.v. artikel) edit
3 / 10
- Technisch herkenbaar,
- maar inhoudelijk grotendeels irrelevant voor wat AcICT daadwerkelijk zegt.
Overzicht in één tabel edit
| Reactie | Inhoudelijke aansluiting op artikel | Cijfer | | ----------------------- | ----------------------------------- | ------ | | Reactie 1 – ironisch | Raakt discours, mist analyse | 5 / 10 | | Reactie 2 – ontologisch | Verdiept architectuurkritiek | 8 / 10 | | Reactie 3 – technisch | Projecteert ander probleem | 3 / 10 |
Eindobservatie (belangrijk) edit
Wat hier zichtbaar wordt, is iets fundamenteels:
- Het hoofdartikel probeert het debat te verplaatsen
- van technologie naar architectuur en besluitvorming.
- Reactie 1 blijft steken in retorische kritiek.
- Reactie 3 valt terug naar technische zekerheden.
- Alleen reactie 2 beweegt in dezelfde richting als het rapport, maar dan radicaler.
Als je wilt, kan ik dit nog:
- expliciet koppelen aan AcICT-rapporttaal vs. werkelijkheid,
- of omzetten in een inhoudelijk sterk LinkedIn-commentaar dat boven deze reacties uitstijgt.
References edit
- ↑ "Samenvatting artikel DUO systeem". ChatGPT. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.
- ↑ "Computable.nl". computable.nl. 2025-12-19. Retrieved 2025-12-20.