Week 116 bij de overheid. Het is een tijdje stil geweest. In juli schreef ik nog Wat ben je aan het doen?. Daarna niets meer.

Er is veel gebeurd. In mei is mijn derde dochter geboren - daar ben ik natuurlijk nog steeds druk mee. Mijn vrijdagen besteed ik nu bij DittoCare, waar ik help met het evalueren of LLM’s doen wat ze moeten doen in medische contexten. Die vrijdag gebruikte ik eerst om weeknotes te schrijven, dus dat is ook mijn excuus waarom die gestopt zijn. En ik ben iets aan het bouwen.

Dat laatste wil ik het vandaag over hebben.

peerpressure

In augustus was ik een weekend weg met vrienden. We zitten niet excessief op onze telefoon, maar bij vlagen wel. Twitter, BlueSky, LinkedIn. Het gebruikelijke. En ik vroeg me af: is dit nou echt nuttig?

Ik dacht: het zou fijn zijn als we elkaar kunnen helpen om niet op de telefoon te zitten. Peer pressure. Sociale druk, maar dan positief.

Twee maanden later, met avonden werken en af en toe in het weekend, was er een app: peerpressure. Een social digital detox app. Je start een focussessie, anderen scannen een QR-code, en jullie zijn allemaal geblokkeerd van de apps die je hebt gekozen. Samen.

De app draait nu op Android (live op Android) en binnenkort ook live op iOS. Mensen gebruiken de app. Ik kreeg vorige week een email van iemand uit Italië met drie feature requests. Geen idee hoe ze de app hebben gevonden. Ik adverteer niet (buiten dit stukje dan).

Zonder code

Hier is het interessante: ik heb geen regel code geschreven. Nul. Nada. Alles is gebouwd door te praten tegen Claude Code.

Letterlijk praten. Via Wispr Flow1, een speech-to-text tool die goed genoeg is dat ik gewoon kan uitleggen wat ik wil. Claude Code vertaalt dat naar code. Dart voor de Flutter app. Kotlin voor Android. Swift voor iOS.

De cijfers: 235 commits over 2 maanden. 32.838 regels Dart. 3.813 regels Swift. 1.129 regels Kotlin. Totaal ongeveer 38.000 regels code die ik niet heb geschreven.

Om duidelijk te zijn: ik heb wel een technische achtergrond. ML engineering, backend development. Maar ik spreek geen Dart, Kotlin of Swift. Ik zou niet weten hoe ik een Flutter app moet compileren, laat staan hoe ik native code voor iOS en Android moet integreren. Claude Code doet dat allemaal.

Hoe het werkt

Een typische sessie ziet er zo uit:

Ik zit in mijn werkkamer. Ik start Claude Code in de terminal met claude --dangerously-skip-permissions - zodat het gewoon kan doorwerken zonder steeds om toestemming te vragen. Dan begin ik te praten.

“Oké, ik wil dat gebruikers hun account kunnen verwijderen. Dat moet in settings zitten. Voeg een nieuwe card toe met een waarschuwing dat dit destructief is. Maak goede copy. En het account moet echt worden verwijderd uit Firestore. Maak daar een plan voor.”

Claude maakt een plan. Meestal is het goed. Soms itereren we wat. Dan gaat het aan de slag.

Ondertussen doe ik andere dingen. Stofzuigen. Brood bakken. Huishoudelijke taken. Claude werkt door - soms twintig minuten, soms een half uur. Als het klaar is, of als het een vraag heeft, kom ik terug. Ik kijk naar het resultaat in de emulator. Het werkt of het werkt niet. Ik geef feedback. Het gaat verder.

Dit is heel anders dan hoe ik vroeger werkte. Vroeger had ik makers-tijd nodig. Blokken van vier uur om in de flow te komen. Nu kan ik context switchen en toch dingen gedaan krijgen. Claude houdt de context voor mij vast. Ik hoef niet alles in mijn hoofd te houden.

Dat is het eigenlijke verschil. De cognitieve last van context-switchen is uitbesteed aan de AI.

Wat er mis ging

Natuurlijk gaat niet alles soepel. Soms zitten we vast. De low-level integratie tussen native code en Flutter is lastig. Informatie doorgeven van Kotlin of Swift naar Dart kan complex zijn. Dan itereren we een tijd.

Maar dit voelt niet anders dan wanneer je het zelf zou doen. Je zou ook een dag kwijt zijn aan het uitzoeken van dit soort details. Het verschil is dat ik het in kleine stukjes doe. Tien minuten hier, vijftien minuten daar. Tussen andere dingen door.

