De beste programmeertaal is ABN

Als kind vond ik programmeren magisch. Je typte code in bv MS Basic, Pascal of Delphi, worstelde met de juiste syntax, haken, punten en komma's, en als alles perfect stond gebeurde er iets magisch, zoals een zelf ontworpen pop-up op je scherm (wie herinnert zich 'Hello World'?) of wat later in mijn pubertijd een eenvoudig spelletje, een zelfgeprogrameerde manier om hoeken en zijden van driehoeken te berekenen, of om muziek te transponeren die ik graag speelde.

Maar eerlijk is eerlijk; echt programmeren wordt al heel snel heel ingewikkeld, kent een vrij stijle leercurve en de kennis verouderd erg snel. De ene na de andere taal volgde elkaar op: C, C++, Java, VBA, en niet lang daarna de html, css, vrml, javascript, AJAX en PHP.
Niet te overzien, niet bij te houden. Dus ik ben nooit een programmeur geworden en zag computers meer als hobby . Ik heb. geleerd om tevreden te zijn met te begrijpen hoe dingen werkten en niet langer te ambiëren om zelf iets te willen maken.

Jaren later werkte ik in Zwitserland en hadden we in ons bedrijf een eigen afdeling met programmeurs. Ik mocht dan vertellen wat ik wilde hebben, zij stelden allerlei vragen, maakten het product en bouwden dan een versie die ik kon testen en van verbeteringen voorzien. De samenwerking met een ervaren programmeur was geweldig; we spraken allebei een andere taal en maakten samen mooie dingen, maar ik bleef volledig afhankelijk van hun beschikbaarheid, mogelijkheden, kennis en soms ook wel goodwill. Het voelde altijd als een kwetsbare samenwerking; pas als alle voorwaarden intact waren (tijd, ondersteuning, opleiding, geld) dan konden we maken wat ik voor ogen had, anders niet. 

Fast forward naar 2026. Ik werk veel met het programma Claude, en als ik iets wil programmeren met Claude Code (zelfde pakket, andere tool). Voor iedereen beschikbaar als gratis download, en als je 20 euro per maand betaald kan je echt al serieuze projecten ondernemen. Claude Code voelt als die zeer ervaren programmeur, webdeveloper, ICT manager en data-base expert in 1 tool. Altijd beschikbaar, altijd bereidwillig en met minimale instructie al resultaat.
En de programmeertaal? Gewoon Algemeen Beschaafd Nederlands. 

Eerst praten, dan pas plannen

Hoe maak je dan iets, zonder enige of met zeer gelimiteerde programmeer ervaring? 

Ik zal een recent projectje van mij hier wat uitwerken.
Ik wilde beter overzicht hebben over het verkrijgen van hulpmiddelen en voorzieningen, en vooral; waar moet je aankloppen voor welk product. Is de rollator iets voor de WMO? Wat is de WLZ? Als iemand een handbike nodig heeft, maar al een WLZ erkenning heeft, waar moet je dan de aanvraag indienen? Voor een revalidatiearts vragen die wekelijkst langskomen, lastig te beantwoorden zijn, en waarvan de regels bovendien per gemeente kunnen verschillen.  

Dus wat mij betreft typisch een klusje om op te pakken met AI.

Stap 1: Brainstorm

De eerste stap is wat mij betreft de AI opdracht geven om een brainstorm op te zetten. Wat wil je precies maken? Wat wil je dat de AI maakt? Op welke manier wil je je vraag stellen, en op welke manier wil je antwoord krijgen? Hoe verzeker je ervan dat het antwoord juist is? Hoe blijft het systeem op de hoogte van de laatste stand van zaken / regels? Etc.

Ik begin dan zelf graag in Claude Chat. Bijvoorbeeld met de prompt

