Plan Mode i Claude Code: trinnvis veiledning og 4 faser i 2026

Flere instruksjoner finner du i Ailoot-dokumentasjonen.

Hva er Plan Mode, og hvorfor er det ikke nok i seg selv?#

I normal modus skriver Claude Code kode umiddelbart, og hvis du ikke følger med, kan du få en diff på tvers av mange filer ut av det blå. Plan Mode snur på rekkefølgen: først undersøkelser og planlegging, deretter godkjenning, så endringer.

Anthropic beskriver Plan Mode slik i den offisielle dokumentasjonen:

Det høres enkelt ut, men skjuler den viktigste endringen. Plan Mode endrer arbeidsrytmen: bli enige først, handle etterpå. Det er en endring av modus, ikke en kosmetisk justering. Problemet for vibe-kodere er at KI-agenter har en tendens til å haste. Hvis du ber om «Legg til Google-autentisering» i normal modus, skriver Claude koden på et minutt, men halvparten av filene blir feil. I Plan Mode blir den samme forespørselen til en tekstplan som du kan lese på to minutter og rette før noen kode blir berørt.

Her er en felle som ingen skriver om i internasjonale veiledninger. Plan Mode alene er et svakt verktøy: planen finnes bare i den gjeldende samtalen. Lukk vinduet, så er planen borte. Du kan ikke overlate den til en annen agent. Det finnes ingen versjoner eller historikk. Hvis oppgaven er stor (refaktorering av en modul på 30 filer, migrering til en ny database), når planen raskt grensen for kontekstvinduet og begynner å bli dårligere.

Derfor fungerer Plan Mode godt sammen med en plans/-mappe i repositoriet. Planen lagres som plans/2026-05-21-google-oauth.md, deles inn i faser med avkrysningsbokser, og den neste agenten kan ta over. Slik fungerer kontekstteknikk – du styrer konteksten før ledeteksten, ikke underveis.

Hvordan aktiverer du Plan Mode i Claude Code?#

Den raskeste måten i en økt er tastaturet:

Shift+Tab           # cycles through modes: default → acceptEdits → plan

Etter to trykk vises indikatoren ⏸ plan mode on nederst i terminalen. Et tredje trykk går tilbake til normal modus. Dette er den mest praktiske metoden – du kan slå på modusen underveis når du ser at oppgaven vokser.

Den andre metoden er å sette et prefiks foran én enkelt ledetekst:

/plan write a plan to migrate the database from MySQL to Postgres

Dette er nyttig når du er i automatisk godkjenningsmodus og ikke vil endre innstillingen for hele økten. Én forespørsel i Plan Mode, og deretter fortsetter arbeidet som før.

Den tredje metoden er ved oppstart av økten:

claude --permission-mode plan

Bruk dette når du vet på forhånd at en oppgave trenger planlegging. For eksempel før en større refaktorering eller migrering.

Den fjerde metoden er å angi standarden i .claude/settings.json i prosjektet:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Når er dette nyttig? Når et team jobber med et komplekst system der enhver endring kan påvirke nærliggende moduler. Da beskytter Plan Mode som standard alle mot utilsiktede endringer.

Et femte triks som ofte blir oversett: Ctrl+G åpner planen i et tekstredigeringsprogram. Bruk det når planen nesten er riktig, men du må omformulere 2-3 punkter eller legge til en begrensning. Rediger den manuelt, lagre, og Claude fortsetter med din versjon.

Hva er Anthropics kanoniske 4 faser i Plan Mode: Explore, Plan, Implement, Commit?#

Mange veiledninger beskriver 3 faser (Explore-Plan-Execute) eller bare 2 (Plan-Implement). Dette er forenklinger. I sin offisielle veiledning for beste praksis beskriver Anthropic nøyaktig 4 faser. Forskjellen er viktig: Når Commit er en egen fase, blir du nødt til å registrere resultatet i stedet for å la det bli med «Jeg gjorde noen flere justeringer her, jeg committer senere» – den vanligste årsaken til tapt arbeid.