Het moeilijkste bleek uiteindelijk niet de techniek, maar de bureaucratie. De app stores. Google Play wilde precies weten wat ik deed in de onboarding. Apple heeft eindeloze reviewprocedures. Claude Code hielp me zelfs daarmee. Screenshots van formulieren, feedback van reviewers - het las mee, vulde in, adviseerde.

Een ironisch detail voor iemand die bij de overheid werkt: het administratieve gedoe van app stores is wat ik het meest haat. Niet omdat het zoveel tijd kost, maar omdat het zo taai is. Formulieren invullen. Schermafbeeldingen uploaden in precies de juiste formaten. Wachten op reviews. Dan feedback krijgen en opnieuw beginnen.

Het stemprobleem

Praten met je computer is cruciaal voor hoe ik dit doe. Ik kan veel meer uitleggen in spraak dan ik zou typen. Ik corrigeer mezelf terwijl ik praat. “Doe dit op Android, nee wacht, iOS bedoel ik.” Wispr Flow haalt die correcties eruit. De prompt wordt schoon.

Ook herhaal ik mezelf vaak, vanuit verschillende invalshoeken. Dat werkt goed. Het maakt de instructies duidelijker. Mijn prompts worden veel langer dan wat ik zou typen. Peter Steinberger werkt juist met korte prompts van 1-2 zinnen in Codex. Voor Claude werken langere uitleg beter, in mijn ervaring.

Er is wel een nadeel: ik kan dit alleen doen als ik alleen ben. Niet met familie in de buurt. Niet op kantoor. Niet in de trein. Alleen mijn baby mag erbij zijn; zij is de enige die niet raar opkijkt als ik tegen mijn laptop praat.

Dit betekent dat ik eigenlijk niet meer op deze manier kan werken als er mensen om me heen zijn. Typen voelt nu als een belemmering. Dat is een vreemde omkering.

Het magische moment

Weken werkte ik met emulators. Gesimuleerde telefoons op mijn laptop. Dan, voor het eerst, installeerde ik de app op mijn echte telefoon. En op de telefoon van mijn partner.

Ik startte een sessie. Zij scande de QR-code. We zaten ineens allebei vast. Geblokkeerd van Signal. Niet handig op dat moment, maar wel magisch.

Dat was het moment dat ik doorhad: we hebben iets gebouwd dat werkt. Echt werkt. Op echte apparaten. Voor echte mensen.

Zonder code te kunnen lezen

Wat opvalt: de code zelf bekijk ik zelden. Het gedrag van de app is wat telt. Dat leidt soms tot vermoedens.

Bijvoorbeeld: op een gegeven moment merkte ik dat sommige apps wel geblokkeerd werden en andere niet. Inconsistent. Ik vermoedde: er zijn waarschijnlijk meerdere lijsten van apps verspreid door de codebase die niet synchroon lopen.

Zonder een regel code te hebben gelezen, instructeerde ik Claude om dit te onderzoeken en DRY (Don’t Repeat Yourself) te maken. Dat deed het. De analyse die het terugstuurde bevestigde mijn vermoeden.

Dit is “behavioral debugging”. Je ziet wat er gebeurt, je hypothetiseert wat de architectonische oorzaak zou kunnen zijn, je laat Claude het oplossen.

Wat dit betekent voor de overheid

Eerder schreef ik hoe Claude Code me hielp met het vertalen van 1146 regels code voor Regelrecht. Dit is een extensie van dat idee.

Bij Regelrecht bouwen we proof of concepts van hoe wetgeving machine-uitvoerbaar kan worden. Wat ik de laatste maanden steeds duidelijker zie: het bouwen van die PoC’s is beleidsvorming. Niet uitvoering. Vormgeving.

Dit klinkt misschien vreemd. Beleidsvorming gebeurt toch met nota’s, memo’s, kamerbrieven? Maar wat we doen is iets anders. We herformuleren de vraag van “Hoe zou het moeten zijn?” naar “Kijk, zo zou het kunnen werken.” Die verschuiving maakt alle verschil.

We zijn nu met een soort roadshow bezig met onze Machine Law (wat we nu RegelRecht noemen) demo. Langs bij wetenschappers, bestuurders, beleidsmakers, juristen. Steeds hetzelfde patroon: we starten met een gesprek, een paar slides. Mensen zijn licht sceptisch. Dan starten we de demo. Mensen gaan rechtop zitten. De vragen worden inhoudelijker. Het gesprek verschuift van abstracte governance-praat naar concrete mogelijkheden.

