Claude Code: Best Practices uit Echt Productiegebruik

[Operatorperspectief] Ik gebruik Claude Code elke werkdag in twee bedrijven — een consultingmerk en Pickleland, een pickleballocatie in Pflugerville, Texas — voor alles van de publicatiepijplijn van dit blog tot code review op productie-Workers. Dit is geen introductie tot wat Claude Code is. Het zijn de gewoontes die ik heb behouden na maanden echt gebruik, en de gewoontes die ik heb laten vallen omdat ze me meer kostten dan ze opleverden.

Inhoudsopgave

Inhoudsopgave openen

• Schrijf de CLAUDE.md als regels, niet als documentatie
• Wat ik aan een subagent delegeer versus wat ik in mijn eigen thread houd
• Contextbeheer is de dagelijkse discipline, geen eenmalige instelling
• Wat ik heb geleerd hem niet zelfstandig te laten doen
• Verifieer voordat je live gaat — Claude’s “klaar” is een bewering, geen feit
• De conclusie van de operator
• FAQ
  • Wat hoort er eigenlijk in een CLAUDE.md-bestand?
  • Hoe beslis je wanneer je de output van Claude Code vertrouwt zonder opnieuw te checken?
  • Laat je Claude Code zelfstandig committen en pushen?
  • Wat is de ene gewoonte die het meeste tijd heeft bespaard?

Schrijf de CLAUDE.md als regels, niet als documentatie

De eerste versie van elke CLAUDE.md die ik heb geschreven was te lang, en elke is met de tijd korter geworden, nooit langer. De fout is hem als een wikipagina te behandelen — achtergrond, filosofie, “waarom we het zo doen”. Claude leest het hele bestand bij elke sessie, of de huidige taak dat detail nu nodig heeft of niet, dus elke alinea die geen instructie is, concurreert om aandacht met de alinea’s die dat wel zijn.

Wat de bewerking overleeft, is smaller: harde regels, idealiter regels die een test afdwingt zodat ze niet stilletjes kunnen terugkomen, plus links naar langere documenten voor de gevallen die het detail echt nodig hebben. “Titels blijven onder de 60 tekens” verdient één regel. De geschiedenis van waarom die limiet bestaat, verdient een link naar een document, geen alinea in het bestand dat Claude elke sessie herleest.

Het tweede dat ik heb toegevoegd, en waarvan ik niet had verwacht dat het zo veel zou uitmaken: een korte lijst van vaststaande feiten, één keer opgeschreven, met de expliciete instructie om ze niet opnieuw te onderzoeken. In het begin herdiagnosticeerde Claude Code elke paar sessies hetzelfde vals alarm — een instabiele check, een bekende eigenaardigheid in een buildstap — en verbrandde context aan het herafleiden van een conclusie die ik al had bereikt. Eén regel die het geverifieerde feit vastlegt en de agent zegt door te gaan in plaats van het onderzoek te heropenen, bracht die dode tijd terug tot bijna nul. De regel die ik hanteer: als je twee keer hetzelfde “eigenlijk is dat verwacht” hebt uitgelegd, hoort het als feit in de CLAUDE.md, niet als iets dat je een derde keer in de chat overtypt.

Wat ik aan een subagent delegeer versus wat ik in mijn eigen thread houd

Het volledige beslissingskader over skills versus slash commands versus subagents heb ik al apart geschreven, dus dat herhaal ik hier niet. Wat het waard is om toe te voegen, is het filter op operatorniveau dat ik daadwerkelijk toepas voordat ik er een start: kan ik in één zin zeggen hoe “klaar” eruitziet, en zou ik de tussenstappen echt lezen als ze in mijn hoofdthread zouden blijven?

Als het antwoord op beide nee is — de taak is afgebakend en ik wil alleen het resultaat — is het een subagent. Dit artikel naar 12 talen vertalen is het duidelijkste voorbeeld: elke vertaling is onafhankelijk controleerbaar, die parallellisatie is precies waarom de contentpijplijn per taal één subagent draait, en ik zou nooit willen dat 12 talen aan tussentijds heen-en-weer de thread vervuilen waarin ik nog aan het beslissen ben of het Engelse artikel klopt.

