Week 8: Met de vinger boven de delete-toets

Vrijdag was ik ziek. Niet dramatisch, maar genoeg om normaal gesproken op de bank te kruipen met een boek. Dat deed ik niet. In plaats daarvan zette ik Claude Code aan het werk. Niet voor werk, maar voor projecten die ik zelf leuk vind. Het voelde als een compromis: ik hoefde niet actief te coderen, de agents deden het zware werk, en ik stuurde bij waar nodig.

Maar het was geen rust. Elk afgerond idee gaf een shot dopamine, dat ervoor zorgde dat ik het volgende oppakte. Bouwen, resultaat zien, volgende idee. Bouwen, resultaat, volgende. Ik moet dit voor mezelf evalueren, schreef ik in mijn journal. Dat is eerlijk. Minder eerlijk is dat ik diezelfde avond nog drie ideeën uitwerkte.

Twee plannen, twee problemen

Een dag eerder had ik twee plannen laten maken met de brainstorming skill. Het eerste: de Conversation Coach uitbreiden met audio-analyse. Het tweede: een contradictie-detector die tegengestelde standpunten van podcastgasten herkent. Twee onafhankelijke features, dus ik maakte twee worktrees aan - aparte werkruimtes zodat de agents elkaar niet in de weg zitten. Net als twee collega’s die elk aan een eigen branch werken.

Het idee was efficiënt. De praktijk was chaotisch. Elk plan heeft meerdere agents die om input vragen wanneer er keuzes gemaakt moeten worden. Twee plannen tegelijk betekende twee sets agents die door elkaar heen om aandacht vroegen. De cognitieve belasting was te hoog. Ik legde één plan aan de kant.

En dan de worktree-les. Na uren itereren op de Conversation Coach rapporten - minuten per aflevering, vier maanden aan data - was ik tevreden. De worktree werd gemerged naar main en opgeruimd. Maar de gegenereerde rapporten stonden in die worktree. Ze gaan niet naar GitHub (te groot, opnieuw te genereren). Weg. Alles opnieuw. Niet desastreus, wel vervelend. En het tegendeel van efficiënt.

Met de vinger boven Enter

De contradictie-detector bracht een ander soort moment. Om 160+ gastenafleveringen met elkaar te vergelijken wilde ik een lokaal model gebruiken - goedkoper dan de cloud. Na twee uur ontwikkeling en twaalf uur draaitijd waren de resultaten teleurstellend. Lokaal draaien zou dagen duren. Herberekenen was geen optie. En het moest draaien op mijn notebook, waar ik ook gewoon op werk.

Ik had het delete-commando al ingetypt. Twee uur werk weggooien voelt anders wanneer AI het gebouwd heeft. Er zit geen bloed, zweet en tranen in. De binding is minder. Dat is een voordeel van deze manier van werken: je bent eerder geneigd om iets weg te gooien dat niet werkt.

Maar voordat ik op Enter drukte, stelde ik nog één vraag: “Wat zou het kosten met een cloud-model? Hoe lang duurt dat?” Het antwoord verraste me. Met Claude Haiku vielen de kosten mee. Dus ik zette door. Een dag later had ik een werkende detector die contrasterende standpunten tussen gasten identificeert. Van bijna-verwijderd naar bruikbaar, door één vraag.

Cognitive debt

Terwijl de agents werkten, las ik een artikel van Margaret Storey: How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt. Haar punt: je bouwt steeds minder een mentaal model op van wat je met coding agents maakt. Ik herken dat. Bij mijn ambitieuzere projecten experimenteer ik met het creëren van nieuwe functionaliteiten zonder de implementaties te beoordelen. Goed getest, met guardrails rondom codekwaliteit en duplicatie. Maar het risico is reëel: elke nieuwe feature wordt moeilijker te begrijpen als je geen helder beeld hebt van het geheel.

Dat leidde tot een situatie die ik bizar vond en tegelijk volkomen logisch. Drie Claude Code sessies tegelijk. Sessie 1: het contradictie-plan uitvoeren. Sessie 2: een mentaal model opbouwen van mijn eigen project, alsof ik een nieuw teamlid was dat onboarded moest worden. Sessie 3: functionele documentatie schrijven. De eerste twee op mijn notebook. De derde via Claude.ai, verbonden met mijn GitHub project, bediend vanaf mijn telefoon. Onderweg.

