Wie Claude de hele dag gebruikt, vooral via Claude Code, werkt op een ander niveau dan iemand die af en toe een mail laat schrijven. Op dat niveau gaat het niet meer om losse prompts, maar om hoe je je werk inricht zodat het model zo veel mogelijk zelfstandig kan afmaken. Dit deel verzamelt de aanpak van de zwaarste gebruikers, te beginnen bij iemand die het kan weten.
De tips van de maker van Claude Code
Boris Cherny bouwde Claude Code en gebruikt het zelf intensief. Een paar van zijn punten zijn breed bruikbaar, ook buiten het programmeren.
Zijn meest genoemde tip gaat over git worktrees: draai meerdere Claude-sessies tegelijk, elk in een eigen werkmap, zodat ze elkaar niet in de weg zitten. Hij noemt het zijn grootste productiviteitssprong. In gewone taal: je laat drie tot vijf taken parallel lopen in plaats van te wachten tot er één klaar is. Voor wie veel los werk heeft dat niet van elkaar afhangt, is dat een wereld van verschil.
Daarnaast: plan eerst, voer dan pas uit. Beschrijf het probleem volledig voordat je het model vraagt iets te bouwen. Hoe beter je het probleem hebt uitgepraat, hoe beter de uitvoering. Hij gebruikt daar ook spraak voor, hij dicteert de meeste van zijn opdrachten in plaats van ze te typen, omdat je sprekend sneller en vollediger een probleem beschrijft dan tikkend.
En de verificatieloops uit het vorige deel komen ook bij hem terug als een van de grootste hefbomen voor kwaliteit. Geef het model een manier om zijn werk te controleren, dan wordt het beter. Dat geldt voor een beginner en voor een power user evengoed.
Autonome workflows: hooks, loop en batch
Hoe meer je het model zelfstandig laat doen, hoe meer je wilt vastleggen wat er sowieso altijd moet gebeuren. Daar zijn een paar gereedschappen voor.
Hooks zijn stukjes vaste logica die op vaste momenten in een taak draaien, bijvoorbeeld een controle die altijd loopt voordat iets wordt opgeslagen. Het mooie is dat dit geen gok van het model is maar een harde regel: het gebeurt altijd, precies zoals jij het hebt ingesteld. Zo haal je de dingen die geen interpretatie verdienen weg bij het model en leg je ze vast in code.
Met een loop-commando laat je het model een bewerking herhalen over een reeks, en met een batch-aanpak draai je dezelfde stap over veel items tegelijk. Voor terugkerend werk met een vaste vorm scheelt dat enorm. En een handig klein hulpmiddel: met een zijvraag-commando stel je tussendoor even een korte vraag zonder dat je de lopende taak onderbreekt.
Tool use: laat het eerst denken
Sonnet 5 pakt uit zichzelf sneller een tool, een browser, een terminal, een zoekopdracht. Dat is meestal goed, maar bij een lastige taak wil je dat het eerst nadenkt voordat het ergens op klikt.
De manier om dat te sturen: laat het model met een denkstap beginnen voordat het zijn eerste tool aanroept. In de praktijk vraag je het eerst een plan te maken, of de situatie te analyseren, en pas daarna aan de slag te gaan. Een model dat eerst denkt en dan handelt, maakt minder verkeerde tussenstappen dan een model dat meteen begint te klikken. Het ligt in lijn met het bredere principe: plan eerst, voer dan uit.
Sonnet 5 of Opus 4.8?
De vraag die elke zware gebruiker zich stelt. Het korte antwoord: Sonnet 5 voor vrijwel alles, Opus 4.8 voor de uitzonderingen.
Opus 4.8 is het zwaarste model. Het redeneert dieper, maar het is langzamer en duurder. Sonnet 5 is sneller en goedkoper, en haalt op moeilijke taken inmiddels Opus-niveau als je het juiste effort level kiest. Daarmee verschuift de afweging. Vroeger stuurde je je moeilijkste werk vanzelf naar het dure model. Nu kun je veel daarvan op Sonnet 5 met een hoge effort-stand laten doen, voor een fractie van de kosten.
Bewaar Opus voor de echt zware, kritische problemen waar maximale redeneerdiepte het verschil maakt en de hogere prijs en lagere snelheid het waard zijn. Voor het dagelijkse werk, ook het pittige, is Sonnet 5 vanaf nu de standaard.
De nieuwe tokenizer en je context
Sonnet 5 telt tekst anders dan zijn voorganger. Dezelfde tekst kost nu ongeveer dertig procent meer tokens. Dat heeft twee gevolgen die je moet kennen.
Het eerste is kosten. Reken je met token-prijzen, dan valt dezelfde hoeveelheid tekst nu hoger uit dan je gewend was. Hou daar rekening mee in je begroting en vergelijk niet één op één met de oude getallen.
Het tweede is ruimte. Daar staat een groot voordeel tegenover: Sonnet 5 heeft een contextvenster van een miljoen tokens. Je kunt een heel document of een complete codebase in één keer meegeven. Ook al kost dezelfde tekst meer tokens, het venster is zo ruim dat je in de praktijk veel minder vaak hoeft op te knippen. Voor wie met grote documenten werkt, weegt die ruimte ruimschoots op tegen de hogere telling.
De keerzijde van zo diep erin gaan
Hoe meer je hierop bouwt, hoe meer je eraan vastzit. Worktrees, hooks, een CLAUDE.md die jouw manier van werken kent: dat is comfortabel, maar het is ook een workflow die zich vastlegt rond één model van één aanbieder. Overstappen wordt duurder naarmate je dieper gaat. Goed om te weten, niet om bang voor te zijn.
Twee dingen die ik zelf bijhoud. Transparantie: als ik iets grotendeels met Claude maak, zeg ik dat erbij. Deze reeks bijvoorbeeld is met Claude geschreven en daarna door mij nagelopen. En de vraag waar je werk draait: voor het meeste is de cloud prima, maar zodra het om gevoelige of vertrouwelijke gegevens gaat, weeg je af of dat wel naar een externe dienst moet of dat een lokale aanpak beter past. Dat hoort bij het vak, niet als bijzaak maar als onderdeel van de keuze.
Promptstructuren voor agentic werk
Tot slot, de rode draad onder al het bovenstaande. Als je het model zelfstandig laat werken, verschuift je rol van iemand die elke stap aanstuurt naar iemand die het kader zet. Dat kader heeft een vaste vorm die telkens terugkomt.
Je beschrijft het doel volledig, je geeft de context die meereist via een vast bestand, je laat het model eerst denken en plannen voordat het handelt, en je bouwt een manier in waarop het zijn eigen werk kan controleren. Daarbinnen geef je het de ruimte om de taak af te maken. Dat is de kern van werken met een agentisch model: niet micromanagen, wel een goed kader en een goede meetlat geven.
Daarmee is de reeks rond. Van de eerste prompt tot de autonome workflow draait het steeds om hetzelfde: wees duidelijk over wat je wilt, geef de context die nodig is, en geef het model een manier om te checken of het klopt. De rest is oefening.
Vragen, of benieuwd hoe ik dit zelf inzet? Lees mee op sparkone.nl of mail me op jeroen@sparkone.nl.