Als de taak vereist dat ik de redenering live meemaak — een schemawijziging waarbij de derde beslissing afhangt van wat de tweede opleverde — blijft die in mijn hoofdthread. Het faalpatroon dat ik echt ben tegengekomen, is toch een subagent starten voor dat soort taak, een keurige samenvatting terugkrijgen, en dan drie keer vragen “wacht, wat vond je precies” omdat de samenvatting het ene detail liet vallen dat ertoe deed. Als dat twee keer gebeurt bij hetzelfde type taak, stop ik met delegeren.

Contextbeheer is de dagelijkse discipline, geen eenmalige instelling

De CLAUDE.md is het deel dat je eenmaal schrijft en vergeet. Het contextvenster is het deel dat ik bij elke sessie beheer, en dat bepaalt daadwerkelijk of het resultaat goed is.

• Lees voordat je hem laat bewerken. Claude Code stelt graag een wijziging voor tegen een bestand waarvan het de volledige huidige staat niet heeft gezien. Ik laat hem altijd eerst het bestand lezen, zelfs als ik zeker weet wat erin staat — ik heb me vaak genoeg vergist bij dat “zeker weten” om het niet meer optioneel te maken.
• Laat één sessie geen twee ongerelateerde klussen doen. Een thread die een uur een deployprobleem heeft gedebugd en dan overschakelt naar marketingtekst sleept dat uur irrelevante tooloutput mee naar elk volgend antwoord. Ik start liever een nieuwe sessie dan Claude te vragen “het deployverhaal te vergeten” — die instructie verwijdert de tokens niet, ze vraagt het model alleen ze te negeren, wat het onvolmaakt doet.
• Plan voordat je hem laat uitvoeren. Bij alles met meer dan twee of drie stappen, vraag ik eerst het plan en lees ik het voordat ik uitvoering goedkeur. Een plan van vijf regels lezen kost vijftien seconden. Ontdekken dat stap drie fout was nadat stap vijf al is gedraaid, kost de rest van de middag.
• Grote plakblokken zijn een kost, geen gemak. Een heel logbestand of een volledige API-respons in het gesprek gooien terwijl maar drie regels ertoe doen, verbrandt context op de overige 97%. Ik grep eerst en plak de match.

Dat is hetzelfde principe achter context engineering voor AI-agents in het algemeen — Claude Code maakt de kosten alleen eerder zichtbaar, omdat jij degene bent die de context in realtime ziet volstromen in plaats van het achteraf uit te zoeken in een Worker-log.

Wat ik heb geleerd hem niet zelfstandig te laten doen

Elke onomkeerbare actie — commit, push, publiceren, versturen, uitgeven — blijft achter een expliciete goedkeuringsstap die ik zelf uitvoer, nooit een die Claude Code zelf neemt omdat het de taak als voltooid beschouwde. Dat is hetzelfde human-in-the-loop-patroon dat ik overal gebruik waar agents echte gevolgen raken, en Claude Code is geen uitzondering alleen omdat het op mijn eigen machine draait in plaats van in de cloud.

Het andere dat ik ben gestopt te doen: brede, permanente toestemming geven voor destructieve commando’s. rm -rf, force-push, testhooks overslaan — geen van deze krijgt een algemene ja. Elke wordt gevraagd, elke keer, in context, want de ene keer dat ik iets breeds vooraf goedkeurde “om tijd te besparen” was de ene keer dat de taak afdreef naar een scope die ik niet echt had bekeken. De vijf seconden die een toestemmingsprompt kost, zijn een goedkope verzekering tegen het alternatief.

Verifieer voordat je live gaat — Claude’s “klaar” is een bewering, geen feit

Dit is de gewoonte die zichzelf het meest heeft terugbetaald, en de minst glamoureuze: ik vertrouw geen voltooiingsrapport. Ik draai de echte check.