Jo mer presis planen er, desto færre iterasjoner trengs i gjennomføringen. Bruker du 10 minutter på planen, tar gjennomføringen én ledetekst. Skisserer du planen på et minutt, vil gjennomføringen kreve en time med rettinger.

Slik ser de 4 fasene ut når du legger til Google OAuth (et eksempel fra Anthropic Docs):

Ledetekstene er også forskjellige i hver fase. I Explore: «les /src/auth og finn ut hvordan vi håndterer økter og innlogging». I Plan: «Jeg vil legge til Google OAuth. Hvilke filer må endres? Lag en plan». I Implement: «gjennomfør OAuth-flyten fra planen, skriv tester, kjør testsuiten og rett feil». I Commit: «opprett en commit med en beskrivende melding og åpne en PR».

En viktig nyanse: Plan Mode hindrer ikke Claude i å kjøre kommandoer for undersøkelser. Read, LS, Glob, Grep, web fetch og skallkommandoer for utforsking er tillatt. Bare Edit, Write og alle filsystemoperasjoner som gjør endringer, er forbudt. Det betyr at Claude kan lese prosjektstrukturen, kjøre git log og se på tester – men den kan ikke endre noe ved et uhell.

Hvordan leser du Claudes plan og avgjør om du skal godkjenne den?#

Når Claude er ferdig med å lage en plan, viser den alternativer for hva du kan gjøre videre:

• Godkjenn og start i automatisk modus
• Godkjenn og godta redigeringer
• Godkjenn og gjennomgå hver redigering manuelt
• Fortsett planleggingen med tilbakemelding
• Forbedre med Ultraplan (nettlesergjennomgang)

Å vite om du skal godkjenne en plan, er nøkkelferdigheten i Plan Mode. Det er lett å trykke automatisk på «Godkjenn» og deretter måtte tilbakestille commits. Den smiskende KI-en vil gi et raskt svar, og du vil komme raskere til koden. Begge tar feil.

En god plan oppfyller 7 kriterier:

1. Konkrete filnavn. Ikke «Jeg oppdaterer autentisering», men «Jeg endrer src/auth/login.ts:42-58, oppretter src/auth/oauth-callback.ts og oppdaterer src/auth/session.ts:103.»
2. Rekkefølgen er spesifisert. Planen er delt inn i faser eller trinn, ikke «Jeg gjør alt dette et eller annet sted».
3. Eksterne avhengigheter er navngitt. Hvis oppgaven krever et nytt bibliotek, står det på listen. Hvis miljøvariabler trengs, står de også der.
4. Risikoer er oppført. En god plan sier: «Migreringen kan ødelegge eksisterende økter; X må kontrolleres.» En dårlig plan sier ingenting om bivirkninger.
5. Det finnes suksesskriterier. «Testene i test/auth består, linteren er ren, og utviklingsserveren starter uten feil.»
6. Ingen antakelser som er «tatt ut av løse luften». Hvis Claude sier «Jeg bruker bibliotek Z», bør du sjekke: Har du i det hele tatt installert det i prosjektet? Hvis KI-en fant det på, ser du at det ikke er nevnt i package.json.
7. Planen får plass på skjermen. Hvis planen for en enkel funksjon tar opp 200 linjer, er oppgaven sannsynligvis for stor til én plan. Del den opp.

Når en plan ikke består kontrollen, finnes det tre alternativer:

• Fortsett planleggingen med tilbakemelding – gi Claude en konkret kommentar om hva du ikke liker, så skriver den planen om.
• Ctrl+G – åpne planen i et redigeringsprogram, rediger den manuelt og lagre. Claude fortsetter med din versjon.
• Forbedre med Ultraplan – planen legges inn i nettlesermodusen til Claude Code på nettet. Der går du gjennom delene og kommenterer, og kjører den deretter lokalt eller i skyen.

Hvis noe går galt midt i gjennomføringen, ikke tving det gjennom. Gå tilbake til Plan Mode og skriv planen på nytt. Det er 10 ganger billigere enn å tilbakestille 40 commits senere.

Plan Mode + en plans/-mappe: en kombinasjon for lang kontekst#

