Claude Code Tutorial Serie 4: Hvad er brugsscenarierne for Claude Code?

Typiske brugsscenarier

Jeg opdeler brugsscenarierne i fire kategorier, sorteret efter hyppighed fra høj til lav.

Første kategori: Forståelse af kode

Dette er nok den mest brugte type. Når man overtager en andens projekt, ser på en gammel modul, eller åbner et repository uden dokumentation, kan man bare spørge det.

Specifik fremgangsmåde:

claude "Hvad laver dette projekt? Hvor er indgangspunktet?" – Det læser package.json, mappestruktur, nøglefiler og giver et overblik.
Åbn en funktion, få den til at forklare logikken og tegne flowet (med tekstbeskrivelse).
Få den til at spore en API-anmodnings fulde vej fra frontend til database.

Det, det gør her, er i bund og grund at hjælpe dig med "det beskidte arbejde med kodelæsning". Du behøver ikke selv at grep i timevis og sætte brikkerne sammen i hovedet. Det rydder stien, og du tager beslutningerne.

Erstatningen for denne type scenarie er: Manuel gennemsøgning af kodebasen, notetagning, tegning af kaldgrafer.

Anden kategori: Skrivning og ændring af kode

Dette er den mest omtalte kategori, men den er faktisk ikke den mest brugte. Scenarier for at skrive kode ser normalt sådan ud:

Generer ny funktionalitet: "Tilføj en grænseflade til at ændre e-mail under user-modulet, valider e-mail-formatet, skriv enhedstests."
Tværfils refaktorering: "Erstat alle moment() med dayjs() i disse tre filer, uden at ændre anden logik."
Migrering og opgradering: "Konverter denne Vue 2-komponent til Vue 3 Composition API-syntaks."

Den genererede kode er ikke altid korrekt første gang, men den kan udføre tværfils ændringer på én gang, og du kan gennemgå diff'en fil for fil og acceptere eller afvise.

Erstatningen for denne type scenarie er: Manuel skrivning af gentagelseskode, manuel søgning og erstatning af tværfils referencer.

Tredje kategori: Debugging og reparation

Når en fejl opstår, er den normale arbejdsgang: Se fejlmeddelelsen, find filen, gæt årsagen, prøv at rette, hvis det ikke virker, gå tilbage. Claude Code kan direkte modtage hele fejlstacken og kombinere den med projektkoden for selv at lokalisere fejlen.

Typisk brug:

Giv den output fra en mislykket test, den læser relevant kode, giver en løsning, kører testen igen for at se, om den består.
Ved CI-fejl, indsæt loggen, lad den reparere, og kør derefter git diff for at bekræfte ændringerne.

Her fungerer det mere som en "første runde inspektør". Det er dig, der bruger tid på at tænke, men det er den, der læser filer, sammenligner forskelle og kører verifikationskommandoer.

Erstatningen for denne type scenarie er: Gentagne testkørsler, læsning af fejllogs, manuel sammenligning af kodeforskelle.

Fjerde kategori: Diverse automatisering

Denne type scenarie er mest overset, men sammenlagt sparer den mest tid.

Eksempler:

Skriv Git-commit-beskeder: claude "Skriv en commit-besked i Conventional Commits-format baseret på den aktuelle git diff"
Generer PR-beskrivelse: Få den til at sammenligne den aktuelle branch med main og generere en opsummering af ændringerne og testnoter.
Skriv udgivelsesnoter: Få Claude Code til at læse den seneste uges commithistorik og generere CHANGELOG.
Svar på miljøproblemer: "Installation af denne afhængighed giver en fejl, hjælp mig med at se på terminaludskriften og finde årsagen."

Fælles for disse opgaver: De er ikke komplekse, men besværlige. Hvis du gør det selv, skal du skifte vindue og skrive meget. Overlad det til den, og det er færdigt på få sekunder.

Erstatningen for denne type scenarie er: Manuel redigering af tekst, skrivning af standarddokumentation, søgning efter miljøkonfigurationsproblemer.

Et "kort"

Hvis man sætter disse fire typer scenarier ind i den daglige arbejdsgang, ser det cirka sådan ud:

Får et ukendt projekt
    │
    ▼
[Forståelse af kode] ─── Find ud af struktur, indgang, nøglelogik
    │
    ▼
Begynd at skrive ny funktion eller ændre modul
    │
    ▼
[Skrivning/ændring af kode] ─── Generer implementering, tværfils refaktorering
    │
    ▼
Kør test, der opstår fejl
    │
    ▼
[Debugging og reparation] ─── Analyser fejl, lokaliser, reparer, kør igen
    │
    ▼
Forbered commit
    │
    ▼
[Diverse automatisering] ─── Skriv commit, PR-beskrivelse, udgivelsesnoter
    │
    ▼
Commit, færdig

Du behøver ikke bruge det i alle fire kvadranter. Nogle teams bruger det kun til at forstå kode, andre kun til at skrive tests og sende PR'er. Hvilket område der plager dig mest, start med det scenarie.

To brugbare kriterier

Hvis du er usikker på, om en opgave skal overlades til Claude Code, kan du stille dig selv to spørgsmål:

1. Er denne opgave mere "mekanisk" end "kreativ"?

At ændre hundrede referencer, formatere output, generere boilerplate-kode – disse opgaver tager tid, når man gør dem selv, men du har allerede ideen. Det er velegnet til at overlade til den.

2. Er "verifikationsomkostningen" for denne opgave høj?

Hvis en ændring kræver gentagne hop, testkørsler og loglæsning for at bekræfte, er det langsomt for en person at fejlsøge. Claude Code kan selv gennemføre cyklussen "ret-kør-se-ret-igen", og du bliver meget mere afslappet.