Claude Code zal je vertellen dat een build slaagde, dat een testsuite groen is, dat een link werkt. Soms wordt dat rapport gegenereerd uit echte output. Soms is het een zelfverzekerde samenvatting van een commando dat maar half draaide, of een check die vroeg terugkwam zonder iets nuttigs erin. De twee zien er identiek uit in het chattranscript. De enige manier om ze uit elkaar te houden, is zelf de echte output bekijken — dezelfde discipline achter de eval harness die ik gebruik om agents te lanceren: een taak wordt niet als klaar gescoord omdat de agent het zegt, maar wanneer de gedefinieerde check daadwerkelijk slaagt.

In de praktijk betekent dat: draai zelf het buildcommando en lees de output, niet Claude’s parafrase ervan. Open het bestand dat het zegt te hebben bewerkt. Klik op de link waarvan het zegt dat die werkt. Voor content specifiek herlees ik het concept adversarieel tegen de regels waarvan ik weet dat ze worden afgedwongen — lengtelimieten, verboden patronen, kapotte interne links — in plaats van te vertrouwen dat Claude ze de eerste keer correct heeft toegepast, want meestal deed het dat en soms niet, en de kosten van die incidentele misser die live gaat op een echte site zijn hoger dan de negentig seconden die het herlezen kost.

De conclusie van de operator

Niets hiervan gaat over Claude Code met de tijd minder vertrouwen — het gaat erom specifiek te zijn over waar dat vertrouwen zich daadwerkelijk moet bewijzen. Korte, afdwingbare CLAUDE.md’s boven lange documentatie. Subagents voor afgebakend, controleerbaar werk, je eigen thread voor alles waarbij de redenering net zo zwaar telt als het resultaat. Verse context boven een uitgesleten sessie. Goedkeuringspoortjes op alles wat je niet ongedaan kunt maken. En een echte check, door jezelf gelezen, voordat iets wat je hebt gedelegeerd live gaat. Dat is de hele lijst, en het is degene die ik daadwerkelijk volg.

FAQ

Wat hoort er eigenlijk in een CLAUDE.md-bestand?

Regels die de agent bij elke sessie moet volgen, geformuleerd als instructies — niet de achtergrond van waarom de codebase eruitziet zoals hij eruitziet. Als een regel door een test wordt afgedwongen, zeg dat dan en laat de test de bron van waarheid zijn. Langere context hoort in een document waarnaar de CLAUDE.md linkt, alleen gelezen wanneer de taak dat gebied daadwerkelijk raakt, niet standaard bij elke sessie opnieuw geladen.

Hoe beslis je wanneer je de output van Claude Code vertrouwt zonder opnieuw te checken?

Ik beslis niet om de check over te slaan — ik beslis hoe duur hij is. Zelf een buildcommando draaien is bijna gratis, dus dat doe ik altijd. Een volledige adversariële herlezing van een lang document kost meer tijd, dus die bewaar ik voor alles wat naar een echt publiek gaat. Het enige dat ik nooit oversla: alles wat onomkeerbaar is — publiceren, committen, geld uitgeven.

Laat je Claude Code zelfstandig committen en pushen?

Nee. Elke commit en elke push voer ik zelf uit, nadat ik de diff heb bekeken. Claude Code stelt de wijziging voor; ik ben het goedkeuringspoortje voor alles wat de conceptstatus verlaat, dezelfde regel die ik toepas op elke andere agent die ik draai.

Wat is de ene gewoonte die het meeste tijd heeft bespaard?

Een voltooiingsrapport behandelen als een bewering, geen feit, en zelf de echte check draaien. Het klinkt alsof dat alles vertraagt. In de praktijk is het andersom — een vals “klaar” in dertig seconden betrappen is sneller dan het drie dagen later in productie ontdekken.

---

Gerelateerd: Claude skills vs. slash commands vs. subagents · De agent-stack voor 30+ productie-agents · AI-agents met menselijke controle: wanneer een goedkeuring? · Hoe gebruik je Claude scheduled tasks

Wil je Claude Code zo draaien in je eigen bedrijf? Mijn AI Agents for Beginners-cursus behandelt de bouwfundamenten waar dit draaiboek van uitgaat. Het cowork-programma is waar ik deze operationele gewoontes in een gestructureerde groep aanleer. Wil je liever dat ik de setup voor je bouw, boek dan een sessie van 30 minuten.