Hva jeg bruker Claude Code til — og hva jeg ikke bruker det til

Jeg kjører Claude Code daglig som en del av faktisk arbeid, ikke som en kuriositet. Her er den ærlige rapporten.

Det jeg bruker det til, jevnlig:

Sanity-innholdspatcher. Denne nettsiden kjører på Sanity CMS, og innholdsoppdateringer som ville krevd tjue manuelle klikk blir et fem-linjers skript som jeg beskriver på norsk og Claude skriver. Å patche grunnleggerbiografien på tvers av to språk uten å ødelegge eksisterende feltstruktur: ti minutter inkludert gjennomgang.

KB-innleseinfrastruktur. Markdown-filer i en mappe, embeddet inn i en Postgres pgvector-store. Første versjon av chunker-en tok en time med Claude som parprogrammerer mot en halvdag med å lese dokumentasjon. Andre versjon la til strippet sitater og en `language`-alias for `locale` i frontmatter-parseren da et eksternt innholdssett dukket opp i et annet format. Tjue minutter.

Engangsskript der kostnaden ved å skrive dem for hånd ikke er verdt det. Inspector-skript som dumper Sanity-state. Engangs-patcher når jeg debugger. Migrasjonsskript som flytter tre paragrafer fra ett felt til et annet. Ingen av disse hadde eksistert hvis jeg måtte skrive dem for hånd. De fleste blir lagt inn i repoet og glemt, og det er greit.

Lese andres kode når jeg er ny til et bibliotek. Bedre enn dokumentasjonen i de fleste tilfeller — raskere, svarer på det faktiske spørsmålet, peker til kildefilen når jeg trenger å verifisere.

Det jeg ikke bruker det til:

Å designe arkitekturen. Claude Code er en junior-utvikler på sitt beste når det gjelder strukturelle beslutninger. Det vil skrive det du ber det skrive. Hvis det du ber det skrive er fundamentalt feil, får du en selvsikkert-feil implementering. Beslutningen om hva som skal bygges, kommer fra meg. Alltid.

Debugging når jeg ikke har lest koden først. Mønsteret som går galt hver gang: jeg ser en feil, limer den inn i Claude, ser det generere en plausibel fiks, anvender fiksen, og finner ut at bug-en ikke faktisk er fikset. Fiksen som fungerer kommer fra å forstå hva som er ødelagt. Jeg leser nå koden først, hver gang.

Ting der feilmodusen er stille. AI-kodingverktøy er best når du raskt kan verifisere output — passerer testen, kjører build-en, rendres siden. De er verst når output ser riktig ut, men er subtilt feil (autentiseringsflyter, betalingslogikk, hva som helst der "kjørte uten feil" ikke betyr "gjorde det riktige"). For disse skriver jeg førsteversjonen selv.

Mønsteret, hvis det finnes ett: Claude Code multipliserer din smak. Hvis du har god smak i kode, gjør det deg raskere. Hvis du ikke har det, gir det deg mer dårlig kode, raskere.

Det er også det riktige svaret på "burde vi bruke AI til å skrive kode i selskapet vårt": det kommer an på om dere har en senior utvikler som kan styre det. Uten en, sender dere selvsikkert-utseende teknisk gjeld i raskere takt enn før.