Hur Boris Cherny använder Claude Code: Boris-planen för avancerad AI-utveckling

Om du söker efter “Boris Cherny hur han använder Claude Code” letar du troligen inte efter ännu en nybörjarlista med prompts.

Du vill förstå arbetsmodellen bakom seriös Claude Code-användning: hur människor nära verktyget tänker kring planering, parallella agenter, verifiering, projektminne, behörigheter, hooks och upprepningsbara engineering-flöden.

Vi har gjort en omfattande genomgång av officiell Claude Code-dokumentation, Boris Cherny-intervjuer, publika sammanfattningar och sekundära sammanställningar av Boris-attribuerade tips. Mönstret är tydligt: avancerad Claude Code-användning handlar inte om en perfekt prompt. Det handlar om att göra AI-kodning till ett kontrollerat operativsystem för utveckling.

På Hammer Automation kallar vi det Boris-planen.

För tydlighetens skull: “Boris-planen” är vår sammanfattande ram, inte en officiell Anthropic-term. Det är en praktisk modell destillerad från publikt material om Boris Cherny, Claude Code-teamet och den dokumenterade Claude Code-verktygslådan.

Boris-planen i en mening

Ge Claude Code en avgränsad uppgift, en isolerad arbetsyta, en stark plan, verklig verifiering, hållbart minne, specialiserade agenter, automation med hooks och tydliga behörighetsgränser.

Det är skillnaden mellan vardaglig AI-kodning och ett engineering-grade AI-arbetsflöde.

1. Sluta köra en Claude Code-session i taget

Det största skiftet för avancerade användare är parallellitet.

Boris beskrivs återkommande som någon som kör flera Claude Code-sessioner samtidigt, historiskt med separata utcheckningar och numera mer naturligt med git worktrees. Den officiella Claude Code-dokumentationen lyfter också worktrees som ett säkert sätt att köra parallella sessioner utan att filändringar krockar.

Poängen är inte att se upptagen ut. Poängen är att sluta tvinga en enda agent att hålla all kontext och alla roller i huvudet samtidigt.

Ett praktiskt upplägg:

• Session A: implementerar funktionen i ett dedikerat worktree.
• Session B: granskar samma område som en skeptisk granskare.
• Session C: fokuserar bara på tester, testdata och randfall.
• Session D: utforskar en konkurrerande implementationsväg.
• Session E: uppdaterar dokumentation, migrationsnoteringar eller PR-beskrivning.

Det är en annan mental modell än ”Claude, koda det här”. Det liknar mer att starta ett tillfälligt utvecklingsteam där varje agent har en ren arbetsyta och ett smalt ansvar.

Vad vanliga användare missar: de använder en lång session för allt. Då slåss implementation, research, misslyckade försök, granskningsanteckningar och orelaterade sidofrågor om samma kontextfönster.

Avancerat drag: isolera både filerna och tänkandet.

2. Plan-läget är kontrollpanelen

Boris råd återkommer ofta till planering. Sammanfattningen i The Pragmatic Engineer återger honom ungefär som att när planen är bra kan Claude ofta implementera i ett enda svep. Den officiella Claude Code-dokumentationen säger samma sak mer formellt: utforska först, planera sedan, koda därefter.

Plan-läge är inte byråkrati. Det är där du stoppar dyr avdrift innan den börjar.

Använd det när:

• uppgiften rör flera filer
• arkitekturen är oklar
• ändringen påverkar autentisering, betalning, behörigheter, migreringar eller kundnära beteende
• du inte känner kodvägen väl
• du vill att agenten identifierar tester innan den börjar redigera

En stark prompt för Plan-läge:

Utforska auth/session-flödet först. Redigera inte ännu.
Skriv sedan en plan för att lägga till rate limits på inloggningsförsök.
Ta med filer som sannolikt behöver ändras, risker, tester att lägga till och exakta verifieringskommandon.
Peka ut allt som är oklart innan implementation.

Utmana sedan planen innan du ger tillstånd att koda:

Granska din plan som en skeptisk staff engineer.
Vilka antaganden kan vara fel?
Vilken är den minsta säkra implementationen?
Vilken verifiering bevisar att detta fungerar?

Vad vanliga användare missar: de driver Claude rakt in i redigering och ägnar sedan resten av sessionen åt att korrigera fel angreppssätt.

Avancerat drag: lägg mer energi före redigering, så blir implementationen snabbare och renare.

3. Verifiering är den verkliga kvalitetsmultiplikatorn

