Du kjører Claude Code i første gir — her er Beast Mode-oppsettet som endrer alt

---

De fleste utviklere som installerer Claude Code gjør det samme: de kjører npm install -g @anthropic-ai/claude-code, åpner terminalen, og begynner å chatte. Kanskje de legger inn en CLAUDE.md med noen linjer. Kanskje ikke. Og så lurer de på hvorfor verktøyet «ikke lever opp til hypen».

Problemet er ikke Claude Code. Problemet er at du kjører en Ferrari i første gir.

Vi har brukt de siste ukene på å grave i alt fra Boris Chernys personlige workflow til obskure GitHub-repoer med tusenvis av stjerner — og satt sammen oppsettet som faktisk utnytter det Claude Code kan. Her er resultatet: 6 konkrete steg som tar omtrent 30 minutter å sette opp, men som endrer måten du koder på permanent.

Steg 1: CLAUDE.md — den mest undervurderte filen i prosjektet ditt

Det finnes én fil som har større innvirkning på Claude Code-kvaliteten enn noen annen kodeendring du kan gjøre. Den heter CLAUDE.md, og de fleste ignorerer den fullstendig.

Boris Cherny, mannen som faktisk bygde Claude Code hos Anthropic, har én klar melding: Legg kun inn det Claude ikke kan utlede fra koden selv. Har du package.json med React? Da vet Claude allerede at du bruker React. Gjenta det ikke. Har du tsconfig.json? Da vet Claude at det er TypeScript. Spar plassen.

Det du skal ha der er ting som er usynlige i koden — commit-konvensjoner, språkpreferanser, databaseregler som «aldri bruk prisma db push», arkitekturbeslutninger som «vi valgte Zustand over Redux fordi X».

Systemet har to nivåer:

Global CLAUDE.md (~/.claude/CLAUDE.md) gjelder for absolutt alt du gjør. Tenk: «hvem er jeg som utvikler?» Her legger du commit-format, språk, code review-krav og universelle databaseregler. Hold den på 10–20 linjer.

Prosjekt-CLAUDE.md (./CLAUDE.md i roten) handler om dette prosjektet. Arkitektur, gotchas, testkonvensjoner, ting som har bitt deg før. Hold den på 30–50 linjer.

Skriv i CLAUDE.md det du ville fortalt en nyansatt senior-utvikler på dag én — ikke det som allerede står i koden

Ifølge research fra flere AI-utviklingsmiljøer følger Claude bullet points 60% bedre enn prosa. Og filer over 100 linjer begynner å fortynne oppmerksomheten. Tommelfingerregelen: 30–100 linjer, bullet points, null fyllstoff.

Steg 2: 5 plugins som forvandler Claude Code fra autocomplete til utviklerteam

Claude Code har et plugin-system som de færreste vet om — og enda færre bruker skikkelig. Det finnes over 100 tilgjengelige utvidelser. Vi har testet de fleste. Disse fem er de som faktisk gjør en forskjell.

code-review — 5 agenter jobber parallelt

Når du kjører /code-review, skjer noe de fleste ikke forventer: Claude spinner opp fem separate Sonnet-agenter som jobber parallelt. Én sjekker CLAUDE.md-etterlevelse. Én scanner for bugs. Én leser Git-historikk for kontekst. Én sjekker tidligere PR-kommentarer. Og den siste verifiserer at koden følger egne kodekommentarer.

Hvert funn scores på en skala fra 0 til 100. Bare funn med score over 80 rapporteres. Det betyr at du slipper falske positiver og nitpicking — du får bare det som faktisk betyr noe.

pr-review-toolkit — 6 spesialagenter

Denne pakken gir deg seks nisjeagenter: silent-failure-hunter som finner undertrykte feil (catch-blokker som svelger exceptions), pr-test-analyzer for testdekning, type-design-analyzer for TypeScript-typer, comment-analyzer, code-simplifier og en generell code-reviewer. Hver agent har sitt eget fokusområde.

ralph-wiggum — autonome loops

Oppkalt etter Simpsons-karakteren, laget av Anthropic-utvikler Daisy Hollman. Konseptet er enkelt men kraftig: en Stop-hook som forhindrer Claude fra å stoppe. I stedet kjører den videre i en loop, evaluerer sin egen fremdrift, og stopper først når oppgaven er ferdig.

Aktiver med /ralph-loop "Refaktorer hele autentiseringssystemet" og la Claude jobbe mens du tar en kaffe. Avbryt med /cancel-ralph når du vil.

security-guidance — 9 farlige mønstre blokkert

En PreToolUse-hook som kjører før hver eneste Bash-kommando og fil-operasjon. Den overvåker command injection, XSS, eval()-bruk, farlig HTML, pickle-deserialisering, os.system-kall og mer. Blokkerer automatisk — ingen manuell innsats.

hookify — hooks som skriver seg selv

Etter en sesjon der noe gikk galt — kanskje Claude pushet til feil branch, kanskje den overskrev en fil — kjør /hookify. Pluginet analyserer samtalen og genererer en hook som forhindrer nøyaktig det problemet i fremtiden. Selvforbedrende utviklermiljø.

Steg 3: Hooks som gjør kvalitetssikring umulig å glemme

Plugins er valgfrie. Hooks er det ikke. De kjører automatisk, uten at du trenger å huske noe.

PreToolUse: Commit-gaten

Her er scenariet: Du har kodet i en time, alt fungerer, du skriver git commit — og Claude blokkeres. Exit code 2. Meldingen: «BLOKKERT: Kjør code review før commit.»

