Fejlfinding med Claude Code og Codex

Claude Code og Codex kan hjælpe med fejlfinding, men de fungerer bedst, når opgaven starter med konkrete oplysninger. En vag besked som “hjemmesiden virker ikke” giver værktøjet for meget plads til at gætte.

På virksomhedshjemmesider handler fejlfinding ofte om konkrete systemer: kontaktformularer, bookingforløb, WordPress-plugins, Laravel-job, svar fra betalingssystemer, flersprogede sider, Cloudflare-adfærd eller API-integrationer.

Denne arbejdsgang starter, før der findes en rettelse, man kan stole på. Målet er at gå fra en observeret fejl til en forklaring, der er underbygget af dokumentation. Gennemgang af en eksisterende ændring er en anden opgave, som er beskrevet i AI-kodegennemgang med Claude og Codex.

Start med et reproducerbart problem

Før et AI-kodeværktøj skal rette noget, bør fakta samles.

Nyttige oplysninger:

• Præcis URL eller brugerforløb
• Forventet adfærd
• Faktisk adfærd
• Fejlbesked eller logudsnit
• Seneste udrulning eller ændringer i plugins, server eller konfiguration
• Browser, enhed eller brugerrolle, hvis det er relevant
• Kommando der reproducerer fejlen, hvis den findes

Jo bedre oplysninger, desto mindre skal værktøjet gætte.

Beskriv den mindst mulige situation, der udløser fejlen, før koden ændres. Hvis en formular kun fejler i én browser, et webhook kun fejler ved andet forsøg, eller en side kun går i stykker bag en cache, er det en del af fejlen. En bred beskrivelse som “den fejler nogle gange” kan ikke bruges til en efterfølgende kontrol.

Bed om hypoteser før kode

En god arbejdsgang ved fejlfinding adskiller diagnose fra rettelse.

Bed først Claude Code eller Codex om at gennemgå de relevante filer og opstille sandsynlige årsager. Bed derefter om at få beskrevet, hvilke oplysninger der kan bekræfte eller afkræfte hver årsag. Først derefter bør værktøjet lave en lille rettelse.

Det reducerer tilfældige rettelser. Det giver også udvikleren mulighed for at fange en forkert antagelse, før filer ændres.

Hypoteserne skal kunne afprøves. “API’et er ustabilt” er for bredt. “Den anden levering genbruger en idempotensnøgle, som modtageren afviser” peger på en loglinje, en datastruktur og en sti gennem koden, der kan kontrolleres.

Find det lag, hvor fejlen opstår

Det synlige symptom afslører ikke altid det lag, der fejler. En formular, som tilsyneladende ikke bliver sendt, kan være påvirket af browservalidering, JavaScript, serverens behandling, en ekstern API, e-maillevering eller den kvittering, brugeren får vist.

Bed agenten følge forespørgslen gennem disse grænser og tydeligt angive, hvor dokumentationen stopper. Et vellykket HTTP-svar beviser eksempelvis, at serveren svarede — ikke at henvendelsen nåede CRM-systemet, eller at e-mailen kom frem.

Hold rettelsen overskuelig

Fejl under pres fører ofte til for store ændringer. AI kan gøre det værre, fordi det kan redigere mange filer hurtigt.

Jeg foretrækker en lille rettelse, der beviser årsagen:

• Tilføj manglende validering
• Ret én forkert betingelse
• Ret én forkert kobling af API-data
• Håndtér én timeout- eller retry-sti
• Gendan én rute eller viderestilling
• Tilføj én fokuseret test

Hvis det reelle problem er større, bør den lille rettelse stadig gøre næste trin tydeligere.

Verificér rettelsen

Sidste trin er ikke “AI siger, at det er rettet”. Sidste trin er at efterprøve rettelsen.

Det kan betyde at køre en test, gentage det oprindelige brugerforløb, kontrollere logfiler, bekræfte et webhook-svar, indsende en formular, gennemgå en genereret side eller se en kø køre efter udrulning.

Gentag først præcis den situation, der udløste fejlen. Kontrollér derefter den nærmeste situation, der allerede virkede, så en følgeskade bliver opdaget. Notér, hvilke kontroller der blev kørt, og hvilke der ikke kunne køres. Agentens opsummering er nyttig, men dokumentationen fra systemet afgør, om problemet er løst.

Den bredere arbejdsgang omkring fejlfindingen er beskrevet i Claude Code og Codex i en eksisterende kodebase. For API-tunge systemer er driftssikre API-integrationer relevant. Ved akutte WordPress-problemer er specialudvikling og WordPress-rettelser ofte et mere direkte udgangspunkt.