"Ik wil een simpele webapp bouwen die een revalidatiearts in een paar vragen laat zien wie een hulpmiddel betaalt: Zvw, Wmo, Wlz, UWV of eigen rekening. Voor aios en ergotherapeuten, moet op de poli in een minuut te gebruiken zijn. Ik wil er zelf van leren hoe je een beslisboom als data modelleert in plaats van als geneste if-statements. Maak hier een deployment-prompt voor Claude Code van. Als je nog vragen hebt, stel die dan eerst"

Uit deze vrij eenvoudige paragraaf kwamen enkele aanvullende vragen ter verdieping, onder andere of dit voor landelijke regels gold of ook voor lokale regels (beiden), of de onderliggende wetgeving meegenomen moest worden (ja), en of het systeem zichzelf moet kunnen updaten (ja).

Tenslotte gaf ik nog instructie dat alle teksten moesten worden voorzien van een referentie, zodat ik kon checken of de antwoorden klopten of dat de AI iets had verzonnen en de opdracht dat als de AI geen antwoord had of conflicterende antwoorden had dat hij dat expliciet moest benoemen. Als laatste stap gaf ik de opdracht om de prompt nog eens kritisch te bekijken, de sterke punten en de zwakke punten te benoemen en voor de zwakke punten een oplossing te geven.

Daaruit kwam een volledige prompt, die je hier kunt vinden

Merk op dat er hierboven geen enkele regel staat, geen code, geen ICT-taal, geen exacte beschrijving van het eindproduct. Het zijn vakinhoudelijke wensen, en ze zijn in normaal Nederlands beschreven.

Stap 2: Projectplan

Pas nadat ik tevreden was over het resultaat van de brainstorm heb ik de AI een projectplan laten schrijven. Dat plan is een paar keer heen en weer gegaan voordat er iets gebouwd werd. Die revisierondes leverden de eisen op waar het project later op is gaan draaien:

• de inhoud staat volledig los van de code — in het programmabestand staat geen enkele regel over hulpmiddelen, wetten of loketten;
• elke vraag heeft verplicht een "weet ik niet"-uitgang;
• geen enkel pad is langer dan zes vragen;
• geen uitkomst zonder minstens één werkende bronverwijzing én een datum waarop die is gecontroleerd;
• geen enkele uitkomsttekst belooft een vergoeding — de wijzer wijst een loket aan, meer niet;
• en het bronnenonderzoek is fase nul, dus vóór er een letter code bestaat. En er is een voorziening opgenomen om aan het begin van de maand alle bronnen opnieuw te checken, dit ivm veranderende wet- en regelgeving. 

Op deze manier is het bronnendocument de bron van waarheid geworden: per afbakeningsregel het artikel- of paragraafnummer, de datum van de bron, en de datum vanaf wanneer de regel geldt. Elke tak in de boom is daarnaar te herleiden. Bij een wijziging in de wet- en regelgeving gaat eerst het bronnendocument om, dan pas de boom. Nooit andersom. Dus het is prima mogelijk om de beslisboom te blijven gebruiken als de overheid of de gemeenten hun regels veranderen. 

Ook aandacht voor wat er bewust níét in zit stond in het plan. Geen bedragen, eigen bijdragen of eigen risico — twee UWV-pagina's noemden op dezelfde dag verschillende drempelbedragen. Geen indicatiecriteria voor het hulpmiddel zelf: dat is een medische vraag, geen financieringsvraag. Geen merken, geen leveranciers, geen enkele vorm van patiëntregistratie.

3. Bronnen en informatie verzamelen.

4. Bouwen 