Det här är den tydligaste överlappningen mellan Boris-attribuerade råd och officiell dokumentation.

Den officiella Claude Code-dokumentationen beskriver verifiering som en av de mest hävstångsstarka sakerna du kan göra. En publik sammanställning av Boris tips säger att hans främsta rekommendation är att ge Claude ett sätt att verifiera sitt arbete, med påståendet att slutkvaliteten kan förbättras två till tre gånger.

Den exakta multiplikatorn är mindre viktig än mekanismen: Claude behöver feedback från verkligheten.

Verifiering kan vara:

• ett riktat testkommando
• typkontroll, lint eller build
• webbläsarinspektion via Chrome-tillägg eller desktop-verktyg
• simulator-körningar för mobilt arbete
• logginspektion
• reproduktionsdata från Sentry
• BigQuery- eller analyskontroller
• jämförelse av screenshots
• CI-status
• en andra Claude-session som granskar diffen

Nyckelinstruktionen är inte ”skriv bra kod”. Nyckelinstruktionen är:

Stanna inte efter redigering. Kör det smalaste relevanta verifieringskommandot.
Om det fallerar, diagnostisera grundorsaken, fixa den och kör igen.
När det passerar, kör en bredare kontroll och sammanfatta kvarvarande risk.

För frontend-arbete: ge Claude en webbläsare. För backend-arbete: ge den tester och loggar. För dataarbete: ge den queries och förväntade utfall. För workflow automation: ge den en dry-run-väg.

Vad vanliga användare missar: de behandlar tester som något människor kör efter att Claude är klar.

Avancerat drag: tester är agentens feedbackloop.

4. CLAUDE.md är ackumulerande engineering-minne

Ett återkommande Boris-mönster är aggressivt underhåll av delat projektminne. Publika sammanställningar beskriver hur Claude Code-teamet håller en gemensam CLAUDE.md i git och uppdaterar den när Claude gör samma typ av misstag igen.

Det här är en av de viktigaste idéerna i hela arbetsflödet.

En korrigering ska inte dö i en chattlogg. Den ska bli en av fyra saker:

• en regel i CLAUDE.md
• ett slash-kommando
• en skill
• en hook

Bra innehåll i CLAUDE.md:

• exakta kommandon för build, test och lint
• repo-specifika konventioner som Claude inte kan räkna ut själv
• arkitektoniska gränser
• regler av typen ”rör aldrig detta direkt; använd den här wrappern”
• kända fallgropar
• branch-, PR- och migrationsetikett
• domänvokabulär
• säkerhetsbegränsningar

Dåligt innehåll i CLAUDE.md:

• generiska råd som ”skriv ren kod”
• långa tutorials
• gammalt onboarding-material
• fil-för-fil-sammanfattningar som Claude kan läsa själv
• sådant som ändras varje vecka

En användbar review-kommentar är inte bara:

Det här ska använda en string literal union, inte en enum.

Den ackumulerande versionen är:

Fixa detta och uppdatera sedan CLAUDE.md så att framtida ändringar undviker TypeScript-enums och föredrar string literal unions i det här repot.

Vad vanliga användare missar: de korrigerar Claude manuellt varje gång.

Avancerat drag: varje upprepad korrigering blir infrastruktur.

5. Gör upprepade prompts till slash-kommandon, skills och hooks

Om du skriver samma instruktion mer än en gång per dag bör den förmodligen inte vara en prompt längre.

Boris-attribuerade publika tips betonar slash-kommandon för upprepade innerloopar. Officiell dokumentation beskriver också commands, skills, hooks och settings som delar av Claude Codes operativa yta.

Välj rätt verktyg:

• Slash-kommandon: återanvändbara arbetsflöden som operatören triggar.
• Skills: uppgiftsspecifika procedurer och kontext som laddas vid behov.
• Hooks: deterministisk lifecycle-automation runt tool calls eller sessionshändelser.
• Subagenter: specialiserade arbetare med separat kontext och separata behörigheter.

Exempel värda att bygga:

/fix-ci
Inspektera fallerande CI, reproducera lokalt om möjligt, patcha grundorsaken, kör kontroller igen och sammanfatta risk.

/security-review
Granska aktuell diff för auth, behörigheter, secrets, dataexponering och osäkert shell- eller nätverksbeteende.

/release-check
Kör changelog, version, tester, build, smoke checks och PR-sammanfattning före release.

