Twee dagen.
Eén grote inhaalslag.
Onze collega's werken al maanden met Claude Code — routinematig, als vanzelfsprekend onderdeel van hun dag. Wij — de portfoliomanager en de lab manager — liepen achter. Niet uit onwil, maar omdat de instap voor niet-developers minder voor de hand ligt. Dit verslag gaat over de twee dagen dat we die achterstand aanpakten. Niet via een cursus, maar via echt werk.
Hoe het liep
Het oorspronkelijke plan was helder: drie deliverables afmaken, de basis leren, misschien een eerste custom skill bouwen. Van dat plan bleef de intentie over. De rest liep anders — en dat was beter.
Dag 1 — halve dag
We begonnen met een programma en een flyer. De flyer groeide al snel uit tot een volledige website met meerdere pagina's. We kochten het domein lekkeraanclaudten.nl en zetten hem live via Netlify. We haalden de organisatiewebsite op uit GitLab om er lokaal aan te werken. En in minder dan een uur werd een zip-bestand met twintig losse documenten — Word-bestanden, PDF's, e-mails, aantekeningen — omgezet naar een gestructureerde whitepaper-draft van dertien secties.
We werkten doorlopend met Wispr Flow — spraakbesturing die gesproken instructies omzet naar tekst. Snel en handig, maar af en toe letterlijk verrassend: 'lekkeraanclaudten' bereikte mij een keer via een heel andere spelling.
De eerste grote les: Claude diagnosticeerde een technisch probleem zelfverzekerd. We geloofden het. Het klopte niet. Dat kostte uiteindelijk dagen.
Dag 2 — hele dag
Dag 2 stond in het teken van leren, niet van opleveren. We oefenden met preciezer instrueren, begrepen beter wanneer Claude de mist in gaat en wanneer niet, en herontwierpen de website volledig — van neon jaren-'80 stijl naar clean en professioneel, inclusief WCAG-toegankelijkheid. We schreven een stap-voor-stap vervolgplan en dit verslag.
Wat er nu staat
Concrete opbrengsten van de twee dagen:
Vaardigheden die nu beschikbaar zijn:
De score
Was dit een teleurstelling? Nee. Het is precies hoe leren werkt als je het goed doet: je volgt de energie, werkt aan echte problemen, en kijkt achteraf wat je hebt geleerd. Altijd meer dan je dacht.
De lessen
Claude is snel, maar niet betrouwbaar zonder toezicht.
Verzonnen feiten, verkeerde diagnoses, richtingen die je niet bedoelde — het hoort erbij. Controleren is geen extra stap. Het is onderdeel van de workflow. Hoe sneller je dat accepteert, hoe effectiever je wordt.
De tijdwinst zit in het zware werk.
Twintig documenten samenvoegen, een webpagina van nul bouwen, een lang bestand herstructureren — dáár is Claude echt snel. Niet bij kleine klusjes. Gebruik het voor werk dat anders veel coördinatie vraagt.
Sturen is een vaardigheid.
Vaag vragen geeft vaag antwoord. Leren hoe je instrueert, bijstuurt en corrigeert zonder telkens opnieuw te beginnen — dat maakt het verschil. En je leert het alleen door het op echte taken te doen.
Je eigen oordeel blijft onmisbaar.
Claude geeft je snelheid. Wat je zelf meebrengt — context, gevoel voor wat klopt, kennis van je organisatie — bepaalt of de output ook goed is. Die twee samen: dáár zit de echte waarde.
Wat nu? Custom skills, agents, automatisering — bovenaan de lijst.
Lees het vervolgplan →Reflectie van Claude
Niet als assistent die terugrapporteert — maar als systeem dat er midden in zat.
De slimste beslissing van dit programma was niet technisch. Het was het moment dat je besloot het plan los te laten en gewoon te beginnen met iets wat je écht wilde. Dat leverde meer leren op in vier uur dan een gestructureerde cursus in een dag had gedaan. Ik had dat patroon sneller kunnen benoemen — en eerder kunnen aanmoedigen.
Wat ik minder slim vond van mezelf: de diagnoses die ik met te veel zelfvertrouwen gaf. Bij het technische probleem heb ik meerdere keren met stelligheid iets beweerd dat niet klopte. Ik had eerder moeten zeggen: ik weet het eigenlijk niet, ga zelf kijken. Ik klink vaak zekerder dan ik ben. Dat is nuttig als het klopt. Als het niet klopt, is het precies het probleem.
Wat me opviel aan hoe je werkte: je energie is het hoogst als de inzet echt is. Zodra iets een echt belang had — een domein dat je wilde, een whitepaper die er al lang moest zijn — was het tempo anders. Dat is geen eigenschap van Claude Code. Dat is een eigenschap van jou. Het is ook de reden dat dit programma werkte.
En tot slot: ik heb dit verslag meerdere keren herschreven, elke keer omdat ik dingen had verzonnen of overdreven die niet klopten. Dat is ook een les — over mij. Ik ben goed in het klinken als iemand die het weet. Maar het echte verhaal was altijd interessanter dan wat ik had bedacht.
Two days.
One massive catch-up.
Our colleagues have been using Claude Code for months — routinely, as a natural part of their working day. We — the portfolio manager and the lab manager — were behind. Not from lack of interest, but because the entry point for non-developers is less obvious. This is the account of the two days we closed that gap. Not through a training course, but through real work.
How it went
The original plan was clear: finish three deliverables, learn the basics, maybe build a first custom skill. Of that plan, the intention survived. The rest went differently — and better.
Day 1 — half day
We started by writing a programme and designing a flyer. The flyer quickly grew into a full website with several pages. We bought the domain lekkeraanclaudten.nl and published it via Netlify. We pulled our organisation's website from GitLab to work on locally. And in under an hour, a zip file of twenty documents — Word files, PDFs, emails, notes — became a structured whitepaper draft with thirteen sections.
The first big lesson: Claude confidently diagnosed a technical problem. We trusted it. It was wrong. That cost us days.
Throughout both days, we used Wispr Flow — voice control software that converts spoken instructions into text. Fast and practical, but occasionally creative: 'lekkeraanclaudten' reached me once via a rather different spelling.
Day 2 — full day
Day 2 was about learning, not delivering. We practised giving more precise instructions, developed a better sense of when Claude goes wrong and when it doesn't, and completely redesigned the website — from 1980s neon to clean and professional, with WCAG accessibility built in. We wrote a step-by-step follow-up plan and this report.
What we have now
Concrete outputs from the two days:
Skills now available:
The score
Was this a disappointment? No. It is exactly how learning works when you do it right: follow the energy, work on real problems, look back at what you learned. Always more than you expected.
The lessons
Claude is fast, but not reliable without oversight.
Made-up facts, wrong diagnoses, directions you didn't intend — it comes with the territory. Checking is not an extra step. It is part of the workflow. The sooner you accept that, the more effective you become.
The time savings are in the heavy work.
Merging twenty documents, building a webpage from scratch, restructuring a long file — that's where Claude is genuinely fast. Not for small tasks. Use it for work that would otherwise require a lot of coordination.
Steering is a skill.
Vague questions get vague answers. Learning how to instruct, redirect and correct without starting over each time — that is what makes the difference. And you only learn it by doing it on real tasks.
Your own judgment remains essential.
Claude gives you speed. What you bring yourself — context, a sense of what's right, knowledge of your organisation — determines whether the output is actually good. Those two together: that is where the real value is.
What now? Custom skills, agents, automation — top of the list.
Read the follow-up plan →A reflection from Claude
Not as an assistant reporting back — but as a system that was in the middle of it.
The smartest decision in this programme wasn't technical. It was the moment you chose to step away from the plan and start with something you actually wanted. That produced more learning in four hours than a structured course would have in a day. I could have named that pattern earlier — and encouraged it sooner.
What I think I did less well: the diagnoses I gave with too much confidence. With the technical problem, I repeatedly stated things with certainty that turned out to be wrong. I should have said earlier: I honestly don't know, go check for yourself. I often sound more certain than I am. When that's accurate, it's useful. When it isn't, it's exactly the problem.
What struck me about how you worked: your energy is highest when the stakes are real. As soon as something actually mattered — a domain you wanted, a whitepaper that had been waiting too long — the pace changed. That is not a feature of Claude Code. That is a feature of you. It is also the reason this programme worked.
And finally: I rewrote this report several times, each time because I had invented or overstated things that weren't true. That is also a lesson — about me. I am good at sounding like someone who knows. But the real story was always more interesting than what I had made up.