Plan Mode er en Claude Code-modus. plans/-mappen er en metode som bygger på den. Hvis du bruker Plan Mode uten en mappe, når du grensen etter en times arbeid.

Logikken er slik. Claudes kontekstvindu er øktens minne. Det får plass til 1 million tokens i Opus 4.7, men dette er hele samtalen din. Hvis du planlegger en kompleks oppgave i én samtale, deretter ber om implementering, diskuterer en feil og så noe annet, blir vinduet «oppblåst». Claude begynner å glemme tidlige beslutninger, blande sammen kontekster og stille spørsmål på nytt.

Løsningen er den gylne regelen: én oppgave – én samtale.

Slik gjør du det:

1. Samtale 1 – lag planen. Aktiver Plan Mode, beskriv oppgaven, og Claude lager en plan. Lagre planen i plans/2026-05-21-feature-name.md. Lukk vinduet.
2. Samtale 2 – del den inn i faser. Åpne en ny chat. Be: «ta plans/2026-05-21-feature-name.md og del den inn i faser». Lagre den oppdaterte filen.
3. Samtale 3 – gjennomfør fase 1. Åpne en ny chat. Be: «gjennomfør fase 1 fra plans/2026-05-21-feature-name.md og kryss av punktene etter hvert som du fullfører dem». Lukk vinduet.
4. Samtale 4 – gjennomfør fase 2. Gjør det samme.

Hva gir dette deg? Kontekstvinduet for hver samtale holder seg ferskt. Claude i fase 3 kjenner ikke detaljene fra fase 1, men kjenner planen fordi plans/-filen ligger i repositoriet. Den neste agenten (enten en underagent, en ny økt eller en kjøring via /goal) kan ta over planen og fortsette.

Sammenligning av tilnærminger:

Hver funksjon har sin egen planfil. Når du tre måneder senere må huske hvorfor du valgte én betalingsleverandør fremfor et alternativ, kan du åpne den relevante planen og lese beslutningshistorikken: hva som ble diskutert, hvilke alternativer som ble vurdert, og hvorfor akkurat denne veien ble valgt.

Dette er levende arbeidsplaner; statisk dokumentasjon blir utdatert i løpet av noen måneder.

Hvordan kan du få Claude til å jobbe mens du sover, med Plan Mode og /goal?#

Den største begrensningen i lange KI-økter er ikke selve modellen, men personen som trykker på Enter. Hver gang Claude når slutten av en omgang, venter den på svaret ditt. /goal fjerner denne ventetiden.

Syntaksen er enkel:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

Vilkåret kan være opptil 4000 tegn. Én målsetting per økt. Etter hver omgang ser Haiku-minimodellen på transkripsjonen og avgjør: «vilkåret er oppfylt – avslutt» eller «ikke oppfylt – neste omgang». Evaluatoren bruker ikke verktøy; den leser bare.

Aliaser for å fjerne målsettingen: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Kombinasjonen med Plan Mode ser slik ut:

1. Aktiver Plan Mode (trykk Shift+Tab to ganger).
2. Be: «lag en plan for å migrere databasen fra MySQL til Postgres, og lagre den i plans/2026-05-21-postgres-migration.md med faser og kriterier».
3. Gå gjennom planen, rediger den og godkjenn den.
4. Avslutt Plan Mode (trykk Shift+Tab én gang til).
5. Sett et mål: «fullfør alle faser i plans/2026-05-21-postgres-migration.md, kryss av i boksene, alle tester består, ellers stopp etter 50 omganger».
6. Lukk laptopen og legg deg.

Om morgenen kontrollerer du resultatet: enten «✓ mål fullført» eller «◎ stoppet etter 50 omganger», med en historikk over det som ble gjort.

Det er tre viktige regler for /goal, ellers sløser du med tokens:

Regel 1: En målbar sluttilstand. «Få det til å se fint ut» er dårlig. «npm test returnerer 0, npm run lint returnerer 0, og en oppføring er lagt til i CHANGELOG.md» er bra.