/customer-bug
Läs buggrapporten, samla loggar/Sentry/kontext, identifiera sannolika filer, föreslå plan och vänta sedan innan redigering.

Hooks är där det här blir ännu vassare. En PostToolUse-hook kan formatera efter ändringar. En Stop-hook kan notifiera dig, köra en slutkontroll eller hindra en session från att avslutas innan ett villkor är uppfyllt. En permission hook kan blockera destruktiva kommandon.

Vad vanliga användare missar: de håller sina bästa arbetsflöden instängda i minnet.

Avancerat drag: lyft upprepat beteende till verktyg som teamet kan återanvända.

6. Använd subagenter för att separera tänkandet

Subagenter är inte bara ”mer Claude”. De är ett verktyg för kontexthantering.

Officiell dokumentation beskriver subagenter som specialiserade assistenter med egna kontextfönster. Det spelar roll eftersom kodbasresearch, logggrävande, testfel och review-diskussioner snabbt kan översvämma huvudsessionen.

Använd subagenter när:

• utforskning kräver läsning av många filer
• review inte ska ärva implementatörens antaganden
• säkerhet behöver en separat lins
• testning kräver brusig kommandoutmatning
• migrationsarbete kan delas upp per modul
• dokumentation kan ske oberoende

Ett starkt mönster:

1. Huvudsessionen äger uppgiften och planen.
2. En subagent undersöker relevant kodväg.
3. Huvudsessionen implementerar.
4. En separat subagent granskar diffen.
5. En annan subagent verifierar tester eller randfall.
6. Huvudsessionen väger samman feedback.

Det här är särskilt användbart för avancerade användare eftersom problemet inte längre är ”kan Claude redigera kod?” Problemet är ”kan jag hålla rätt kontext på rätt plats?”

Vad vanliga användare missar: de låter ett kontextfönster bli en skräplåda.

Avancerat drag: delegera brusigt arbete ut ur huvudtråden.

7. Använd behörigheter för att röra dig snabbt och säkert

En anledning till att avancerade användare får dramatiskt mer värde av Claude Code är att agenten inte blockeras var trettionde sekund.

Men svaret är inte alltid --dangerously-skip-permissions.

Boris-attribuerade tips betonar att man bör förgodkänna säkra kommandon via /permissions och delade settings. Officiell dokumentation stödjer samma bredare idé genom settings, permission scopes, sandboxing, hooks och managed policies.

Tillåt fritt:

• smala testkommandon
• typkontroll och lint
• formatterare
• lokala builds
• ofarlig filläsning
• branch-lokala fixture-uppdateringar

Kräv godkännande för:

• produktionsdeploys
• databasmigreringar
• auth- och billing-ändringar
• destruktiva shell-kommandon
• force pushes
• externa skrivningar
• åtkomst till kunddata
• secrets och credentials

Det är här många företag fastnar. Antingen gör de Claude för svag för att vara användbar eller för kraftfull för att vara säker.

Den avancerade setupen är en mellanväg: snabbspår för säkert arbete, hårda grindar för riskfyllt arbete och tydliga ”aldrig”-zoner.

Vad vanliga användare missar: behörigheter behandlas som irriterande prompts.

Avancerat drag: behörigheter är workflow design.

8. Koppla Claude Code till systemen där sanningen finns

Claude Code blir mycket mer användbart när det kan se samma operativa kontext som människor använder.

Boris-attribuerade arbetsflöden nämner verktyg som Slack, BigQuery, Sentry, webbläsartestning, MCP-integrationer och loggar. Lärdomen är inte ”koppla in allt”. Lärdomen är: koppla in systemen som stänger loopen.

Användbara integrationer:

• GitHub: PR:er, reviews, CI, issues och changelogs
• Sentry/loggar: riktiga fel och stack traces
• Slack: buggrapporter, kundkontext och interna beslut
• BigQuery/analytics: produktbeteende och regressionskontroller
• Browser/Chrome extension: visuell och interaktiv frontend-verifiering
• MCP-servrar: kontrollerad åtkomst till interna verktyg

En bugfix-prompt blir mycket starkare när den innehåller den verkliga tråden, felloggar, senaste deployen och verifieringskommandot.

Använd Slack-tråden, Sentry-ärendet och diffen från senaste deployen för att identifiera sannolik grundorsak.
Redigera inte förrän du har en plan och en verifieringsväg.

Vad vanliga användare missar: de klistrar in en vag buggbeskrivning och förväntar sig att Claude ska förstå hela världen.

