Week 14: Wat een machine van je gewoonten maakt
De /insights feature van Claude Code hield een spiegel omhoog na vijf weken dagelijks gebruik. Wat de data terugzag, was niet altijd prettig — maar wel bruikbaar.
Donderdag draaide ik /insights. Een command in Claude Code dat je eigen sessiegeschiedenis analyseert en terugkoppelt: wat werkte, wat niet, welke patronen Claude herkentte in hoe je samenwerkt. Ik wist dat het interessant zou zijn. Ik wist niet dat het ongemakkelijk zou voelen.
De analyse keek terug op ruim dertig dagen en 1.181 berichten verspreid over 98 sessies. Het rapport begon positief — een volledig geautomatiseerde dagelijkse routine, parallelle agents die 114+ branded SVG’s genereren, een complete programmeertaal gebouwd in Rust via zes gemerge pull requests. Dingen waar ik trots op mag zijn.
Daarna kwamen de patronen.
De gewoonten die je niet ziet
Dertig keer een verkeerde aanpak. Achtentwintig keer buggy code. Fragiele pipelines die halverwege breken omdat een tijdelijk bestand al verwijderd was, of omdat encoding in een SVG tekstelement ontsnapte.
Maar het meest treffende was niet de opsomming van fouten — het was de karakterisering. You are a power user who treats Claude Code as an autonomous operations engine. Ja, dat klopt. You issue high-level commands and let Claude figure out the implementation. Ook waar. You are impatient with mistakes. Dat ook.
Het is raar om jezelf teruggekoppeld te krijgen als patroon. Niet als zelfanalyse, maar als empirische observatie uit duizend interacties. De sessiegeschiedenis liegt niet. Jij niet, ik niet, maar de data ook niet.
Het inzicht dat het hardst aankwam: ik schrijf zelden gedetailleerde specs vooraf. Ik geef high-level opdrachten en verwacht dat Claude figureert hoe het moet. Dat werkt 92% van de tijd. De overige 8% zijn die 32 verkeerde aanpakken. De oplossing is simpel — meer upfront context, specifieke bestandspaden, expliciete styleconstraints — maar het vraagt een gewoonte die ik nog niet heb.
Recursie als architectuur
Terwijl ik de aanbevelingen van /insights verwerkte, bouwde ik in Orca een code review agent. Niet voor Orca, maar in Orca. Een multi-specialist architectuur: drie agents met elk een eigen expertise — beveiliging, stijl, logica — die via shared memory hun bevindingen samenvoegen.
Dat is een merkwaardig soort recursie. Een programmeertaal die je aan het bouwen bent, gebruiken om een tool te schrijven die code beoordeelt. De taal had zijn eigen beperkingen bloot gelegd eerder in de week: heterogene parallelle spawning bestaat nog niet. Drie agents tegelijk opstarten met andere typen? Nog niet mogelijk. De oplossing was sequentieel spawnen — minder elegant, maar het werkt.
Die beperking dwong tot een architectuurkeuze: shared memory als coördinatiemechanisme in plaats van directe datacommunicatie tussen agents. Soms zijn beperkingen goede architectuuradviseurs.
Van schijnbaar naar echt parallel
Aan het einde van de week brak er iets open in de Orca runtime. De ToolRegistry — de centrale registratie van beschikbare tools — was niet thread-safe. FanOut en ParallelSpawn operaties leken parallel te draaien, maar deden dat in werkelijkheid niet. Pre-computed resultaten, geen echte concurrentie.
De fix was een refactor naar Arc<T>: gedeeld eigenaarschap via reference counting, zodat meerdere tokio-threads tegelijk toegang hebben tot dezelfde registry. Daarna: twee taken van elk 50 milliseconden — totale uitvoertijd minder dan 150 milliseconden. Wall-clock bewijs dat het werkt.
Het verschil tussen schijnbare en echte parallelliteit is niet altijd zichtbaar in de code. Je moet meten. Dat geldt ook voor andere systemen.
Automation die zijn eigen grenzen kent
Halverwege de week bouwde ik een automatisch episode-update systeem voor de AIToday Live website. RSS feed parsen, metadata extraheren, afleveringen op de juiste pagina’s zetten, deployen. Het systeem werkt nu — maar het bouwen ervan bracht opnieuw de fragiele plek boven tafel: HTML entities in podcast-beschrijvingen die niet netjes escapen, boilerplate tekst die gefilterd moet worden, platform-URLs die soms ontbreken in de feed.
Elke keer als een pipeline breekt, zit de oorzaak in een randgeval dat ik niet voorzag. Dat is geen bug — dat is de aard van het werk. De les die /insights ook gaf: bouw verificatiestappen in na elke fase, niet alleen aan het einde.
Die les hebben we inmiddels geïmplementeerd in de dagelijkse routine. URL health checks, bestandsvalidatie, rapportage over wat handmatige interventie vereiste. Niet als terugblik, maar als geautomatiseerde bewaking per stap.
Wat het met mij deed
Het ongemakkelijke aan de /insights sessie was niet de lijst met fouten. Die wist ik grotendeels. Het ongemakkelijke was de formulering: you are impatient with mistakes en you don’t write detailed upfront specs. Dingen die waar zijn maar die ik mezelf niet zo had beschreven.
Er is een verschil tussen weten dat je ongeduldig bent en het teruggelezen krijgen als patroon uit duizend interacties. Het tweede voelt als bewijs.
Veertien weken in dit experiment merk ik dat de technische uitdaging verschuift. De tools worden beter — Orca als bewijs, de concurrency doorbraak, de automation die zichzelf valideert. Maar de obstakels die overblijven zijn steeds vaker menselijk: gewoonten die ik niet zie, specs die ik oversta, context die ik niet geef.
/insights deed iets dat ik niet had verwacht: het gaf me een buitenperspectief op mijn eigen manier van werken. Niet als oordeel, maar als data. En data kun je iets mee.
De vraag is of je er ook iets mee doet.