Regel 2: Uttrykkelig verifisering. Vilkåret bør vise til noe som kan verifiseres: en kommando, fil eller et endepunkt. Ikke «alt fungerer», men «curl localhost:3000/api/users returnerer 200».

Regel 3: Begrens antall omganger. Legg alltid til «eller stopp etter N omganger». Anthropic anbefaler uttrykkelig følgende i dokumentasjonen:

Hvis du aktiverer /goal uten «stopp etter», kan budsjettet forsvinne i løpet av natten.

Hvilken 4-trinnssyklus gjør Plan Mode til en ingeniørprosess?#

En vanlig feil er å spørre «hvordan fikser jeg det?»: Claude foreslår en løsning, du tar den i bruk, men ingenting fungerer eller ting blir verre. Dette er den «smiskende KI-en»: Den er trent til å svare raskt, og du vil komme raskere til koden. En 4-trinnssyklus løser dette.

4-trinnssyklusen stopper denne modusen. Den brukes trinnvis i én Plan Mode-økt:

Trinn 1. Fastslå fakta uten å foreslå en løsning.

Ledetekst: «Jeg opplever følgende: [symptombeskrivelse]. Oppgaven din nå er å fastslå fakta. Alle løsninger, ideer og råd er forbudt. Bare: hva jeg observerer, hvilke trinn som kan gjentas, hvilke data som er tilgjengelige, og hvilke data som mangler. Absolutt stoppvilkår: IKKE foreslå løsninger; bare registrer diagnosen.»

Dette stopper KI-ens første innskytelse: «her er løsningen». Claude må stoppe ved «hva som er kjent og ukjent».

Trinn 2. Utvikle alternativer med eksempler.

Ledetekst: «Nå som diagnosen er fastslått, finn eksempler på nettet på hvordan lignende problemer er løst. Minst 3 ulike tilnærminger. For hver: en lenke til primærkilden, en kort beskrivelse og fordeler og ulemper for vår situasjon.»

Dette stopper KI-ens andre innskytelse: «finn på en løsning på sparket». Vi ber den gå ut i verden og hente tilbake tilnærminger som kan kontrolleres.

Trinn 3. Detaljert plan med risikoer.

Ledetekst: «Ta det beste alternativet fra trinn 2 og lag en detaljert plan: hvilke konkrete filer som skal berøres, hva som skal legges til, hva som skal fjernes, hvilke tester som skal skrives, hva som kan gå i stykker, og hvilke risikoer som finnes 2-3 trinn frem i tid.»

Dette er den velkjente Plan-fasen, men med én forskjell: Den er basert på de verifiserte alternativene fra trinn 2, ikke på Claudes gjetninger.

Trinn 4. Egenkontroll av planen.

Ledetekst: «Gjør nå en obligatorisk egenkontroll. Gå ærlig gjennom planen på nytt: Finnes det steder der du har tatt noe ut av løse luften og ikke kontrollert det mot koden, dokumentasjonen eller et eksempel fra trinn 2? Hvis det er tilfelle, marker det og revider planen.»

Dette er det siste filteret. Claude må kontrollere sin egen resonnering og innrømme hvor den hallusinerte. Vanligvis blir minst 2 punkter i planen revidert i dette trinnet.

Etter de 4 trinnene er planen klar for godkjenning. Du kan gå videre til gjennomføringen, trygg på at oppgaven er forstått, alternativene er vurdert og risikoene tatt med i betraktningen.

Denne metoden er ment for å diagnostisere vanskelige feil og ta arkitekturvalg – situasjoner der feil har høye kostnader. Brukt med Plan Mode fjerner den den største frustrasjonen for vibe-kodere: «KI-en ga meg en løsning, jeg tok den i bruk, og alt gikk i stykker».

Hvilke 5 ferdige ledetekster fungerer i Plan Mode for vanlige oppgaver?#

Mal 1. Refaktorering av en modul.

Jeg aktiverer Plan Mode. Oppgave: refaktorer modulen {module-name}.

Trinn 1: Undersøk den nåværende strukturen til modulen {module-path}. Beskriv:
- hvilke filer som hører til modulen
- hvilke eksterne avhengigheter den har
- hvilke deler som er duplisert
- hvilke funksjoner som er overkompliserte

