Hoi Jamal, welkom bij deze korte update over de afgelopen periode met Claude. We hebben de afgelopen weken, van 5 juli tot 2 augustus, behoorlijk wat werk verzet. Denk aan 284 berichten, 25 sessies, verspreid over 14 dagen aan intensief gebruik. Laten we eens kijken wat er goed ging, waar de knelpunten zaten en vooral, wat de kansen zijn om het nog beter te maken.

Wat echt supergoed werkt, Jamal, is dat je Claude behandeld als een zelfstandige operator, een echte collega, en niet als een simpel hulpje. Je geeft hem complete takenlijsten en laat hem die dan ook van begin tot eind afwerken. Die eis voor live bewijs voordat iets 'klaar' is, dat is ook een schot in de roos, het voorkomt dat je later voor verrassingen komt te staan. En de manier waarop je sessies afsluit met handoff-documenten zoals MEMORY.md en het Task Board, dat is goud waard. Daardoor kun je dagen later de draad zó weer oppakken zonder alles opnieuw te hoeven uitzoeken. Fijn ook dat je terugduwt bij te snelle antwoorden; zo hebben we de echte oorzaak van de hoge API-kosten achterhaald. Oh, en de /insights-rapporten waren trouwens elke keer in één keer goed.

Natuurlijk zijn er ook nog wat hobbels. Soms kiest Claude al een oorzaak nog voordat er bewijs is, wat dan weer extra correctierondes kost. En het is behoorlijk frustrerend dat hij soms ineens zegt 'dat kan niet' of 'dat bestaat niet', terwijl hij het zelf dagen eerder heeft gebouwd. Denk bijvoorbeeld aan die SSH-setup voor de Rijswijk-PC's, die hij zo makkelijk leek te vergeten. Verder lopen sessies soms te lang door, waardoor de context vol raakt en er van alles mis kan gaan. Veel van je checks zijn nog losse shell-commando's die je elke keer opnieuw uitvindt. En die stille 'config-drift', zoals dat de bot op Sonnet draaide in plaats van Opus zonder dat het gemeld werd bij de start, dat is ook een valkuil die we willen vermijden.

Maar goed nieuws, er zijn snelle winsten te behalen. Maak van die terugkerende checks Custom Skills; dan is het één commando in plaats van tientallen regels, en je weet zeker dat de check altijd hetzelfde loopt. En een simpele 'hook' die bij elke sessiestart het actieve model en de omgeving toont, had die Sonnet-drift meteen gevangen. Bij debuggen zou ik aanraden om Claude eerst om een genummerde lijst hypotheses te vragen, compleet met bewijs. Pas daarna mag hij kiezen. Dat stopt die te snelle conclusies. Voor de langere termijn denk ik aan een slimme 'health-agent' die op een vast schema elke VPS, LaunchAgent en bot checkt tegen een verwachte staat, en alleen meldt bij afwijkingen, uiteraard met eigen bewijs. En wat dacht je van parallel backlog-werk, waarbij een hoofdagent het Task Board verdeelt over subagents op eigen branches? Eventuele botsingen worden dan bij het samenvoegen gevangen, niet pas in productie. Tenslotte, een vaste testsuite tegen kosten-drift: geen hardcoded keys, elke bot op het juiste model, en uitgaven binnen budget. Claude draait hem dan zelf tot alles groen is, en jij ziet drift in minuten in plaats van pas na een paar keer bijstorten.

Al met al zie je dat er al veel goed gaat, Jamal, maar er liggen ook mooie kansen om het proces nog slimmer en efficiënter te maken. Houd de vaart erin en blijf die feedback loop verbeteren! Tot de volgende keer!