Boris' 9 praktische tips voor Claude Code: de configuratie van een expert blijkt zo "simpel" te zijn. Boris Cherny heeft binnen Anthropic de bijnaam: de vader van Claude Code. Hij is recentelijk erg actief op X, waardoor veel mensen Boris vragen: hoe gebruik jij Claude Code eigenlijk? Hij heeft onlangs 9 praktische tips gedeeld op X. Er zijn niet zoveel tips als je zou denken, elke tip is eenvoudig en rechttoe rechtaan. 【1】Kernidee: er is geen standaard antwoord voor de beste praktijken van Claude Code. Boris begint met te zeggen: > Mijn configuratie is misschien verrassend standaard! Claude Code werkt geweldig direct uit de doos, dus ik pas het persoonlijk niet veel aan. > Mijn configuratie is misschien uit jouw perspectief "origineel". Claude Code werkt prima uit de doos, ik heb het persoonlijk niet veel aangepast. Het is ook begrijpelijk, die beste praktijken, zoals Skills en Plugins, zijn al ingebouwd als functies door de ontwikkelaars van Claude Code. Er is geen enkele juiste manier om Claude Code te gebruiken. Het team heeft het opzettelijk zo ontworpen dat je er vrij mee kunt experimenteren; je kunt het gebruiken, aanpassen of zelfs radicale wijzigingen aanbrengen zoals je wilt. Iedereen binnen het Claude Code-team gebruikt het op een totaal andere manier. Dus het is niet nodig om je in te spannen om naar "beste praktijken" te zoeken; het belangrijkste is dat je een tempo vindt dat bij jou past. 【2】Meerdere agenten taken parallel: tegelijkertijd een dozijn Claude's draaien. Boris' dagelijkse routine ziet er als volgt uit: hij opent 5 Claude Code-instanties in de terminal, met tabbladen genummerd van 1 tot 5, met systeemmeldingen aan, en schakelt over naar de juiste tab wanneer hij invoer nodig heeft. Tegelijkertijd draait hij 5 tot 10 taken in de webversie. De terminal en de webversie kunnen elkaar "overdragen": gebruik het &-symbool om de lokale sessie naar de webversie over te zetten, of gebruik --teleport om heen en weer te schakelen. Elke ochtend en overdag start hij een paar taken via de Claude-app op zijn telefoon en kijkt later terug naar de resultaten. Deze "multithreading" werkstijl is gebaseerd op de logica dat Claude Code goed is in autonoom uitvoeren; veel taken vereisen niet dat je er constant bij bent. Je start een taak, geeft een richting aan, laat het draaien en gaat ondertussen met andere dingen bezig. Zodra het je bevestiging nodig heeft, keer je terug. Dit is een totaal andere aanpak dan de traditionele "mens typt een regel code, AI vult een paar regels aan". Maar dit stelt ook hogere eisen aan de gebruiker; je moet goed zijn in het toewijzen van taken aan agenten en in staat zijn om tussen meerdere taken te schakelen. Voor degenen die gewend zijn aan traditionele ontwikkelingsmodellen met slechts één taak tegelijk, is dit een grote uitdaging. Ik schaam me te zeggen dat, hoewel ik ook vaak gebruik maak van Coding Agent, ik nog steeds niet gewend ben aan het gelijktijdig uitvoeren van te veel taken. Dit jaar moet ik mijn vaardigheden op dit gebied verbeteren. 【3】Modelkeuze: waarom Opus gebruiken in plaats van de snellere Sonnet. Boris zegt dat hij voor al zijn taken Opus 4.5 gebruikt in combinatie met de thinking-modus. Dit is het beste programmeermodel dat hij ooit heeft gebruikt. Sommigen zullen vragen: is Opus niet groter en langzamer dan Sonnet? Boris' antwoord is: hoewel de respons iets trager is, heb je veel minder correcties nodig, en de tool-aanroepen zijn ook nauwkeuriger, waardoor het uiteindelijk sneller is. Dit punt ben ik het eigenlijk altijd mee eens geweest; bij het schrijven van code moet je niet alleen naar snelheid streven, maar ook naar kwaliteit. Als een snel model je drie keer laat corrigeren, is het beter om een trager model te gebruiken dat het in één keer goed doet. Tijd is niet alleen de responstijd van het model, maar ook de kosten van je aandacht en energie. Het enige probleem is dat Opus duurder is. 【4】 is een speciaal configuratiebestand voor Claude Code, dat in de hoofdmap van het project staat. Elke keer dat je Claude Code opstart, leest het automatisch dit bestand en beschouwt de inhoud als "achtergrondkennis". Je kunt het zien als een projecthandleiding die je aan de AI geeft, waarin je de architectuur, normen en aandachtspunten van het project uitlegt. Het team van Boris heeft de aanpak dat de hele Claude Code-repository in één Git wordt gedeeld, en iedereen onderhoudt het samen. Elke week voegt iemand er iets aan toe. De regels zijn eenvoudig: elke keer dat je ziet dat Claude iets verkeerd doet, schrijf je "doe dit niet" erbij, en de volgende keer weet hij het. Wat nog interessanter is, is dat ze deze mechanismen ook gebruiken tijdens codebeoordelingen. Boris tagt @.claude in de PR van een collega, zodat Claude een nieuwe regel toevoegt aan . Dit wordt gerealiseerd via de GitHub Action van Claude Code. Dan Shipper noemt deze aanpak "rente-op-rente engineering": elke correctie wordt een teamasset, waardoor de AI steeds beter begrijpt wat jullie project inhoudt. Als je nog nooit het commando hebt gebruikt, zal Claude automatisch de projectstructuur analyseren en een initiële versie genereren. Vervolgens kun je het gebruiken en aanvullen, en als je iets niet goed vindt, voeg je het toe. 【5】Plan-modus: denk eerst na voordat je aan de slag gaat. Boris zegt dat de meeste van zijn sessies beginnen in de Plan-modus. In Claude Code kun je door twee keer op Shift+Tab te drukken wisselen. In de Plan-modus zal Claude de code niet direct aanpassen, maar eerst een uitvoeringsplan geven. Je kunt heen en weer discussiëren en het plan aanpassen totdat je tevreden bent. Vervolgens schakel je over naar de automatische acceptatiemodus, en Claude kan meestal alles in één keer afmaken. "Een goed plan is echt belangrijk", deze gewoonte brengt eigenlijk de klassieke wijsheid van softwareontwikkeling over naar AI-samenwerking: eerst ontwerpen, dan coderen. Veel mensen die AI gebruiken om code te schrijven, beginnen direct, en als het resultaat verkeerd is, zijn de herwerk kosten hoog. Enkele minuten besteden aan het afstemmen van het plan kan je uren aan herwerk besparen. 【6】Automatisering van repetitief werk: slash-commando's en sub-agenten. Boris heeft een paar handelingen die hij dagelijks tientallen keren gebruikt, en hij heeft ze omgevormd tot slash-commando's. Bijvoorbeeld "/commit-push-pr", waarmee je in één keer een commit, push en PR kunt aanmaken. Slash-commando's zijn in wezen Markdown-bestanden die in de .claude/commands/ directory staan. Je kunt instructies in natuurlijke taal schrijven en ook bash-scripts insluiten om vooraf informatie te verkrijgen, waardoor het aantal keren dat het model moet worden aangeroepen, vermindert. Deze commando's kunnen naar Git worden ingediend en zijn beschikbaar voor het hele team. Naast slash-commando's gebruikt hij ook sub-agenten (agenten zijn onafhankelijke Claude-instanties die speciaal zijn voor bepaalde taken). Bijvoorbeeld, hij heeft een code-simplifier sub-agent die automatisch de code vereenvoudigt nadat de hoofd-Claude zijn werk heeft voltooid; en een verify-app sub-agent die verantwoordelijk is voor end-to-end testen. Het gemeenschappelijke kenmerk van deze twee functies is: ze maken repetitieve taken vast, zodat Claude ze zelf kan aanroepen. Je hoeft niet elke keer opnieuw uit te leggen, en je hoeft niet alle details van de commando's te onthouden. Gebruik de PostToolUse Hook om de door Claude gegenereerde code te formatteren. Claude kan meestal automatisch goed geformatteerde code genereren, en deze Hook behandelt de laatste 10% van de code om te voorkomen dat er formatfouten optreden tijdens het continue integratie (CI) proces. 【7】Veiligheid en integratie: machtigingsconfiguratie en externe tools. Boris gebruikt de "gevaarlijke" optie --dangerously-skip-permissions niet. In plaats daarvan gebruikt hij het /permissions-commando om vooraf goedkeuring te geven voor enkele veelgebruikte veiligheidscommando's, zodat hij niet elke keer een bevestigingsvenster hoeft te zien. Deze configuraties worden opgeslagen in .claude/settings.json en zijn gedeeld binnen het team. Nog krachtiger is de integratie van de MCP-server. MCP staat voor Model Context Protocol, een standaardprotocol dat door Anthropic is geïntroduceerd om AI te verbinden met externe tools. Via MCP kan Claude Code direct: - Berichten zoeken en verzenden via Slack - BigQuery-query's uitvoeren om gegevensvragen te beantwoorden - Foutlogboeken van Sentry ophalen Het team van Boris heeft ook de MCP-configuratie voor Slack ingediend in de repository, zodat iedereen het direct kan gebruiken. Dit betekent dat Claude Code niet alleen een programmeertool is, maar ook een "alles-in-één assistent" die je hele toolchain kan aanroepen. 【8】Langdurige taken verwerken: laat Claude zelf verifiëren. Voor taken die lang duren, heeft Boris een paar strategieën: Ten eerste laat hij Claude automatisch de resultaten verifiëren met een achtergrondagent nadat het klaar is. Je kunt dit in de prompt vragen, of de Stop Hook gebruiken om het zeker te triggeren. > Opmerking: Hooks zijn de "haak"-mechanismen van Claude Code, waarmee je aangepaste logica kunt invoegen op specifieke momenten waarop Claude een actie uitvoert. Je kunt het zien als "triggers": wanneer een bepaald evenement zich voordoet, wordt automatisch je vooraf ingestelde commando of script uitgevoerd. > Stop Hook is wanneer Claude de respons heeft voltooid en zich voorbereidt om de controle terug te geven. > Gerelateerde documentatie: Ten tweede gebruik je de ralph-wiggum plugin, die in wezen een Bash-lus is: stel je een eenvoudige oneindige lus voor (while true), die voortdurend dezelfde taakomschrijving (prompt-bestand) aan de AI geeft, zodat deze keer op keer het werk verbetert totdat het volledig is voltooid. Ten derde gebruik je in een sandbox-omgeving --permission-mode=dontAsk of --dangerously-skip-permissions, zodat Claude niet wordt onderbroken door machtigingsbevestigingen en zelf kan doorgaan. De kerngedachte is: als het een langdurige taak is, laat het dan niet op je wachten. Geef het voldoende autonomie en zelfcorrigerend vermogen. 【9】De belangrijkste tip: geef Claude verificatiemogelijkheden. Boris plaatst deze tip als laatste, omdat hij zegt dat dit misschien de belangrijkste factor is voor het behalen van goede resultaten. Als Claude zijn eigen werk kan verifiëren, kan de uiteindelijke output 2 tot 3 keer beter worden. Hij geeft een voorbeeld: elke wijziging die ze indienen, test Claude zelf met een Chrome-extensie: de browser openen, de UI testen, problemen ontdekken en itereren totdat de functionaliteit normaal is en de ervaring redelijk is. De verificatiemethoden variëren afhankelijk van de situatie. Het kan een bash-opdracht zijn, het kan een test suite zijn, of het kan het testen van een applicatie in een browser of mobiele simulator zijn. De vorm is niet belangrijk; wat belangrijk is, is dat je AI feedback krijgt. Dit principe is eigenlijk heel eenvoudig. Menselijke ingenieurs vertrouwen ook op de cyclus van "code schrijven - testen - resultaten bekijken - aanpassen" om de kwaliteit te waarborgen. AI werkt op dezelfde manier. Als het alleen kan schrijven en niet kan testen, is het alsof je met je ogen dicht werkt; de kwaliteit hangt volledig van geluk af. Boris' advies is: investeer energie in het opzetten van een solide verificatiemechanisme. Dit is de investering met de hoogste opbrengst. 【10】Experts gebruiken hun zwaard zonder technieken. In wuxia-romans gebruiken experts hun zwaard niet met veel flashy technieken; geen technieken zijn beter dan technieken. Boris pronkt niet met complexe aangepaste configuraties of mysterieuze privé-prompten; hij gebruikt gewoon de officiële functies. Het verschil is: hij begrijpt de logica achter deze functies echt en combineert ze tot een efficiënte workflow. Parallel werken is mogelijk omdat Claude autonoom kan uitvoeren; het gebruik van Opus is omdat de algehele efficiëntie hoger is; is het om correcties tot activa te maken; de Plan-modus is om eerst na te denken voordat je aan de slag gaat; slash-commando's en sub-agenten zijn voor het automatiseren van repetitief werk; en het verificatiemechanisme biedt AI een feedbackloop. Als je net begint met het gebruik van Claude Code, hoef je niet te haasten om allerlei geavanceerde configuraties te bestuderen. Begin met de basis: leer parallel werken, leer plannen, leer accumuleren van AI-verificatiemethoden. Als je echt tegen een bottleneck aanloopt, kun je later pas die ingewikkelde dingen gaan uitproberen.

