Boris' 9 Claude Code-praktiske tips: Det viser seg at konfigurasjonen av masteren er så "enkel" Boris Cherny har et kallenavn innen Anthropic: Claude Codes far. Han har vært aktiv på X i det siste, så mange spør Boris: Hvordan bruker du egentlig Claude Code selv? Han delte nettopp 9 praktiske tips på X. Det er ikke så mange triks som du tror, og hvert eneste er uprætiøst. [1] Kjernefilosofi: Det finnes ikke noe standardsvar på Claude Codes beste praksis Boris åpnet med å si: > Oppsettet mitt er kanskje overraskende vanilje! Claude Code fungerer utmerket rett ut av boksen, så jeg tilpasser det personlig ikke så mye. > Min konfigurasjon kan være «original» som du forventer. Claude Code fungerer utmerket rett ut av esken, og jeg gjorde personlig ikke mye tilpasning. Det er forståelig at disse beste praksisene, som ferdigheter og plugins, lenge har vært innebygd i funksjoner som Claude Code-utviklere. Det finnes ikke én riktig måte å bruke Claude Code på. Teamet designet det bevisst for å kunne kastes casual, og du kan bruke det akkurat som du vil, hvordan du vil endre det, og hvordan du vil endre det. Alle i Claude Code-teamet bruker det helt forskjellig. Så det er ikke nødvendig å slite med å finne "beste praksis", det viktigste er å tilpasse seg din egen rytme. [2] Multi-agentoppgaver parallelt: Åpne mer enn et dusin Claude samtidig Boris sin daglige rutine er slik: åpne 5 Claude Code-instanser i terminalen, fane nummer 1 til 5, slå på systemvarsler, og hopp over hvilken som må tastes inn. Samtidig kjører han også 5 til 10 oppgaver på nettversjonen. Terminaler og nettsider kan "overlevere" hverandre: bruk &-symbolet for å overføre den lokale sesjonen til nettsiden, eller bruk --teleport for å bytte frem og tilbake på begge sider. Han starter flere oppgaver fra Claude-appen på telefonen hver morgen og i løpet av dagen, og kommer tilbake senere for å se resultatene. Kjernen i denne «multitrådede» måten å jobbe på er at Claude Code er god på autonomi, og mange oppgaver krever ikke at du følger med. Du starter oppgaven, gir den en retning, lar den gå, og gjør noe annet selv. Kutt ned når det trengs bekreftelse. Dette er helt annerledes enn den tradisjonelle «mennesket som skriver en kodelinje, AI-en lager noen linjer». Dette krever imidlertid også høyere brukerkrav, og du må være flink til å tildele oppgaver til agenter og kunne bytte mellom flere oppgaver når som helst. Dette er en stor utfordring for tradisjonelle utviklingsmodeller som er vant til å utvikle på egenhånd og bare har én oppgave om gangen. Jeg skammer meg over å si at selv om jeg også bruker Coding Agent regelmessig, er jeg fortsatt ikke vant til å kjøre for mange oppgaver samtidig, så jeg vil styrke praksisen min på dette området i år. [3] Modellvalg: Hvorfor bruke Opus i stedet for den raskere Sonetten Boris sier at han bruker Opus 4.5 til alle sine oppgaver med tenkemodus. Dette er den beste programmeringsmodellen han noen gang har brukt. Noen vil spørre: Er ikke Opus større og tregere enn Sonnet? Boris' svar er at selv om enkeltresponsen er litt tregere, trenger du å korrigere den mye mindre, verktøykallene er mer presise, og sluttresultatet er raskere. Faktisk har jeg alltid vært enig i at det ikke kan være raskt å skrive kode, men må være av høy kvalitet; hvis en rask modell krever at du korrigerer den frem og tilbake tre ganger, er det bedre å bruke en treg modell til å gjøre det samtidig. Tid handler ikke bare om modellens responstid, det handler også om oppmerksomhet og innsatskostnader. Det eneste problemet er at Opus koster mer. 【4】 er en spesiell konfigurasjonsfil for Claude Code, plassert i prosjektroten. Hver gang du starter Claude Code, leser den automatisk filen og behandler innholdet som «bakgrunnskunnskap». Du kan forstå det som: Dette er prosjektspesifikasjonen du skrev til AI, og forteller den strukturen, spesifikasjonene og forholdsreglene for prosjektet. Boris-teamets tilnærming er at hele Claude Code-repositoriet vedlikeholdes i én enkelt Git. Hver uke legger folk til ting i Rigano. Regelen er enkel: hver gang du ser Claude gjøre noe galt, skriv «ikke gjør dette» i det, og neste gang vil den vite det. Det som er enda mer interessant, er at de også bruker denne mekanismen når de gjennomgår kode. Boris vil @.claude i kollegaens PR og be Claude legge til en ny regel i . Dette oppnås gjennom Claude Codes GitHub Action. Dan Shipper kaller dette et «rentes rente-prosjekt»: hver feilkorrigering blir en teamressurs, som gjør at AI-en kan forstå prosjektet ditt mer og mer. Hvis du ikke har brukt kommandoen ennå, vil Claude automatisk analysere prosjektstrukturen og generere en initial versjon. Så legger du til etter hvert som du bruker, og legger til hva som er galt når du ser det. [5] Planmodus: tenk klart før du gjør det Boris sier at han starter de fleste øktene sine i Plan-modus. Dobbeltklikk på Shift+Tab i Claude Code for å bytte. I Plan-modus endrer ikke Claude koden direkte, men gir deg først en utførelsesplan. Du kan diskutere og revidere planen frem og tilbake til du er fornøyd. Deretter bytter du til auto-aksept-modus, som Claude vanligvis gjør på én gang. «God planlegging er veldig viktig», denne vanen overfører faktisk den klassiske visdommen fra programvareutvikling til AI-samarbeid: design først og deretter kode. Problemet med at mange bruker AI til å skrive kode er å starte den direkte, og resultatet er at kostnaden for omarbeiding blir høy på grunn av feil retning. Å bruke noen minutter på å justere planen sparer timer med omarbeiding. [6] Automatiser repeterende arbeid: slash-kommandoer og underagenter Boris hadde flere operasjoner han måtte gjøre dusinvis av ganger om dagen, og han gjorde dem om til slash-kommandoer. For eksempel fullfører "/commit-push-pr" innsending, push og PR-opprettelse med ett klikk. Slash-kommandoer er i bunn og grunn Markdown-filer som plasseres under .claude/commands/-mappen. Du kan skrive kommandoer i naturlig språk, og du kan også legge inn bash-skript for å få informasjon på forhånd, noe som reduserer antall kall frem og tilbake i modellen. Disse kommandoene kan sendes inn til Git og deles av hele teamet. I tillegg til slash-kommandoen bruker han også en underagent (en agent er en separat instans av Claude som spesialiserer seg på visse typer arbeid. For eksempel har han en kode-forenklende underagent som automatisk forenkler koden etter at hoved-Claude har fullført sitt arbeid. Det finnes også en verify-app underagent som har ansvar for ende-til-ende-testing. Det disse to egenskapene har til felles, er at du gjentatte ganger befester det du gjør og lar Claude bestemme det selv. Du trenger ikke å gjenta forklaringen hver gang eller huske detaljene i kommandoen. Bruk PostToolUse Hook for å formatere koden generert av Claude. Claude genererer vanligvis automatisk godt formatert kode, og denne kroken håndterer de siste 10 % av koden for å unngå feilformatering senere i prosessen med kontinuerlig integrasjon (CI). [7] Sikkerhet og integrasjon: tillatelseskonfigurasjon og eksterne verktøy Boris bruker ikke --dangerously-skip-permissions-alternativet. I stedet forhåndsgodkjenner han noen ofte brukte sikkerhetskommandoer med /permissions-kommandoen for å unngå at bekreftelsesboksen åpnes hver gang. Disse konfigurasjonene lagres i .claude/settings.json og deles av teamet. Enda kraftigere er MCP-serverintegrasjonen. MCP, en forkortelse for Model Context Protocol, er en standardprotokoll lansert av Anthropic som lar AI koble seg til eksterne verktøy. Med MCP kan Claude Code direkte: - Søk og send Slack-meldinger - Kjør BigQuery-spørringer for å svare på dataspørsmål - Hent feilloggen fra Sentry Boris-teamet sendte også inn Slacks MCP-konfigurasjon til repositoriet, og alle brukte den rett ut av esken. Dette betyr at Claude Code ikke bare er et programmeringsverktøy, men en «alt-i-ett-assistent» som kan hente opp hele verktøykjeden din. [8] Lang oppgavebehandling: La Claude verifisere det selv For langvarige oppdrag har Boris flere strategier: Den første er å la Claude automatisk bruke bakgrunnsagenten for å verifisere resultatene etter fullføring. Du kan be om det i prompten, eller du kan bruke en Stop Hook for å utløse det mer deterministisk. > Merknad: Hooks er Claude Codes "hook"-mekanisme som lar deg sette inn egendefinert logikk på bestemte øyeblikk når Claude utfører en handling. Du kan tenke på det som en "trigger": når en hendelse skjer, utfør automatisk din forhåndsinnstilte kommando eller skript. > Stop Hook er når Claude svarer og er klar til å overlate kontrollen. > Relatert dokumentasjon: Den andre er å bruke ralph-wiggum-pluginen, som i bunn og grunn er en Bash-løkke: tenk deg en enkel død sløyfe (selv om den er sann) som fortsetter å mate den samme oppgavesetningen (prompt-filen) til AI-agenten, slik at den forbedrer arbeidet sitt om og om igjen til den er helt ferdig. Den tredje er å bruke --permission-mode=dontAsk eller --dangerously-skip-permissions i sandkassemiljøet, slik at Claude ikke blir avbrutt av tillatelsesbekreftelse og kjører til slutten alene. Kjerneideen er: siden det er en lang oppgave, ikke la det vente på deg. Gi den nok autonomi og evne til selvkorreksjon. [9] Den viktigste: gi Claude valideringsmuligheter Boris legger denne til slutt, og sier at dette sannsynligvis er den viktigste faktoren for å oppnå et godt resultat. Hvis Claude kan validere arbeidet sitt, kan sluttresultatet økes med 2 til 3 ganger. Han ga et eksempel: for hver endring de sender inn til, tester Claude seg selv med Chrome-utvidelser: åpner nettleseren, tester brukergrensesnittet, og itererer når det finner et problem til det fungerer som det skal og opplevelsen er rimelig. Verifiseringsmetodene varierer avhengig av scenariet. Det kan være å kjøre en bash-kommando, kjøre en testsuite, eller teste en app i en nettleser eller mobilemulator. Formen er ikke viktig, men det viktige er: la AI-en ha en tilbakemeldingssløyfe. Denne sannheten er faktisk veldig enkel. Menneskelige ingeniører er også avhengige av syklusen «å skrive kode, teste – se resultater – modifisere» for å sikre kvalitet. Det samme gjelder for AI. Hvis det bare kan skrives og ikke måles, er det som å gjøre ting med lukkede øyne, og kvaliteten avhenger av flaks. Boris' forslag er å investere i å styrke verifikasjonsmekanismen. Dette er den høyeste avkastningen på investeringen. [10] Mestere bruker sverd for å vinne uten trekk I kampsportromaner har mestere ikke så mange funksjoner med sverd, og det finnes ingen trekk å vinne. Boris viser ikke frem komplekse tilpassede konfigurasjoner, har ikke mystiske private prompts, og bruker offisielle funksjoner. Forskjellen er at han virkelig forstår logikken bak disse funksjonene og deretter kombinerer dem til en effektiv arbeidsflyt. Parallelt arbeid utføres fordi Claude kan utføre autonomt; Opus brukes på grunn av høyere total effektivitet; Det er å gjøre feilretting om til ressurser; Plan-modusen er å tenke klart før man gjør det; slash-kommandoer og under-agenter er automatisert repeterende arbeid; Verifiseringsmekanismen er for å gi AI-tilbakemelding en lukket sløyfe. Hvis du akkurat har begynt med Claude Code, er det ingen grunn til å skynde seg med avanserte konfigurasjoner. Bruk det grunnleggende godt først: lær å jobbe parallelt, lær å planlegge, og lær deg å samle AI-verifiseringsmetoder. Når du virkelig møter en flaskehals, er det ikke for sent å kaste de blomstene.

En ting Boris ikke nevnte, er den grunnleggende CI/kodegjennomgangsprosessen, som kanskje er vanlig for de store selskapene og som bør være der som standard For eksempel, når han fullfører en oppgave med Claude Code, sier han ikke at man skal flette direkte til hovedgrenen, men sender inn en PR. Etter innsending av en PR vil alle lint- og automatiserte tester automatisk kjøres på CI-serveren, og hvis testen feiler, kan ikke PR-en slås sammen. En PR består alle automatiserte tester og trenger noen til å gjøre en kodegjennomgang (selvfølgelig er AI-assistanse mulig, men det må fortsatt bekreftes), og hvis kodegjennomgangen finner problemer, må den revideres. For mange individuelle utviklere er de ikke vant til å bygge en CI/kodegjennomgangsarbeidsflyt, og de driver ikke engang med Git-kodeadministrasjon, så de kan ikke rulle tilbake hvis noe går galt.

[10] De tingene du ikke kan se En ting Boris ikke nevnte, er den grunnleggende arbeidsflyten for kildekontroll/CI/kodegjennomgang, som kanskje er vanlig for deres store selskaper og bør være der som standard For eksempel, når han fullfører en oppgave med Claude Code, sier han ikke at man skal flette direkte til hovedgrenen, men sender inn en PR. Etter innsending av en PR vil alle lint- og automatiserte tester automatisk kjøres på CI-serveren, og hvis testen feiler, kan ikke PR-en slås sammen. En PR består alle automatiserte tester og trenger noen til å gjøre en kodegjennomgang (selvfølgelig er AI-assistanse mulig, men det må fortsatt bekreftes), og hvis kodegjennomgangen finner problemer, må den revideres. Disse er også grunnlaget for deres evne til å multitaske parallelt, og uten disse grunnleggende arbeidsflytene kan de ikke multitaske parallelt. For mange individuelle utviklere er de ikke vant til å bygge en CI/kodegjennomgangsarbeidsflyt, og de driver ikke engang med Git-kodeadministrasjon, så de kan ikke rulle tilbake hvis noe går galt.