Claude Code-serieopplæring 4: Hva er bruksområdene for Claude Code?

Typiske bruksscenarioer

Jeg deler bruksscenarioene inn i fire kategorier, sortert etter hyppighet fra høy til lav.

Første kategori: Forstå kode

Dette er nok den mest brukte kategorien. Når du overtar et prosjekt fra noen andre, ser på en gammel modul, eller åpner et depot uten dokumentasjon, spør du bare direkte.

Spesifikk fremgangsmåte:

claude "Hva gjør dette prosjektet? Hvor er inngangen?" – Den leser package.json, katalogstruktur, nøkkelfiler og gir en oppsummering.
Åpne en funksjon, be den forklare logikken og tegne flyten (med tekstbeskrivelse).
Be den spore hele banen til en API-forespørsel fra frontend til database.

Det den gjør her, er i bunn og grunn å hjelpe deg med «det skitne arbeidet med kodelesing». Du trenger ikke å grepe rundt i en halv time og deretter sette sammen brikkene i hodet. Den rydder veien, og du tar avgjørelsene.

Erstatningsobjektet for denne typen scenarioer er: manuell leting i kodebasen, notatskriving og tegning av kallgrafer.

Andre kategori: Skrive kode, endre kode

Dette er den mest diskuterte kategorien, men den er faktisk ikke den mest brukte. Scenarioene for kodeskriving er vanligvis slik:

Generere ny funksjonalitet: "Legg til et grensesnitt for å endre e-post under user-modulen, valider e-postformatet, skriv enhetstester."
Omstrukturering på tvers av filer: "Bytt alle moment() i disse tre filene til dayjs(), ikke endre annen logikk."
Migrering og oppgradering: "Konverter denne Vue 2-komponenten til Vue 3 Composition API-syntaks."

Den genererte koden er ikke nødvendigvis riktig første gang, men den kan gjøre alle endringer på tvers av filer på én gang, og du kan se på diff per fil og godta eller avvise enkeltvis.

Erstatningsobjektet for denne typen scenarioer er: manuell skriving av repeterende kode, manuell søk-og-erstatt av referanser på tvers av filer.

Tredje kategori: Feilsøking og reparasjon

Når en feil oppstår, er den vanlige arbeidsflyten: se på feilmeldingen, lokaliser filen, gjett årsaken, prøv å endre, hvis det ikke fungerer, gå tilbake og se igjen. Claude Code kan ta imot hele feilstakken direkte, kombinere med prosjektkoden og lokalisere selv.

Typisk bruk:

Gi den mislykkede testutgangen til den, den leser relevant kode, gir en endringsløsning, kjører testen på nytt og sjekker om den består.
Ved CI-feil, lim inn loggen, la den fikse, og kjør deretter git diff for å bekrefte endringene.

Her fungerer den mer som en «førsterunde-undersøker». Det er du som bruker tid på å tenke, men det er den som blar i filer, sammenligner forskjeller og kjører verifiseringskommandoer.

Erstatningsobjektet for denne typen scenarioer er: gjentatt kjøring av tester, lesing av feillogger, manuell sammenligning av kodeforskjeller.

Fjerde kategori: Diverse automatisering

Denne kategorien er minst iøynefallende, men summen av dem sparer mest tid.

Eksempler:

Skrive Git commit-meldinger: claude "Skriv en commit-melding i Conventional Commits-format basert på gjeldende git diff"
Generere PR-beskrivelse: Be den sammenligne forskjeller mellom gjeldende gren og main, generere en oppsummering av endringene og testinstruksjoner.
Skrive utgivelsesnotater: La Claude Code lese commit-historikken for den siste uken og generere en CHANGELOG.
Svare på miljøproblemer: "Installasjon av denne avhengigheten ga en feil. Hjelp meg å se på terminalutgangen og finne årsaken."

Fellesnevneren for disse tingene er: de er ikke kompliserte, men kjedelige. Å gjøre dem selv krever å bytte vinduer og skrive mye tekst. Gi dem til den, så er de ferdige på noen sekunder.

Erstatningsobjektet for denne typen scenarioer er: manuell redigering av tekst, skriving av standard dokumentasjon, søking etter miljøkonfigurasjonsproblemer.

Et «kart»

Hvis du setter disse fire kategoriene inn i den daglige arbeidsflyten, ser det omtrent slik ut:

Får et ukjent prosjekt
    │
    ▼
[Forstå kode] ─── Finn ut struktur, inngang, nøkkellogikk
    │
    ▼
Begynn å skrive ny funksjonalitet eller endre modul
    │
    ▼
[Skrive kode/endre kode] ─── Generer implementering, omstrukturer på tvers av filer
    │
    ▼
Kjør tester, får feil
    │
    ▼
[Feilsøking og reparasjon] ─── Analyser feil, lokaliser, fiks, kjør på nytt
    │
    ▼
Forbered innsending
    │
    ▼
[Diverse automatisering] ─── Skriv commit, PR-beskrivelse, utgivelsesnotater
    │
    ▼
Send inn, ferdig

Du trenger ikke å bruke den i alle fire kvadrantene. Noen team bruker den bare til å forstå kode, andre bare til å skrive tester og sende PR-er. Velg det scenariet som plager deg mest, og start derfra.

To nyttige vurderingskriterier

Hvis du er usikker på om en oppgave bør overlates til Claude Code, kan du stille deg selv to spørsmål:

1. Er denne oppgaven mer «mekanisk» enn «kreativ»?

Å endre hundre referanser, formatere utdata, generere standardkode – disse tingene tar mye tid når du gjør dem manuelt, men du har allerede ideen. Det passer å gi dem til den.

2. Er «verifiseringskostnaden» for denne oppgaven høy?

Hvis en endring krever flere hopp, kjøring av tester og lesing av logger for å bekrefte, er det tregt å prøve og feile manuelt. Claude Code kan fullføre syklusen «endre-kjør-se-endre igjen» selv, og du blir mye lettere.