Hooken leser fra Claude Codes transcript-logg og sjekker om code review har blitt kjørt i denne sesjonen. Hvis ikke? Ingen commit. Punktum. Dette er ikke en anbefaling du kan ignorere — det er en fysisk blokkering.

Teknisk fungerer det slik: Et bash-script mottar JSON på stdin med kommandoen Claude prøver å kjøre. Scriptet sjekker om det er en git commit, og hvis ja, leter det etter spor av code-review i transcript-filen. Finner det ingenting, returnerer det exit code 2 — som betyr «blokkér denne operasjonen og gi Claude denne tilbakemeldingen».

PostToolUse: Auto-formatering

Hver gang Claude skriver eller endrer en fil, kjører Prettier automatisk etterpå. Ingen diskusjon om formatering, ingen glemte npm run format. Det bare skjer.

Stop: Varsling når Claude er ferdig

Den mest undervurderte hooken. Når Claude fullfører en oppgave, sender den en desktop-notifikasjon — på Windows via PowerShell-bro fra WSL2, på Linux via notify-send. Du slipper å sitte og stirre på terminalen mens Claude jobber. Start oppgaven, bytt til noe annet, bli varslet når den er klar.

Steg 4: Context7 MCP — slutt på hallusinerte API-er

Har du noen gang fått Claude til å skrive kode mot et API som ikke lenger eksisterer? Eller brukt en funksjon som ble deprecated for tre versjoner siden? Det er fordi Claude bruker treningsdataene sine — som alltid er noen måneder utdatert.

Context7 løser dette. Det er en MCP-server (Model Context Protocol) som injiserer oppdatert dokumentasjon for over 1000 biblioteker direkte inn i Claude Code. Når Claude skal skrive Next.js 16-kode, får den den faktiske, nåværende dokumentasjonen — ikke det den husker fra treningen.

Installasjon tar bokstavelig talt én kommando:

claude mcp add --scope user --transport http context7 https://mcp.context7.com/mcp

Ferdig. Fra neste sesjon har Claude tilgang til live-docs for React, Next.js, Prisma, Tailwind, Express, FastAPI, Django og hundrevis av andre biblioteker. Gratis.

Context7 dreper det vanligste AI-kodingsproblemet: hallusinerte API-er som ikke lenger eksisterer

Steg 5: Extended thinking — tregere er raskere

I ~/.claude/settings.json finnes det én innstilling som Boris Cherny har på til enhver tid: alwaysThinkingEnabled: true.

Intuitivt virker det bakvendt. Extended thinking gjør hver tur merkbart tregere — Claude bruker tid på å «tenke» før den svarer. Men Boris sitt argument er konkret: du trenger å styre Claude mindre. Færre feil betyr færre korreksjoner. Færre korreksjoner betyr færre runder. Og færre runder betyr at totalttiden går ned, ikke opp.

For ekstra krevende oppgaver — kompleks refaktorering, arkitekturbeslutninger, debugging av race conditions — kan du bruke /think for å trigge enda dypere resonnering.

Steg 6: Parallellisering — flere Claude-instanser, null konflikter

Den siste brikken handler ikke om konfigurasjon, men om workflow. Og den er overraskende enkel.

Worktrees + tmux lar deg kjøre flere Claude Code-sesjoner på samme repo uten at de overskriver hverandres filer:

claude --worktree min-feature --tmux

Denne kommandoen oppretter et isolert Git-worktree med sin egen branch, starter en tmux-sesjon, og lar Claude jobbe uforstyrret. Du kan ha 3-4 slike kjørende parallelt — én for frontend, én for backend, én for tester.

Kombiner dette med ralph-wiggum loops (/ralph-loop "implementer X") og du har i praksis et lite utviklerteam som jobber parallelt, autonomt, til oppgavene er ferdige.

Vanlige feil som dreper produktiviteten

CLAUDE.md som er en roman. Over 100 linjer og Claude begynner å deprioritere instruksjoner. Kutt til beinet.

Gjentar det koden allerede viser. Hver linje i CLAUDE.md som dupliserer noe fra package.json, tsconfig.json eller mappestrukturen er bortkastet plass.

Ingen verifikasjonssteg. Boris Chernys viktigste råd: «Gi Claude en måte å verifisere sitt eget arbeid — det 2–3x-er kvaliteten.» Tester, type-checking, linting — Claude må kunne sjekke seg selv.

Ignorerer MEMORY.md. Personlige preferanser — som at du foretrekker norsk, eller at du har fatigue i hendene og trenger korte svar — hører hjemme i ~/.claude/projects//memory/MEMORY.md. Ikke i CLAUDE.md.

Bruker Claude Code uten plugins. Det er som å installere VS Code uten extensions. Teknisk mulig, men du går glipp av det meste.

Hva dette betyr i praksis

Med dette oppsettet skjer følgende automatisk i hver sesjon:

Claude tenker dypere takket være extended thinking. Den har tilgang til oppdatert dokumentasjon via Context7. Når den skriver kode, formateres den automatisk av Prettier-hooken. Når du prøver å committe, blokkeres du fysisk til code review er kjørt — med 5 parallelle agenter som fanger reelle bugs, ikke falske positiver. Og når alt er ferdig, får du en desktop-notifikasjon.

Du trenger ikke huske noe av dette. Hookene og pluginene gjør jobben for deg.

Det er forskjellen mellom å bruke Claude Code — og å utnytte Claude Code.