Trinn 2: Finn 2-3 eksempler på nettet på refaktorering av lignende moduler.
Minst 1 kilde må være offisiell dokumentasjon fra Anthropic eller tilhørende rammeverk.

Trinn 3: Lag en refaktoreringsplan i plans/YYYY-MM-DD-refactor-{module}.md:
- hvilke filer som skal gis nytt navn
- hvilke funksjoner som skal trekkes ut til egne moduler
- hvilke tester som skal beholdes og hvilke som skal skrives om
- risikoer: hva som kan gå i stykker for brukerne

Trinn 4: Egenkontroll. Er det antakelser i planen som er «tatt ut av løse luften»?
Skriv dem om eller fjern dem.

Mal 2. Databasemigrering.

Jeg aktiverer Plan Mode. Oppgave: migrer databasen fra {old} til {new}.

Trinn 1: Undersøk det gjeldende databaseskjemaet med {schema-reading-command}. Beskriv:
- hvilke tabeller som finnes, og størrelsen på dem
- hvilke relasjoner, indekser og begrensninger som finnes
- hvor migreringene lagres
- hvilke data som er kritiske

Trinn 2: Finn eksempler på {old → new}-migreringer i produksjonsprosjekter.
Minst 3 ulike tilnærminger: pg_dump, dual-write, blue-green.
For hver, oppgi fordeler og risikoer for vår datamengde.

Trinn 3: Lag en migreringsplan i plans/YYYY-MM-DD-db-migration.md:
- faser (sikkerhetskopiering, migrering, verifisering, overgang)
- suksesskriterier for hver fase
- tilbakeføringsplan hvis noe går galt
- nedetid eller ingen nedetid

Trinn 4: Egenkontroll. Er alle tall underbygget av dokumentasjon?
Er alle trinn vurdert opp mot utviklingsmiljøet?

Mal 3. Legge til en ny funksjon.

Jeg aktiverer Plan Mode. Oppgave: legg til funksjonen {description} i prosjektet.

Trinn 1: Undersøk hvordan lignende funksjoner fungerer i prosjektet nå.
Se spesielt på:
- {file-1}
- {file-2}
- hvilke arkitekturmønstre som brukes
- hvilke tester som er skrevet for lignende funksjoner

Trinn 2: Finn ut hvordan denne funksjonen er implementert i åpen kildekode-prosjekter
med en lignende arkitektur. Minst 2 ulike tilnærminger.

Trinn 3: Lag en plan i plans/YYYY-MM-DD-feature-{name}.md:
- liste over nye filer
- liste over endrede filer med konkrete linjenumre
- rekkefølge for implementeringen
- hvilke tester som skal legges til
- hva som skal legges til i CLAUDE.md som en regel for framtidige økter

Trinn 4: Egenkontroll. Følger planen prosjektets arkitektur?
Forutsetter den biblioteker som ikke er installert ennå?

Mal 4. Skrive tester.

Jeg aktiverer Plan Mode. Oppgave: dekk modulen {name} med tester.

Trinn 1: Undersøk modulen {path}. Finn:
- offentlige funksjoner og signaturene deres
- interne funksjoner vi IKKE skal teste (implementasjonsdetaljer)
- randtilfeller: tom input, feil, samtidig tilgang

Trinn 2: Finn testeksempler for en lignende type oppgave
fra populære åpen kildekode-prosjekter som bruker det samme rammeverket.

Trinn 3: Lag en testplan i plans/YYYY-MM-DD-tests-{module}.md:
- en liste over tester for hver offentlige funksjon
- hvilke mocker som trengs
- hvilke fixtures som trengs
- hvilken verifiseringsmetode som skal brukes (assertionsstil)

Trinn 4: Egenkontroll. Tester alle testene oppførsel, ikke implementasjon?
Dekker testene randtilfellene?

Mal 5. Feilsøking av en kompleks feil.

Jeg aktiverer Plan Mode. Oppgave: finn ut årsaken til feilen {symptom-description}.