Boris heeft een punt niet genoemd, namelijk de basis CI/code review workflow. Voor hen die gewend zijn aan grote bedrijven, zijn dit misschien vanzelfsprekende zaken die standaard aanwezig zouden moeten zijn. Bijvoorbeeld, wanneer hij een taak met Claude Code heeft voltooid, zal hij niet direct naar de hoofdbranch samenvoegen, maar een PR indienen. Na het indienen van de PR worden automatisch alle lint- en geautomatiseerde tests op de CI-server uitgevoerd. Als de tests falen, kan de PR niet worden samengevoegd. Een PR die alle geautomatiseerde tests heeft doorstaan, moet nog steeds door iemand worden beoordeeld (natuurlijk kan AI helpen, maar er is nog steeds menselijke bevestiging nodig). Als er problemen worden ontdekt tijdens de code review, moet er verder worden aangepast. Veel individuele ontwikkelaars zijn niet gewend om een CI/code review workflow op te zetten, en hebben zelfs geen Git codebeheer gedaan, waardoor ze bij problemen niet kunnen terugdraaien.

【10】 Die dingen die je niet kunt zien Boris heeft een punt niet genoemd, namelijk het basisbeheer van de broncode / CI (continue integratie) / codebeoordeling workflow. Dit zijn dingen die voor hen, die gewend zijn aan grote bedrijven, normaal zijn en als vanzelfsprekend worden beschouwd. Bijvoorbeeld, wanneer hij een taak met Claude Code heeft voltooid, zal hij niet direct naar de hoofdbranch samenvoegen, maar een PR indienen. Na het indienen van de PR worden automatisch alle lint- en geautomatiseerde tests op de CI-server uitgevoerd. Als de tests falen, kan de PR niet worden samengevoegd. Een PR die alle geautomatiseerde tests heeft doorstaan, moet ook door iemand worden beoordeeld (natuurlijk kan AI helpen, maar het moet nog steeds door een persoon worden bevestigd). Als er problemen worden ontdekt tijdens de codebeoordeling, moeten er aanpassingen worden gedaan. Dit zijn ook de basisprincipes die hen in staat stellen om meerdere taken parallel uit te voeren. Als deze basisworkflows niet goed zijn opgezet, is het niet mogelijk om meerdere taken parallel uit te voeren. Voor veel individuele ontwikkelaars is het niet gebruikelijk om een CI/codebeoordelingsworkflow op te zetten, en zelfs het beheer van Git-code wordt vaak niet gedaan, waardoor ze bij problemen niet kunnen terugdraaien.