---
title: "10 dingen die ik leerde van 4 weken bouwen met AI"
description: "Gisteren de cijfers. Vandaag de learnings. Over AI als tool, over mijzelf als bouwer, en over waarom de zorg meer moet experimenteren."
date: "2024-12-19"
published: true
seriesOrder: 13
tags:
  - Learnings
  - AI
  - Reflection
  - Healthcare
---

Gisteren de cijfers. Vandaag de learnings.

10 dingen die ik leerde van 4 weken bouwen met AI. Over AI als tool, over mijzelf als bouwer, en over waarom de zorg meer moet experimenteren.

**De belangrijkste inzichten?**

→ AI verzint geen goede oplossing. Jij moet zelf bedenken waar de waarde zit.
→ Domeinkennis weegt zwaarder dan technische skills.
→ Met alle moderne tooling bouw ik nog steeds traditioneel EPD-denken.

Dat laatste was een ontnuchterende realisatie.

---

## De aanleiding

Vier weken geleden startte ik een experiment: hoe ver kom je met AI-tooling als je een compleet EPD-systeem wil bouwen voor de GGZ?

Twee dingen waren de aanleiding. Jaren van frustratie over EPD's die nét niet werken zoals de zorg werkt. En de vraag die ik steeds vaker hoorde: "*Maar kun je met AI écht software bouwen?*" Ik besloot het uit te zoeken.

Meer dan 15 jaar werk ik nu in de GGZ. En al die tijd hoor ik hetzelfde verhaal. Van collega's, van behandelaren, van managers: het EPD werkt niet zoals wij werken. Die ene feature die we nodig hebben? Staat op de roadmap. Al 18 maanden. Het budget voor aanpassingen? Tonnen. En dan nog is het niet zeker dat het komt.

Ik weet dit uit eigen ervaring, want ik heb jarenlang bij een EPD-leverancier gewerkt als consultant en product owner. Dus ik begrijp de worsteling om goede, stabiele, functionele, veilige, schaalbare, gebruiksvriendelijke software te bouwen die voldoet aan alle wet en regelgeving. Maar toch, miljoenencontracten, jarenlange implementaties. En aan het eind van de rit nog steeds workarounds in Excel!

Tegelijkertijd zie ik wat er mogelijk is met moderne AI-tooling. Ik gebruik het dagelijks. Maar om me heen zie ik collega's die sceptisch blijven. "*Leuk voor prototypes, niet voor echte software.*" "*AI-code is niet production-ready.*" "*Eén uur coden met AI is drie uur debuggen.*"

Ik wilde het tegenovergestelde bewijzen. De scepsis snap ik, maar die is gebaseerd op hoe AI een jaar of twee geleden werkte. De techniek gaat sneller dan wij ons aanpassen. Dus: niet praten, maar bouwen. In het openbaar. Documenteren wat werkt en wat niet. En kijken hoe ver ik kom, als niet-programmeur.

## Het resultaat

- 118.000 regels code
- 140+ documenten (waarvan 75 formele specs)
- 7 complete modules
- 3 AI-integraties
- 95 GIT commits
- alles op een hobby budget (+/- €200)

---

## Over AI als tool

### 1. Met AI kun je volwaardige functionaliteit snel opleveren

Dat is de belofte, en die klopt. Maar hier komt de nuance die niemand je vertelt: AI verzint geen goede oplossing. Jij moet zélf bedenken waar de waarde zit.

### 2. Verwacht niet dat het eerste antwoord het juiste is

Nooit, eigenlijk. Ga door. Hak in stukjes. Voeg samen. Ontleed totdat je iets hebt waarmee je verder komt. AI is geen orakel. Het is een klant die niet precies weet wat hij wil. Je moet doorvragen. Concretiseren. Stel je een vage vraag, dan krijg je een vaag antwoord. Wordt je scherper, geef je voorbeelden, dan wordt de output beter.

### 3. Gebruik AI als sparringpartner, niet alleen als programmeur

Laat Claude een probleem analyseren vanuit het perspectief van 'lead developer', 'product owner' én 'eindgebruiker'. Dat geeft je drie invalshoeken die helpen om blinde vlekken te spotten.