Trinn 1: FASTSLÅ FAKTA. Løsninger og ideer er forbudt. Bare:
- hva jeg observerer (den nøyaktige ordlyden i feilmeldingen)
- trinn som kan gjentas
- hvilke data som er tilgjengelige (logger, traces, biblioteksversjoner)
- hvilke data som mangler (hva som må samles inn i tillegg)

Trinn 2: Finn eksempler på denne feilen.
Minst 3 kilder: GitHub-saker, fora eller dokumentasjon.
Oppgi en lenke og et kort sammendrag av løsningen for hver.

Trinn 3: Lag en diagnostikkplan i plans/YYYY-MM-DD-bug-{name}.md:
- hvilke hypoteser som skal kontrolleres (sortert etter sannsynlighet)
- hvilke kommandoer/skript som skal kjøres for å kontrollere hver hypotese
- forventet resultat av hver kontroll

Trinn 4: Egenkontroll. Finnes det hypoteser i planen som er «tatt ut av løse luften»?
Er alle hypotesene knyttet til fakta fra trinn 1?

Kopier hver mal, erstatt {parametere} med dine egne, og lim den inn i Claude Code i Plan Mode. Resultatet er en arbeidsplan i plans/ som du godkjenner og bruker til gjennomføring.

Plan Mode eller normal modus: hva bør du velge?#

Anthropic sier dette rett ut i dokumentasjonen:

Hopp over en separat plan bare når den faktiske diffen er liten, forstått og har lav risiko. Planlegg når du må finne tilnærmingen eller samordne risikable endringer på tvers av komponenter. Kjente filnavn eller mål i én setning fjerner ikke risiko ved migrering, autentisering eller dataintegritet.

Beslutningstabell:

Før du velger modus, spør om tilnærming, bivirkninger og verifikasjon er forstått. Arbeid direkte på en liten, lokal endring med lav risiko og en tydelig kontroll. Planlegg først ved usikkerhet, ukjent kode, migrering, autentisering eller samordning mellom komponenter, selv om du allerede kan navngi alle 3-5 berørte filer.

Hvordan kombinerer du Plan Mode + CLAUDE.md + underagenter for pålitelig arbeid?#

CLAUDE.md er en fil som Claude leser i begynnelsen av hver økt, også i Plan Mode. Hvis CLAUDE.md sier «ikke hardkod datoer; hent dem alltid fra databasen», vil planen aldri foreslå hardkoding. Uten en slik regel kan planen foreslå hva som helst.

Kombinasjonen fungerer slik:

Lag 1. CLAUDE.md angir reglene.

Filen beskriver prosjektets teknologistakk, arkitekturprinsipper, forbud («ikke bruk utdaterte API-er») og krav («alle e-poster skal bruke en felles mal»). Detaljert veiledning: Slik konfigurerer du CLAUDE.md.

Lag 2. Plan Mode anvender reglene på oppgaven.

Når du aktiverer Plan Mode og ber «legg til OAuth», leser Claude CLAUDE.md, ser reglene («lagre tokens i Redis, ikke i databasen») og tar dem umiddelbart med i planen. Planen følger prosjektets arkitektur.

Lag 3. Underagenter deler opp arbeidet.

Hvis planen er delt inn i faser, kan hver fase tildeles en egen underagent. Hver underagent arbeider i sitt eget kontekstvindu uten å fylle opp hovedvinduet. Planen i plans/ forblir den sentrale kilden til sannhet: underagentene leser den, gjennomfører fasen sin og oppdaterer avkrysningsboksene.

Hvilke 7 feil ødelegger Plan Mode?#

Feil 1. Planen finnes bare i chatten.

Symptom: Du skrev en plan, lukket vinduet og må gå tilbake til den neste dag – men ingenting er der; konteksten er borte. Løsning: Lagre alltid planen i plans/YYYY-MM-DD-feature-name.md i repositoriet. Chatten er skrivebordet; filen er arkivet.

Feil 2. Alle oppgavene er i én chat.

