Boris 9 Claude Code-praktiska tips: Det visar sig att konfigurationen av mastern är så "enkel" Boris Cherny har ett smeknamn inom Anthropic: Claude Codes far. Han har varit aktiv på X på sistone, så många frågar Boris: Hur använder du exakt Claude Code själv? Han delade bara 9 praktiska tips på X. Det finns inte så många knep som du tror, och varje är okonstlat. [1] Kärnfilosofi: Det finns inget standardsvar på Claude Codes bästa praxis Boris inledde med att säga: > Min setup kan vara förvånansvärt vanilj! Claude Code fungerar utmärkt direkt ur lådan, så jag anpassar det personligen inte så mycket. > Min konfiguration kan vara "original" som du förväntar dig. Claude Code fungerar utmärkt direkt ur lådan, och jag gjorde personligen inte så mycket anpassningar. Det är förståeligt att dessa bästa praxis, såsom färdigheter och plugins, länge har varit inbyggda i funktioner som Claude Code-utvecklare. Det finns inget enda rätt sätt att använda Claude Code. Teamet designade medvetet den för att kastas avslappnat, och du kan använda den hur du vill, hur du vill ändra den och hur du vill ändra den. Alla inom Claude Code-teamet använder det helt olika. Så det finns ingen anledning att kämpa för att hitta "bästa metoder", det viktigaste är att anpassa din egen rytm. [2] Multiagentuppgifter parallellt: Öppna mer än ett dussin Claudes samtidigt Boris dagliga rutin är så här: öppna 5 Claude Code-instanser i terminalen, flika nummer 1 till 5, slå på systemnotiser och hoppa över vilken som behöver matas in. Samtidigt kör han också 5 till 10 uppgifter på webbversionen. Terminaler och webbsidor kan "lämna över" varandra: använd &-symbolen för att överföra den lokala sessionen till webbsidan, eller använd --teleport för att växla fram och tillbaka på båda sidor. Han startar flera uppgifter från Claude-appen på sin telefon varje morgon och under dagen, och kommer tillbaka senare för att se resultaten. Kärnlogiken i detta "multitrådade" arbetssätt är att Claude Code är bra på autonomi, och många uppgifter kräver inte att du håller koll på det. Du börjar uppgiften, ger den en riktning, låter den gå och gör något annat själv. Dra ner när det behöver din bekräftelse. Detta är helt annorlunda än den traditionella "människan som skriver en kodrad, AI som hittar på några rader". Detta kräver dock också högre användarkrav, och du måste vara bra på att tilldela uppgifter till agenter och kunna växla mellan flera uppgifter när som helst. Detta är en stor utmaning för traditionella utvecklingsmodeller som är vana vid att utveckla själva och bara har en uppgift åt gången. Jag skäms att säga att även om jag också använder Coding Agent regelbundet, är jag fortfarande inte van vid att köra för många uppgifter samtidigt, så jag kommer att stärka min praktik inom detta område i år. [3] Modellval: Varför använda Opus istället för den snabbare Sonetten Boris säger att han använder Opus 4.5 för alla sina uppgifter med tänkande läge. Detta är den bästa programmeringsmodellen han någonsin använt. Vissa kommer att fråga: Är inte Opus större och långsammare än Sonnet? Boris svar är att även om det enskilda svaret är lite långsammare, behöver du korrigera det mycket mindre, verktygsanropen är mer precisa och slutresultatet är snabbare. Faktum är att jag alltid har hållit med om att kodskrivning inte kan vara snabb, utan måste vara av hög kvalitet; om en snabb modell kräver att du korrigerar den fram och tillbaka tre gånger, är det bättre att använda en långsam modell för att göra det samtidigt. Tid handlar inte bara om modellens responstid, utan också om din uppmärksamhet och dina ansträngningskostnader. Det enda problemet är att Opus kostar mer. 【4】 är en speciell konfigurationsfil av Claude Code, placerad i projektets rot. Varje gång du startar Claude Code läser den automatiskt filen och behandlar dess innehåll som "bakgrundskunskap". Du kan förstå det som: Detta är projektbeskrivningen du skrev till AI, där du berättar om projektets struktur, specifikationer och försiktighetsåtgärder. Boris-teamets tillvägagångssätt är att hela Claude Code-arkivet underhålls i en enda Git. Varje vecka lägger folk till saker i Rigano. Regeln är enkel: varje gång du ser Claude göra något fel, skriv "gör inte detta" i den, och nästa gång kommer den att veta det. Det som är ännu mer intressant är att de också använder denna mekanism när de granskar kod. Boris kommer att @.claude i sin kollegas PR och be Claude lägga till en ny regel i . Detta uppnås genom Claude Codes GitHub Action. Dan Shipper kallar detta ett "ränte-på-ränte-projekt": varje felkorrigering blir en team-tillgång, vilket gör att AI:n kan förstå ditt projekt mer och mer. Om du inte har använt kommandot än, kommer Claude automatiskt att analysera projektstrukturen och generera en initial version. Sedan lägger du till när du använder, och tillägger vad som är fel när du ser det. [5] Planläge: tänk klart innan du gör det Boris säger att han börjar de flesta av sina sessioner i Plan-läge. Dubbelklicka på Shift+Tab i Claude Code för att byta. I Plan-läge ändrar Claude inte koden direkt, utan ger dig först en exekveringsplan. Du kan diskutera och revidera din plan fram och tillbaka tills du är nöjd. Byt sedan till auto-accept-läge, vilket Claude vanligtvis gör på en gång. "God planering är verkligen viktigt", denna vana överför faktiskt den klassiska visdomen från mjukvaruutveckling till AI-samarbete: design först och sedan kodning. Problemet med att många använder AI för att skriva kod är att starta den direkt, och resultatet är att kostnaden för omarbetning blir hög på grund av fel riktning. Att lägga några minuter på att justera din plan sparar timmar av omarbete. [6] Automatisera repetitivt arbete: slash-kommandon och underagenter Boris hade flera operationer som han var tvungen att göra dussintals gånger om dagen, och han gjorde dem till slash-kommandon. Till exempel slutför "/commit-push-pr" submission, push och PR-skapande med ett klick. Slash-kommandon är i princip Markdown-filer som placeras under katalogen .claude/commands/. Du kan skriva kommandon i naturligt språk, och du kan också bädda in bash-skript för att få viss information i förväg, vilket minskar antalet anrop fram och tillbaka i modellen. Dessa kommandon kan skickas till Git och delas av hela teamet. Utöver slash-kommandot använder han också en subagent (en agent är en separat instans av Claude som specialiserar sig på vissa typer av arbete. Till exempel har han en kodförenklande subagent som automatiskt förenklar koden efter att huvud-Claude slutfört sitt arbete. Det finns också en verifieringsapp-subagent som ansvarar för end-to-end-testning. Vad dessa två egenskaper har gemensamt är att du upprepar vad du gör och låter Claude bestämma det själv. Du behöver inte upprepa förklaringen varje gång eller komma ihåg detaljerna i kommandot. Använd PostToolUse Hook för att formatera koden som genereras av Claude. Claude genererar vanligtvis automatiskt välformaterad kod, och denna hook hanterar de sista 10 % av koden för att undvika felformatering senare i den kontinuerliga integrationsprocessen (CI). [7] Säkerhet och integration: behörighetskonfiguration och externa verktyg Boris använder inte --dangerously-skip-permissions-alternativet. Istället godkänner han några vanliga säkerhetskommandon med /permissions för att undvika att bekräftelserutan öppnas varje gång. Dessa konfigurationer sparas i .claude/settings.json och delas av teamet. Ännu kraftfullare är MCP-serverintegrationen. MCP, en förkortning av Model Context Protocol, är ett standardprotokoll lanserat av Anthropic som tillåter AI att ansluta till externa verktyg. Med MCP kan Claude Code direkt: - Sök och skicka Slack-meddelanden - Kör BigQuery-frågor för att besvara datafrågor - Hämta felloggen från Sentry Boris-teamet skickade också in Slacks MCP-konfiguration till arkivet, och alla använde den direkt ur lådan. Detta innebär att Claude Code inte bara är ett programmeringsverktyg, utan en "allt-i-ett-assistent" som kan kalla fram hela din verktygskedja. [8] Lång arbetsprocess: Låt Claude själv verifiera det För långvariga uppdrag har Boris flera strategier: Den första är att låta Claude automatiskt använda bakgrundsagenten för att verifiera resultaten efter slutförande. Du kan begära det i prompten, eller använda en Stop Hook för att trigga det mer deterministiskt. > Notera: Hooks är Claude Codes "hook"-mekanism som låter dig infoga anpassad logik vid specifika tillfällen när Claude utför en handling. Du kan tänka på det som en "trigger": när en händelse inträffar, exekverar automatiskt ditt förinställda kommando eller skript. > Stop Hook är när Claude svarar och är redo att lämna över kontrollen. > Relaterad dokumentation: Den andra är att använda ralph-wiggum-pluginet som i princip är en Bash-loop": föreställ dig en enkel dead loop (även om den är sann) som fortsätter mata samma task-sats (promptfil) till AI-agenten, vilket gör att den förbättrar sitt arbete om och om igen tills den är helt klar. Den tredje är att använda --permission-mode=dontAsk eller --dangerously-skip-permissions i sandlådemiljön, så att Claude inte blir avbruten av tillståndsbekräftelse och springer till slutet själv. Kärnidén är: eftersom det är en lång uppgift, låt den inte vänta på dig. Ge den tillräcklig autonomi och förmåga till självkorrigering. [9] Den viktigaste: ge Claude valideringsmöjligheter Boris lägger denna till slutet och säger att detta förmodligen är den viktigaste faktorn för att få ett bra resultat. Om Claude kan validera sitt arbete kan slutresultatet ökas med 2 till 3 gånger. Han gav ett exempel: för varje ändring de skickar in , testar Claude sig själv med Chrome-tillägg: öppnar webbläsaren, testar gränssnittet och itererar när det hittar ett problem tills det fungerar korrekt och upplevelsen är rimlig. Verifieringsmetoder varierar beroende på scenariot. Det kan vara att köra ett bash-kommando, köra en testsvit eller testa en app i en webbläsare eller mobil emulator. Formen är inte viktig, men det viktiga är: låt AI:n ha en återkopplingsslinga. Denna sanning är faktiskt väldigt enkel. Mänskliga ingenjörer förlitar sig också på cykeln "skriva kod-testning-se resultat-modifiera" för att säkerställa kvalitet. Samma sak gäller för AI. Om det bara kan skrivas och inte mätas är det som att göra saker med ögonen stängda, och kvaliteten beror på tur. Boris förslag är att investera i att befästa verifieringsmekanismen. Detta är den högsta avkastningen på investeringen. [10] Mästare använder svärd för att vinna utan drag I kampsportsromaner har mästare inte så många finesser med svärd, och det finns inga drag att vinna. Boris visar inte upp komplexa anpassade konfigurationer, har inga mystiska privata prompts och använder officiella funktioner. Skillnaden är att han verkligen förstår logiken bakom dessa funktioner och sedan kombinerar dem till ett effektivt arbetsflöde. Parallellt arbete utförs eftersom Claude kan utföra autonomt; Opus används på grund av den högre totala effektiviteten; Det är att omvandla felkorrigering till tillgångar; Plan-läget är att tänka klart innan man gör det; slash-kommandon och underagenter är automatiserat, repetitivt arbete; Verifieringsmekanismen är att ge AI-återkoppling en sluten slinga. Om du precis har börjat med Claude Code finns det ingen anledning att rusa in i avancerade konfigurationer. Använd grunderna väl först: lär dig arbeta parallellt, lär dig planera och lär dig att samla AI-verifieringsmetoder. När du verkligen stöter på en flaskhals är det inte för sent att kasta blommorna.

En sak Boris inte nämnde är det grundläggande CI/kodgranskningsflödet, vilket kan vara normalt för deras stora företag och som borde finnas där som standard Till exempel, när han slutför en uppgift med Claude Code, säger han inte att man ska slå ihop direkt till huvudgrenen, utan skickar in en PR. Efter att ha skickat in en PR kommer alla lint- och automatiserade tester automatiskt att köras på CI-servern, och om testet misslyckas kan PR:n inte slås ihop. En PR klarar alla automatiserade tester och behöver någon som gör en kodgranskning (AI-assistans är förstås möjlig, men det måste ändå bekräftas), och om kodgranskningen hittar problem måste den revideras. För många enskilda utvecklare är de inte vana vid att bygga ett CI/kodgranskningsarbetsflöde, och de gör inte ens Git-kodhantering, så de kan inte backa om något går fel.

[10] De där sakerna du inte kan se En sak Boris inte nämnde är det grundläggande arbetsflödet för versionskontroll/CI/kodgranskning, vilket kan vara normalt för deras stora företag och borde finnas där som standard Till exempel, när han slutför en uppgift med Claude Code, säger han inte att man ska slå ihop direkt till huvudgrenen, utan skickar in en PR. Efter att ha skickat in en PR kommer alla lint- och automatiserade tester automatiskt att köras på CI-servern, och om testet misslyckas kan PR:n inte slås ihop. En PR klarar alla automatiserade tester och behöver någon som gör en kodgranskning (AI-assistans är förstås möjlig, men det måste ändå bekräftas), och om kodgranskningen hittar problem måste den revideras. Dessa utgör också grunden för deras förmåga att multitaska parallellt, och utan dessa grundläggande arbetsflöden kan de inte multitaska parallellt. För många enskilda utvecklare är de inte vana vid att bygga ett CI/kodgranskningsarbetsflöde, och de gör inte ens Git-kodhantering, så de kan inte backa om något går fel.