Een prototype doet iets wat geen beleidsdocument kan: het maakt het abstracte tastbaar. Het verplaatst de discussie van “wat als” naar “wat nu”. Voordat je iets laat zien, praten mensen over frameworks en principes. Zodra ze zien dat je een wet in code kunt stoppen en er antwoorden uitkomen, worden ze ineens concreet. “Kunnen we dit ook voor de WOZ?” “Hoe zit het met privacy?” Échte vragen in plaats van buzzwords.

Dit werkt alleen als engineers en beleidsmakers samen optrekken. Niet in gescheiden werelden. Dit is geen “opdracht” die je op afstand geeft aan een team dat het dan uitvoert. Je moet samen ontwikkelen, samen vormgeven wat mogelijk is en wat de implicaties zijn. Dat samen-ontwikkelen doorbreekt de traditionele scheiding tussen denken en doen, tussen beleid en techniek.

Door te bouwen maak je tastbaar wat mogelijk is en wat de implicaties zijn. Dat is veel effectiever dan memo’s schrijven. Het helpt mensen alignen. En met tools als Claude Code wordt dit economisch haalbaar voor beleidsteams.

Om duidelijk te zijn: dit is niet klaar voor productie bij de overheid. Daarvoor hebben we taalmodellen nodig die we zelf draaien, niet op Anthropic’s servers. We hebben betere guardrails nodig. Maar voor prototyping? Dit heeft de potentie om alles te veranderen.

Als je dit wilt proberen

Begin klein. Ik bouwde voor mijn oudste dochter een wiskundespelletje met haar favoriete tekenfilmdier. Een HTML-bestand op mijn laptop. Nergens gepubliceerd. Zij vindt het leuk. Dat is genoeg.

De belangrijkste mindset: verwacht veel van de tool, maar wees niet bang voor fouten. Claude Code maakt voortdurend fouten. Je moet het regelmatig terug op de rails krijgen. Dat is oké.

En: laat het jou vragen stellen. Dat is krachtig. Als Claude vraagt: “Bedoel je dit, of bedoel je dat?” - gebruik dat. Het helpt jullie allebei.

Wat nu?

Peerpressure is nu live (op Android). Het kost me een paar tientjes per maand om te draaien. Als het veel gebruikers krijgt, moet ik een echt plan maken. Voor nu: ik blijf doorwerken. Features toevoegen. Reageren op die Italiaanse emails.

Maar het grotere plaatje is dit: we leren wat mogelijk is. Bij de overheid denk ik dat veel meer mensen dit zouden moeten doen. Beleidsadviseurs. Architecten. Productmanagers. Niet omdat ze developers moeten worden, maar omdat maken > schrijven.

Wel een waarschuwing: je hebt expertise nodig om dit goed te doen. Niet per se expertise in Dart of Swift, maar wel begrip van software architectuur, van wat je bouwt, van hoe systemen werken. Ik denk dat seniors hier echt gaan excelleren. En ik denk ook dat juniors het moeilijker krijgen - je leert minder door te doen als de AI het werk doet. Dat is een serieus probleem waar we over moeten nadenken.

En dan is er security. Ik lees de code niet zelf, dus hoe weet ik dat het veilig is? Eerlijk antwoord: ik vraag Claude Code om security reviews te doen. Is dat genoeg? Misschien niet. Maar ik denk dat ik het nu grondiger doe dan wanneer ik het zonder Claude zou doen - ik heb ook niet per se een security achtergrond. Het blijft een spanningsveld.

En voor legacy reductie? Dat is een ander verhaal. Eentje waar we binnen de overheid over moeten beginnen nadenken. Dit soort tools gaan impact hebben op hoe we productiesoftware bouwen. Dat is onvermijdelijk.

Voor nu: als je dit leest en denkt “interessant” - probeer het. Bouw iets. Iets kleins. Iets persoonlijks. Kijk wat er gebeurt.

Ik praat tegen mijn computer. Mijn computer bouwt apps. Die apps draaien op telefoons van mensen in Italië.

Dat is niet normaal. En dat is precies waarom het interessant is.

Verder lezen: Simon Willison en Peter Steinberger schrijven ook over werken met AI coding tools. Voor Regelrecht zie minbzk.github.io/regelrecht.

  1. Full disclosure: dit is een affiliate link. Als jij je aanmeldt via deze link, krijg jij één maand gratis en krijg ik twee maanden gratis. Win-win, zou ik zeggen. Ik win dan wel twee keer zo hard, maar goed. ↩