Symptom: I én økt diskuterer du autentisering, så en migrering, deretter UI-design og så en feil. Kontekstvinduet blir «oppblåst», og Claude glemmer tidligere ting. Løsning: én oppgave – én samtale. Ferdig med planen? Lukk vinduet. Skal du begynne på gjennomføringen? Åpne et nytt.

Feil 3. Én plan på 3000 linjer uten faser.

Symptom: Det finnes en plan, men den har ingen avkrysningsbokser eller inndeling. Det er umulig å se hva som er gjort og ikke. Delegering er umulig. Løsning: Del hver plan inn i 3-7 faser. Hver fase er en liste med avkrysningsbokser og konkrete handlinger.

Feil 4. Ingen grundige undersøkelser før planen.

Symptom: Claude foreslår en løsning på sparket fordi du ikke ba den lete etter eksempler. En uke senere oppdager du at åpen kildekode har hatt en bedre tilnærming lenge. Løsning: Trinn 2 i 4-trinnssyklusen – få Claude til å finne 2-3 eksempler på nettet før den lager en plan.

Feil 5. Den smiskende KI-en foreslår en løsning uten diagnose.

Symptom: Du spør «hvordan fikser jeg feil X?», Claude foreslår en løsning, du bruker den, og ingenting fungerer eller ting blir verre. Løsning: Start alltid med «fastslå fakta; løsninger er forbudt». Gå videre til alternativene først etter diagnosen.

Feil 6. Egenkontrollen hoppes over.

Symptom: Planen virker rimelig, men inneholder 2-3 antakelser «tatt ut av løse luften» (et oppdiktet bibliotek, et API som ikke finnes eller feil versjon). Gjennomføringen feiler på disse punktene. Løsning: Trinn 4 i 4-trinnssyklusen – få Claude til å kontrollere planen sin ærlig på nytt og flagge antakelser.

Feil 7. Vage vilkår i /goal.

Symptom: Du setter /goal få det til å se fint ut, lar den kjøre over natten og våkner til en brukt kvote på $200. Løsning: Bruk bare målbare vilkår med en verifiseringskommando og et obligatorisk «stopp etter N omganger». Ikke «gjør det bra» eller «puss det opp».

Den åttende feilen, som vibe-kodere gjør oftest, er å ignorere selve ideen om en plans/-mappe. Plan Mode uten en plans/-mappe er ingen metode; det er en leke. Bruker du Plan Mode uten å opprette filer, får du 10% av funksjonene.

Hva bør du gjøre etter den første erfaringen med Plan Mode?#

Tre konkrete trinn i stigende vanskelighetsgrad:

Trinn 1. Konfigurer CLAUDE.md hvis du ikke har en ennå.

Uten CLAUDE.md fungerer Plan Mode «i et vakuum» – Claude kjenner ikke prosjektets regler og foreslår planer som bryter arkitekturen. Fullstendig veiledning: Slik konfigurerer du CLAUDE.md. En minimal CLAUDE.md er 50-80 linjer som beskriver teknologistakken, regler og forbud. Lengden er mindre viktig. Det er spesifisiteten som teller.

Trinn 2. Opprett en plans/-mappe i repositoriet.

Legg til en plans/-mappe i prosjektets rotmappe. Bli enige om et navneformat: YYYY-MM-DD-feature-name.md. Hver plan får sin egen fil. Etter en måned har du 20-30 filer; etter seks måneder 100+. Dette er en levende historikk over prosjektets beslutninger.

Trinn 3. Prøv /goal på én oppgave.

Velg en oppgave du vanligvis gjør for hånd på 30-40 minutter. Aktiver Plan Mode, lag en plan og lagre den i plans/. Avslutt Plan Mode. Sett /goal fullfør alle fasene i plans/file.md, alle tester består, ellers stopp etter 30 omganger. Lukk laptopen i en time og gjør noe annet. Kom tilbake og kontroller resultatet.

Dette er minimumet. Dette bygges opp gradvis; ikke prøv å sette alt sammen på én kveld. Begynn med CLAUDE.md, legg til plans/ etter en uke, og prøv /goal over natten etter en måned.

Når du er klar, kan du bli kjent med Ailoot.