Is dat productief of is dat het probleem dat Storey beschrijft? Ik gebruik AI om te begrijpen wat AI voor me heeft gebouwd. De ironie ontgaat me niet.

Jezelf laten beoordelen

Ondertussen bouwde ik iets dat nog ongemakkelijker voelt: een AI die beoordeelt of mijn eigen podcast relevant is voor de luisteraar. De Luisteraar Fit Score neemt het perspectief van onze doelpersona en scoort elke aflevering op zes criteria. Concrete voorbeelden, herkenbare problemen, praktische toepasbaarheid.

Eerder die week had ik al geëxperimenteerd met AI-kritiek. In Claude Desktop vroeg ik: “Roast my chats from last week and challenge me where to do better!” De feedback was soms scherp, soms hilarisch. Zoals: “Je besteedt serieuze tijd aan PDF-opmaak. Twee chats gaan over het reverse-engineeren van een PDF-design. Dat is werk voor een designer of een stagiair.” Touché.

Het bouwen van de Conversation Coach koste een uur voor de eerste versie. Het verfijnen en precies krijgen zoals ik het wilde koste twee dagen. Dat patroon is een les op zich. De eerste opzet is snel, het echte werk zit in de iteratie. Bij de Luisteraar Fit Score was het niet anders: halverwege moest ik de schaal aanpassen van 0-10 naar 0-5 voor consistentie, wat een cascade aan wijzigingen door alle dashboards veroorzaakte.

Bijsturen

Hoe stuur je iets aan waar je steeds minder van begrijpt? Deze week gaf daar een paar antwoorden op.

Wat werkt: plannen maken voordat je begint. Ik gebruik een brainstorm-skill die doorvraagt waar het plan vaag is. Dat voorkomt dat agents halverwege vastlopen op onduidelijkheden. En na elke wijziging direct testen - niet drie stappen in één keer, maar steeds één ding veranderen en controleren of het klopt.

Wat niet werkt: te veel tegelijk. Twee plannen parallel met elk meerdere agents klinkt efficiënt, maar elke agent vraagt op onvoorspelbare momenten om input. De ene wil een architectuurkeuze, de andere een naamgevingsconventie. Ik schakelde voortdurend van context en verloor overzicht. Eén plan is al cognitief belastend genoeg.

De verrassingen zitten in de details. De Luisteraar Fit Score werkte prima - tot ik halverwege de schaal aanpaste van 0-10 naar 0-5 voor consistentie met andere metrics. Dat klonk als een kleine wijziging. Het was een cascade door vier dashboards, trendcharts en overzichtspagina’s. Bij de contradictie-detector had het model de gewoonte om JSON te verpakken in markdown-codeblokken. De oplossing - structured output met Pydantic - was beter dan wat ik oorspronkelijk had, maar het kostte een halve dag bijsturen om daar te komen.

Het patroon dat ik zie: de eerste versie van iets bouwen gaat snel. Het verfijnen kost twee tot drie keer zoveel tijd. En het bijsturen zit niet in grote koerscorrecties, maar in tientallen kleine beslissingen. Welke schaal gebruik je? Hoe ga je om met een provider die anders reageert dan verwacht? Waar stop je met features toevoegen? Die laatste is het lastigst. YAGNI - You Aren’t Gonna Need It - is een principe dat ik ken en respecteer. Maar als elke uitbreiding maar een uur kost, is de drempel om “nog even dit ertoe te voegen” gevaarlijk laag.

Wat het met mij deed

De rode draad van deze week is de veranderende relatie met mijn eigen werk. Code die AI bouwt voelt minder van mij. Dat maakt het makkelijker om weg te gooien - en dat is soms goed. Het maakt het ook makkelijker om te blijven bouwen terwijl je ziek bent - en dat is misschien minder goed.

Ik bouw tools die mijn podcast beoordelen, roast mijn eigen werkwijze, en laat agents documentatie schrijven zodat ik begrijp wat ze voor me gemaakt hebben. Er zit een spanning in: ik wil grip houden op wat ik maak, maar de manier waarop ik dat doe - meer AI inzetten - vergroot misschien juist de afstand.

Het eerlijke antwoord: ik weet nog niet waar de balans ligt. Maar het moment met de vinger boven de delete-toets was verhelderend. Niet omdat ik bijna iets weggooide. Maar omdat het zo weinig pijn deed.