Planmodus kontra direkte kjøring

Plan Mode har en kostnad: De leser en plan og godkjenner den. For trivielt arbeid er denne kostnaden bare unødvendig friksjon.

Gå rett til direkte utføring når endringen er:

• En enkeltfilretting med en åpenbar endring.
• Utløst av en klar stack trace som peker på den nøyaktige linjen.
• Liten, tydelig avgrenset og lite risikabel selv om den skulle bli feil.

Hvis De allerede kjenner filen, linjen og løsningen, vil planlegging bare gjøre arbeidet langsommere.

Reduser beslutningen til to spørsmål:

• Er endringen stor? Mange filer, nye moduler, refaktoreringer eller migreringer.
• Er endringen tvetydig? Uklare krav, flere gyldige design eller ukjent skadeomfang.

Hvis ett av punktene stemmer, planlegg først. Hvis ingen av dem stemmer — altså at endringen er liten og tydelig — utfører De direkte.

Dette gjenspeiler eksamensprinsippet: reserver en mer omfattende prosess for situasjoner med stor usikkerhet og stor påvirkning, og hold lette arbeidsflyter lette.

Her angir en stack trace filen og årsaken. Det finnes én riktig løsning og ingen designbeslutning. Planlegging tilfører ingenting.

De ville ganske enkelt bedt Claude om å bruke løsningen, la den Read filen og utføre en presis Edit på den eneste linjen som samsvarer.

Sammenlign dette med en forespørsel som «legg til støtte for flere leietakere i API-et». Det berører autentisering, datalaget, ruting og migreringer. Det finnes flere gyldige design, og skadeomfanget er stort.

Dette er et klassisk tilfelle for Plan Mode: la Claude utforske kodebasen skrivebeskyttet, og foreslå deretter en plan som De godkjenner før én eneste endring gjøres.

Planlegging av store endringer innebærer å lese mange filer, og resultatet fra denne utforskningen blir omfattende. Hvis alt dette legges i hovedkonteksten, fører det til lost-in-the-middle-tap av oppmerksomhet og sløser med tokens.

Bruk en Explore-subagent til å isolere utforskningen. Den undersøker og returnerer et konsist sammendrag, mens planleggingskonteksten forblir ryddig. Ferdigheter kan gjøre det samme med context: fork for å isolere omfattende utdata.

Godkjenningssteget er hele poenget. En plan De kan lese, gjør det mulig å oppdage en feilaktig antakelse før den blir til 15 redigerte filer.

Dette er deterministisk kontroll med mennesket i loopen. Det passer naturlig med arkitektens tankesett: når påvirkningen er stor, ønsker De et fast kontrollpunkt, ikke et håp om at modellen gjettet intensjonen Deres riktig. Instrukser er ~90 % sannsynlighetsbaserte; et godkjenningspunkt er 100 % under Deres kontroll.

Noen ganger kan De ikke vite om en oppgave er liten før De undersøker den. Ikke gjett — undersøk trinnvis, og velg deretter modus.

Det innebygde mønsteret er: bruk Grep på inngangspunktene, Read de viktigste filene, bruk Grep på bruksstedene, og Read forbrukerne. Hvis skadeomfanget viser seg å være stort, bytter De til Plan Mode; hvis det bare gjelder ett avgrenset sted, retter De det direkte.

Plan Mode fungerer ikke alene — det inngår i Claude Code-arbeidsflyten Deres.

• En delt ./CLAUDE.md (i VCS) gir planen standardene og konvensjonene Deres på forhånd.
• TDD: la planen skrive feilede tester først, og implementer deretter til testene blir grønne.
• Skråstrekkommandoer / ferdigheter i .claude/ kan uttrykke en repeterbar arbeidsflyt for «planlegg denne funksjonen» som deles med teamet.

Planen blir kontrakten; testene viser at den er oppfylt.

Begge ytterpunktene koster Dem:

• For mye planlegging av en énliniers retting som er åpenbar fra stack tracen, sløser med tid og tilfører et godkjenningssteg ingen trengte.
• For lite planlegging av en omfattende refaktorering betyr at endringer gjøres før noen har validert fremgangsmåten — akkurat den kostbare feilen godkjenningspunktet skal forhindre.

Tilpass prosessen til omfang og tydelighet. Når De virkelig er usikker, bør De helle mot planlegging ved stort eller tvetydig arbeid, og mot utføring ved lite og tydelig arbeid etter en rask undersøkelse.

Viktigste punkter:

• Plan Mode for stort eller tvetydig arbeid: store endringer, flere fremgangsmåter, arkitektoniske beslutninger og sikker utforskning med godkjenning før endringer.
• Direkte utføring for lite og tydelig arbeid: rettinger i én fil og klare stack traces.
• Beslutningsregel: Hvis endringen er stor ELLER tvetydig, planlegg; hvis den er liten OG tydelig, utfør.
• Undersøk trinnvis (Grep -> Read -> Grep -> Read) når De ikke kan fastslå omfanget på forhånd, og velg deretter.
• Isoler omfattende utforskning med en Explore-subagent (eller en ferdighet med context: fork) for å beskytte planleggingskonteksten.
• Godkjenningspunktet er deterministisk menneskelig kontroll — ikke gi avkall på det ved endringer med stor påvirkning.