Of: simuleer een gesprek tussen consultant en klant om een pitch voor te bereiden. Of: "*Wat zou een verpleegkundige hiervan vinden?*" "*Waar zit het risico voor de psychiater?*"

Het gaat om meerdere perspectieven. Daar zit minstens zoveel waarde als in de gegenereerde code.

---

## Over mijzelf als bouwer

### 4. Domeinkennis weegt zwaarder dan technische skills

AI kan code genereren, maar je moet wel snappen wat er staat en weten hoe software werkt. Zeker bij enterprise software zoals een EPD. AI is hier de brug.

Wat AI niet kan: snappen waarom een verpleegkundige overdracht anders werkt dan een artsenbrief. Waarom een risicotaxatie op dát moment in het proces moet zitten. Waarom die ene checkbox er wel toe doet en die andere niet.

Die 15 jaar GGZ-ervaring? Die waren relevanter dan mijn technische skills.

### 5. Je proces blijft gewoon je proces

PRD, Functioneel Ontwerp, Technisch Ontwerp, dat sla je niet over omdat je AI gebruikt. Integendeel. Hoe beter je documentatie, hoe beter de AI-output. "*Garbage in, garbage out*" is nog steeds waar. Alleen nu op een hoger abstractieniveau.

### 6. Cognitive offloading? Ik had het tegenovergestelde

Er wordt gewaarschuwd dat je lui wordt als je alles aan AI overlaat. Misschien, als je besluit om zelf niet meer na te denken.

Maar ik had tijdens dit project juist cognitive overload, de productieve variant. Bouwen, demo's maken, content schrijven, contacten leggen. Alles tegelijk, in vier weken. AI maakt dat mogelijk. Niet door het denken over te nemen, maar door de executie te versnellen.

### 7. Met al die moderne tooling bouw ik nog steeds een vrij traditioneel systeem

De aanpak is innovatief. Het product? Eerlijk gezegd niet heel erg. Hetzelfde EPD-denken als de afgelopen 15 jaar. Dezelfde schermen. Dezelfde workflows. Dezelfde aannames.

Dat was een ontnuchterende realisatie.

---

## Over de zorg en organisaties

### 8. We moeten meer experimenteren

Uit gesprekken hoor ik steeds hetzelfde verhaal: pilots die blijven steken op governance. Op beleid. Op regels. Op commissies die eerst moeten vergaderen.

Allemaal relevant, daar is geen twijfel over. Maar ook allemaal redenen om níet te beginnen.

In een experiment bepaal je zelf de grenzen. Bouw eerst. Leer. En pas dán aan. Probeer niet alle kaders en risico's vooraf te bedenken. De wereld verandert snel en wacht niet op ons 100% waterdichte plan.

### 9. De waarde zit niet in de AI, maar in de data en integratie

De AI zelf is het makkelijke stuk, dat is een API call en een goede prompt. De uitdaging zit in de rest.

Specifiek voor de GGZ: waar somatische zorg veel objectieve datapunten heeft (labwaarden, vitals, scans) hebben we in de GGZ vooral ongestructureerde tekst. Behandelplannen. Decursus. Rapportages. Heteroanamneses. Observaties.

Dát is waar de complexiteit zit. En eerlijk gezegd ook waar het interessant wordt.

### 10. De toekomst is niet een beter scherm, maar geen scherm

Ephemeral UI, vergankelijke interfaces die gegenereerd worden op het moment dat je ze nodig hebt. De agent doet de rest. Geen vaste menu's, geen eindeloze klikpaden. Gewoon: zeg wat je nodig hebt, en het verschijnt.

Dat is niet wat ik gebouwd heb. Maar wel waar ik naartoe wil.

---

## Wat nu?

Dit is wat vier weken bouwen me geleerd heeft. Niet alleen over AI, maar over mijzelf als bouwer en over de zorg waar ik al 15 jaar in werk.

De volgende vraag ligt voor de hand: als ik met moderne tooling nog steeds traditioneel EPD-denken bouw, hoe ziet het EPD van de toekomst er dan wél uit?

Want dat is niet wat ik gebouwd heb (nog niet).

