Sådan bruger du Claude Code og Codex i en eksisterende kodebase

Claude Code og Codex er mest nyttige, når de arbejder i en rigtig kodebase med tydelige grænser. Fordelen i forhold til et indsat kodeudsnit er sammenhængen: De kan gennemgå beslægtede filer, følge projektinstruktioner, se den aktuelle Git-status og køre relevante kontroller, når rettighederne tillader det.

Den sammenhæng betyder ikke, at værktøjerne automatisk forstår systemet. En bookinghjemmeside, WordPress-løsning, Laravel-applikation eller Astro-frontend kan rumme mange års beslutninger: ældre plugins, begrænsninger hos udbyderen, betalingsforløb, SEO-hensyn, specialfelter, API-integrationer og indholdsregler, som ikke fremgår af en enkelt fil.

Kortlæg kodebasen før ændringer

Den første instruktion bør fastlægge, hvor adfærden ligger, og hvordan projektet kontrolleres. En rettelse før denne gennemgang får let værktøjet til at udlede et mønster ud fra for lidt sammenhæng.

Gode startspørgsmål:

• Hvilke filer styrer denne adfærd?
• Hvilken applikation, pakke, udvidelse eller service ejer den?
• Hvilke antagelser og forretningsregler ligger i den nuværende kode?
• Hvilke tests, buildkommandoer eller manuelle kontroller dækker den?
• Findes der lokale ændringer, som ikke må overskrives?
• Hvad kan gå i stykker uden for den fil, der umiddelbart ser relevant ud?

Resultatet bør være et kort over den relevante kode, ikke en bred beskrivelse af hele projektet. Gennemgangen er kun nyttig, hvis den gør næste beslutning mere præcis.

Brug agenter til opgaver, der kræver kodebasen

Claude Code og Codex er bedre egnet end en chat i browseren, når svaret afhænger af flere filer, projektets konventioner, resultater fra kommandoer eller de aktuelle kodeændringer.

Gode opgaver til en kodeagent:

• Find, hvor en rute eller en indholdsside bliver genereret
• Spor et webhook fra controller til databaseopdatering
• Forklar hvorfor et build eller en fokuseret test fejler
• Tilføj validering til én eksisterende formular
• Omstrukturér én gentaget hjælpefunktion uden at ændre resultatet
• Opdatér én komponent uden at ændre hensigten med HTML og styling
• Vurdér om en foreslået ændring følger den eksisterende arkitektur

Opgaven skal stadig have en tydelig grænse. Brede instruktioner som “modernisér hele hjemmesiden” eller “ryd hele temaet op” inviterer til store kodeændringer, der er svære at forstå og risikable at sætte i drift.

Giv hvert værktøj konkrete projektinstruktioner

Claude Code læser typisk projektvejledning fra CLAUDE.md, mens Codex bruger AGENTS.md. Det nyttige indhold er konkret: kodebasens struktur, pakkehåndtering, kontrolkommandoer, arkitektoniske grænser, risici ved udrulning og regler som “ændr ikke brugerfladen uden at blive bedt om det” eller “ændr ikke offentlige URL’er uden viderestillinger”.

Når begge værktøjer bruges, bør fælles regler have én vedligeholdt kilde i stedet for at drive fra hinanden i to lange filer. Den konkrete opsætning er beskrevet i AGENTS.md og CLAUDE.md til projektinstruktioner.

Instruktionerne forbedrer udgangspunktet, men de erstatter ikke oplysninger om den konkrete opgave. Agenten skal stadig kende det ønskede resultat, hvad der ligger uden for opgaven, og hvordan ændringen efterprøves.

Hold Git-status og rettigheder synlige

Før en agent ændrer filer, skal det kontrolleres, om kodebasen allerede indeholder lokale ændringer. Eksisterende arbejde tilhører nogen og må ikke overskrives, blot fordi det ligger uden for den aktuelle opgave.

En kontrolleret rækkefølge er:

1. Tjek den aktuelle Git-status.
2. Bed agenten gennemgå de relevante filer uden at ændre dem.
3. Fastlæg den mindste nyttige ændring.
4. Giv kun adgang til de kommandoer og filer, opgaven kræver.
5. Gennemgå kodeændringerne.
6. Kør de mest fokuserede kontroller, der kan dokumentere resultatet.

Rettigheder betyder noget, fordi kodeagenter kan mere end at foreslå kode. En kommando kan opdatere afhængigheder, omskrive genererede filer, ændre en database, kontakte en ekstern tjeneste eller fjerne lokale data. Agenten bør forklare virkningen før en handling, der er svær at fortryde.

Lav én overskuelig ændring

Rettelsen skal være lille nok til, at en udvikler kan forbinde hver ændret linje med det ønskede resultat. Hvis gennemgangen afdækker et større arkitektonisk problem, bør den nødvendige rettelse og en senere omstrukturering holdes adskilt.

Ved en afgrænset ændring tjekker jeg:

• Ændrer det kun den ønskede adfærd?
• Følger det den eksisterende arkitektur?
• Bevarer det bevidst håndtering af særlige tilfælde?
• Tilføjer det afhængigheder eller konfigurationsændringer?
• Påvirker det SEO, tilgængelighed, formularer, viderestillinger eller måling?
• Kan ændringen verificeres med en kommando eller manuel test?

Når opgaven starter med en fejl, bør arbejdsgangen adskille dokumentation, hypoteser, den mindste rettelse og kontrol af det oprindelige problem. Det er beskrevet i fejlfinding med Claude Code og Codex.

Afslut med dokumentation, ikke agentens opsummering

Den afsluttende besked fra Claude Code eller Codex er en nyttig log, men den beviser ikke, at ændringen virker. Dokumentationen kan være en fokuseret test, typekontrol, et build, et gentaget browserforløb, en sammenligning af logfiler, et webhook-svar eller en gennemgang af den genererede side.

Efter kontrollen skal de faktiske kodeændringer gennemgås for følgeskader og skjulte udvidelser af opgaven. Guiden til AI-kodegennemgang med Claude og Codex viser, hvordan gennemgangen kan opdeles efter konkrete risici i stedet for blot at spørge, om koden “ser god ud”.

Den praktiske standard er den samme for begge værktøjer: forstå kodebasen, afgræns opgaven, hold ændringen overskuelig, og efterprøv resultatet i det system, der skal køre koden.