Het bouwen verliep daarna in zes (automatische) stappen: het bronnenonderzoek vastleggen, een de beslisboom bouwen, een validator makem, de schermen ontwikkelen, alles (laten) testen en tot slot de documentatie maken en de publicatie van de tool conform het projectplan.
Interessanter dan die volgorde is wat er met de eisen uit het plan gebeurde. Ze zijn allemaal machinaal afdwingbaar geworden. "Elke vraag heeft een weet-ik-niet-uitgang" is nu een validator die weigert te draaien als die uitgang ontbreekt, met een Nederlandse foutmelding die zegt bij welke knoop het misgaat. "Geen pad langer dan zes vragen" idem. "Geen tekst belooft een vergoeding" werd geverifieerd in een aparte test. De AI maakte vijftien uitgewerkte casussen met een vastgelegde verwachte uitkomst, elk met de bronregel waaruit die uitkomst volgt; wie een route verlegt, ziet meteen welke casus hij geraakt heeft. De publicatie is achter die controles gezet: rood betekent dat er niets naar buiten gaat.

En omdat de inhoud nu losstaat van de code kan he probleemloos een tak toevoegen zonder de code te openen; een volgende provincie erbij (ik heb me eerst gefocust op mijn eigen provincie; Limburg) is een nieuw databestand, geen nieuwe software.

Wat deze aanpak sterk maakt

Het eerlijke antwoord op "hoe moeilijk was dit" is: er zit een flinke leercurve in. Je moet leren:

• om een idee te verzinnen en de vertaling te maken van de 'wens' naar 'een product'
• om je idee zodanig de formuleren dat de AI je helpt om de prompt te schrijven (ga dit soort dingen vooral niet zelf 'prompten'; kijk maar eens hier hoe uitgebreid en complex de uiteindelijke prompt is geworden
• welk proces je helpt om de prompt optimaal te krijgen.
  Enkele technieken daarvoor heb ik hierboven beschreven en er zullen in de toekomst nog vast meer van dit soort technieken op deze blog langskomen.

De revisierondes zaten op de goedkoopste plek: vooraf. Een eis herformuleren in een plan kost minuten, hem er achteraf in vlechten kost dagen. En de eisen zijn niet vrijblijvend, maar toetsen geworden die blijven staan als ik er over een jaar niet meer aan denk.

De veroudering van de kennis áchter het project was een aandachtspunt en is meegenomen als verbetering in plaats van een bedreiging. Juist door het iteratief proces van de prompt uit te dagen zichzelf te verbeteren. Elke uitkomst draagt nu de datum waarop hij tegen de bronnen is gecontroleerd, de voettekst waarschuwt zichtbaar zodra die datum ouder is dan twaalf maanden. Als bonus loopt er  op de derde van elke maand een check die kijkt of de wetteksten en gemeentegegevens nog zijn wat ze waren.
Die controle ziet overigens verándering, geen betekenis — of een advies daardoor moet wijzigen, blijft mensenwerk. Dat de handreiking van het Zorginstituut van 4 december 2020 dateert en nooit is herzien, terwijl de uitspraak over geclusterd wonen van januari 2025 is, kan geen script voor je wegen.

Doe het zelf: plak & vul in: het gesprek vóór het bouwen

Dit is het blok waarmee je een eigen bouwproject kunt starten. Niet "bouw een app die…", maar:

De rubriek "Wat gebeurd er als het antwoord onbekend is" is degene die ik in het begin zelf oversloeg, en die achteraf het meest heeft opgeleverd.

Wat mij betreft is de vraag "kan ik programmeren?" en zeker "welke programmeertaal is de beste om mee te starten?" hiermee obsoleet geworden. De vraag is veel neer of je je eigen wens nauwkeurig genoeg kunt opschrijven zodat er iets mee te bouwen valt.
Voor de meesten van ons in de zorg is dat een schrijfvaardigheid, geen technische. 

Disclaimer: het schrijven van een tool die werkt is absoluut niet hetzelfde  als een tool maken die geschikt is voor productie; bovenstaande procedure werkt prima als 'proof of concept', voor een 'one-off', een 'personal tool' etc, maar als je een tool wil maken die gedistribueerd kan worden onder meerdere gebruikers of zelfs als betaalde Saas (Software as a Service) aangeboden wordt zijn er nog heel wat extra stappen te nemen.