Avancerat drag: placera Claude i det verkliga arbetsflödet, med gränser.

9. Använd modeller med högre ansträngning när styrning är den dyra delen

En fan-sammanställning av Boris publika inlägg säger att han föredrog Opus med thinking/high effort eftersom större modeller, även om de är långsammare per svar, kräver mindre styrning och använder verktyg bättre.

Det här är datumkänsligt. Modellnamn och standardinställningar ändras. Men principen är hållbar:

Optimera inte bara för kostnad per svar. Optimera för kostnad per färdig, verifierad uppgift.

Använd starkare resonemang för:

• arkitekturändringar
• svår debugging
• migreringar
• okända kodbaser
• säkerhetskänsliga ändringar
• verktygsanvändning i flera steg
• uppgifter där ett fel första vägval blir dyrt

Använd billigare eller snabbare inställningar för:

• enkla redigeringar
• sammanfattningar
• formatering
• mekaniska dokumentationsuppdateringar
• smal testgenerering

Vad vanliga användare missar: de väljer modell efter prislapp eller latens.

Avancerat drag: välj utifrån förväntad styrkostnad och felkostnad.

10. Bygg en Boris-plan för ditt operativa flöde

Den praktiska planen ser ut så här:

1. Välj en värdefull men avgränsad uppgift.
2. Starta en ny session eller ett isolerat worktree.
3. Använd Plan-läge före redigering.
4. Be Claude identifiera verifieringskommandon.
5. Låt Claude implementera mot den godkända planen.
6. Kräv smal verifiering och därefter bredare verifiering.
7. Använd en subagent eller separat session för review.
8. Merga först när diff, tester och risker är tydliga.
9. Omvandla upprepad feedback till CLAUDE.md, ett slash-kommando, en skill eller en hook.
10. Kör nästa liknande uppgift med mindre mänsklig styrning.

Det här är det verkliga avancerade arbetsflödet. Inte ”skriv bättre prompts”. Inte ”lita på AI:n”. Inte ”låt den göra allt”.

Det är att bygga en agentisk engineering-loop där Claude Code kan agera, kontrollera, lära och lämna över på ett säkert sätt.

Vad du bör systematisera härnäst

Om ditt team redan använder Claude Code, börja inte med att köpa ännu ett promptbibliotek. Börja med att kartlägga arbetet ni upprepar.

Leta efter:

• PR-kommentarerna du skriver varje vecka
• buggarna som följer samma felsökningsväg
• release-kontrollerna som lever i en persons huvud
• migreringarna som alla tycker är obehagliga
• kundspecifika ändringar som kräver tribal knowledge
• dashboards och loggar som utvecklare inspekterar manuellt
• testerna Claude glömmer att köra
• kommandona alla godkänner manuellt

Bestäm sedan vad varje sak bör bli:

• en regel i CLAUDE.md
• ett slash-kommando
• en skill
• en hook
• en subagent
• en MCP-integration
• en behörighetspolicy
• ett schemalagt eller målstyrt arbetsflöde

Det är här Hammer Automations arbete passar naturligt in. Värdet är inte ”AI-kodningstips”. Värdet är att göra ad hoc-användning av AI till upprepningsbara, behörighetsstyrda arbetsflöden där agenter kan planera, agera, verifiera och lämna över säkert.

För avancerade Claude Code-användare är nästa nivå inte mer prompting.

Det är operativ design.

Källor och tillförlitlighet

Den här artikeln är en svensk översättning och anpassning av ett engelskt Hammer Automation-utkast om Boris Cherny och Claude Code. Den är skriven för praktiska, avancerade Claude Code-användare och använder begrepp som ”Boris-planen” och ”hur Boris använder Claude Code” som SEO-vänliga sammanfattningar av publikt attribuerade arbetsflöden.

• Officiell Anthropic- och Claude Code-dokumentation: Best practices, Worktrees, Subagents, Hooks, Memory / CLAUDE.md, /goal.
• Boris-attribuerade intervjuer och sammanfattningar: Lenny’s Podcast episode page, Every / AI & I med Cat Wu och Boris Cherny, The Pragmatic Engineer interview summary.
• Sekundär/community-skapad sammanställning: How Boris Uses Claude Code är ett användbart index över publika tips, men enskilda påståenden bör behandlas som sammanställda publika anteckningar om de inte verifieras mot länkade originalinlägg.
• Ytterligare sekundär kontext: Developing.dev Boris Cherny interview summary.